Backend idling

Made all of the hardware changes and everything still works! While I was at it - with PC guts all over the floor, I replaced the PSU in my GX150 (the fan on the original sounded like a heard of cows) and swapped out the RAM modules for a 512Mb stick - the max supported memory on this PIII.

I didn't change any software with the exception of moving the relevant IVTV and LIRC drivers, support libraries and configs from the Shuttle to the GX150. Fired up mythtvsetup and entered the relevant shutdown/wakeup details via the General tab and it worked!

However, I think the MythTV idleness algorithm is broken. It doesn't quite do what is described in the HOWTO.

My scheduler.cpp patch fixes the algorithm for 0.19 and is also likely to apply to 0.20 and SVN head. It hasn't had much testing yet but seems to be working for me.

So far, I've ignored frontend integration. That will require some lirc relaying magic between backend and frontend. I also don't have the frontend reliably powering up yet after being switched off. Still, I'm about half way there and Myth is reliably recording shows.

To get my external USB disk, NTL box and RGB-svideo converter to poweroff/on along with my backend, I've ordered an intelliplug. Will let you know how that goes...

Waking the dead

nvram-wakeup works great on the Dell Optiplex GX150 (my master backend). The bundled guess-helper script didn't produce a usable config. Instead, I took a look at the source as suggested in this MythTV wiki page and used

# nvram-wakeup -iwname dell_optiplex_dxa

It's worth noting that the GX150 can only be set to wakeup at a specific 24hr time. Date and second components are not used. Within the BIOS, the wakeup function can be set to everyday, weekdays or off. Although somewhat limited, this should be fine for a MythTV server as it's extremely rare for the box to be idle 24hrs straight. If it actually needed to be idle for longer, mythbackend would simply shut the box down again if it awoke early and found nothing to do.

The nvram-wakeup utility sets the wakeup time and switches the function on or off by poking /dev/nvram. You need the nvram kernel module loaded. The GX150 is very well behaved, just set the wakeup time and shut the system down. Many motherboards require a reboot for nvram changes to take effect, ie. you have to poke the value, reboot and then shutdown which is a bit messy.

WOL

I also tested the WOL capability. The GX150 comes with an onboard 3c905 driven by the 3c59x driver. This driver doesn't expose WOL functionality via ethtool. Instead, setting the module option enable_wol=1 does the trick.

As with nvram-wakeup, no special shutdown procedure is needed. Fire off a magic WOL packet containing the NICs MAC address; low and behold the box starts booting.

Having tested nvram-wakeup (for scheduled recordings) and WOL (for frontend initiated wake-up), I'm now satisfied that it'll be possible to make this work. I still have to battle with my frontend but even if I'm only able to manage the backed efficiently, that's already ~70W of quiescent power saved.

The next step

Now I'll have to schedule some time to bring my boxes down, take them apart and wrestle the PVR350 from the Shuttle's grasp. That'll be no mean feat. I'll also need to lose the as-yet unused DVB-T card and migrate the USB-serial and homebrew serial blaster hardware and config from the Shuttle to the GX150. Not sure how I'll interact with the frontend after the IR has been moved to the backend but I do have an RF keyboard which can be used in the short-term.