All change

Well since November, I've:

1. Upgraded to MythTV 0.20
2. Moved to using the OpenGL painter
3. Managed to get the internal video player working nicely with (compressed) HD content and digital audio out - requires at least 32Mb of AGP Video RAM
   
4. Implemented a fully idle-managed system with automatic startup and shutdown
   
5. Fixed the Shuttle ZEN boot-up FSB hardware fault that affects almost all of these boxes
   
6. Used LIRC magic to make the back-end seamlessly relay remote signals to the front-end
   

...and the system as a whole is working better than ever! Now that my cable-box gets power-cycled daily, it even changes channel correctly every time.

I must admit that the WAF was real low during the idle-shutdown changes that I made as the system needed administrator intervention to bring up the front-end successfully. This was mostly due to the Shuttle's FSB bug. However, once that was fixed and a few automation scripts were smoothed out, WAF rose to an all-time high.

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.

MythTV energy costs

...between £165-£330 per year!

I'm increasingly disturbed by the energy consumption within my home and some time ago, bought a little plug-in power monitor to see where all of those KWh were going. The monitor plugs in to a wall socket and the kit plugs in to the monitor, either directly or indirectly via a PDU.

It was quite useful in showing me that my cable-box consumed 100% power while on standby and my MythTV server and slave frontend consumed around 150W.

I have a lot of kit that currently runs 24x7. Different parts of it are needed for recording shows, for watching shows, for when people are in the house or for remote access. There's a Venn diagram in there somewhere but here's the list:

• MythTV Slave/frontend inc. ATA disk, PVR350, USB-serial convertor, homebrew serial-IR sender
  
• MythTV backend inc. 2x ATA disk, DVB-T card, USB2 card
• External USB2-ATA enclosure and disk
• USB2 media card reader
• USB2 webcam (currently off)
  
• NTL cable-TV box
• RGB-SVideo convertor
• 100Mb switch
  
• Airport Express
• Broadband router
• NTL cable-broadband box
• Subwoofer (in auto-standby mode)
• AV amp (in standby)
  

The rest of my AV kit (DVD player, Plasma screen, VCR) is controlled indirectly by my AV Amp via a special relay-controlled PDU. If the Amp is off or in standby, the PDU cuts power to the AV kit.

A lot has changed since I first looked at the power consumption of my Myth setup. Due to varying size/noise/location requirements, it used to be spread out around the house but now almost everything resides in the same location, in the cupboard under the stairs. This should make consolidation and power control somewhat easier & cheaper.

I now have an Electrisave. It's a device that can monitor the power consumption of individual power-circuits or an entire home by electromagnetic current sensing. Mine is clamped on my house feed and reads a steady 0.25Kw when the house is quiescent, ie. with no heating, cooling, lighting or domestic appliances running. That's 2190 KWh, 2 Tons of CO2 or about £250 per annum.

Not all of this is down to the PVR subsystem. I have a bunch of devices on standby; clock-radios, a stereo and the microwave. There are also a handful of other devices drawing power such as a wireless phone base-station/holder and electric toothbrush charger.

I'm determined to get to the bottom of this 250W; my short-term goal is to halve it and this will definitely need me to completely re-think my current MythTV setup...

OT: Talking to the screen

I've updated my new remote controlling setup further and I'm now able to manage my screen via it's serial port - yes the commercial grade Panasonic plasma screens come with a serial port! As my Shuttle's only serial port was already used for the IR-blaster, I bought a 2m USB-RS232C serial lead with an ftdi chipset from these guys.

It worked out-of-the-box and came up as /dev/ttyUSB0:

usb 3-1: new full speed USB device using ohci_hcd and address 2
usbcore: registered new driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device
ftdi_sio 3-1:1.0: FTDI USB Serial Device converter detected
drivers/usb/serial/ftdi_sio.c: Detected FT232BM
usb 3-1: FTDI USB Serial Device converter now attached to ttyUSB0
usbcore: registered new driver ftdi_sio
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver

It even defaulted to the correct tty characteristics for me; 9600 baud, 8bits even, 1 stop bit. I now use this trivial script to control the screen via the usual irexec method:

#!/bin/sh
device=/dev/ttyUSB0

if [ -z "$1" ]; then
        echo "Need to specify at least one command"
        exit 1
fi

for cmd in $*; do
        echo -en '\002'$cmd'\003' > $device
done

Optimising for EDTV progressive output

So, I'm finally approaching happiness with the ATI's VGA output. Yes, it's taken me about a fortnight but I guess that's what I expected. I won't go into all of the gory details, but here are some of the more interesting highlights...

1. Use the Xorg 6.8.2 radeon driver at 852x480@60Hz and digital SPDIF audio: serious ALSA problems on pause/skip/LiveTV channel-change, high CPU usage, video output fairly poor using most de-interlacers, bob deint jumpy. Disable kernel radeon module to avoid kernel Oops.
   
2. Use the latest ATI fglrx driver with analogue audio: ALSA problems solved, high CPU usage - no DRM/AGP/DMA, video output fairly poor using most de-interlacers, bob deint jumpy. PQ poor.
   
3. Enable AGP in the BIOS! I'd switched it off to save wasting system RAM when I wasn't using the ATI card. Increase videoram from 8-32Mb. Hand-load ati_agp kernel module so that agpgart can handle the ATI IGP chipset.
   
4. Enable DRM/AGP (no OpenGL, 3D not supported on IGP with fglrx driver): CPU usage low, bob de-interlacer unusable, kerneldeint ok. Mythfrontend using RTC for video timing. PQ acceptable.
   
5. Change output to 856x488@50Hz to match PAL framerate and allow 1:1 screen resolution with overscan: PQ not too bad.
6. Build and install Xorg 6.9.0 to get OpenGL support for the 9100 IGP; to allow mythfrontend to use OpenGL video sync instead of the RTC fallback method. (FC3 has Xorg 6.8.x). Re-enable loading of the radeon DRI kernel module.
7. Use Xorg 6.9.0 radeon driver with DRI. agp_ati, agpgart, radeon, drm kernel modules loaded. Mythfrontend now using DRM for video timing. PQ good.
8. Switch to bob deint: Perfect video timing - no jumping. PQ very good.

I may not be finished yet, but the improvement in audio quality, video quality, CPU usage and display functionality has been dramatic through these steps. Although I was content at step 5 after a week or so of viewing, I feel that step 8 is likely to be a siginificant improvement once I've given it some air-time.

Current Xorg driver config:

Section "Device"
  Identifier  "onboard"
  Driver      "radeon"
  VendorName  "ATI"
  BoardName   "Radeon 9100 IGP"

  Option "AGPMode" "8"
  Option "AGPFastWrite" "on"
  Option "SubPixelOrder" "RGB"
  Option "UseFBDev" "off"
  # usually disabled
  Option "RenderAccel" "on"
  # Usually XAA
  #Option "AccelMethod" "EXA"
  Option "EnablePageFlip" "on"
EndSection

Current Modeline:

  ModeLine     "856x488@50" 26.3 856 888 992 1024 488 498 502 513

OT: CCFL backlighting

Screen with the new CCFL lights installed from Neonlights. This shows 4x 12" white CCFL running off of a pair of inverters fed by a variable (5,6,7.5,9,12,15v) DC adapter at 7.5v. Light-output is at ~50%. The adapter is drawing a mere 5w @ 230v AC.

I intend to install a 12v varilight adaptor to compliment a remote-controlled varilight dimmer feeding a regular wall-light outlet. Once this is in, I should have arm-chair dimming control of the backlighting over ~25-100% brightness range.

Although not necessary for viewing, I'm also considering installing some lighting under the bottom edge of the screen, however the installation wouldn't be as easy or the diffusing pattern as clean as the existing units.