MythTV - the open source DVR

Update debian wheezy (linux 3.2)

Using linux-3.2.x hdmi-audio has been disabled by default on the radeon kernel module, due to black screen issues (can't really argue with that), that mean you have to enable hdmi. I've done that in the initramdisk by adding

drm
radeon modeset=1 audio=1

to "/etc/initramfs-tools/modules", and run "update-initramfs -h -k all"

What is MythTV

MythTV is a free software DVR (Digital Video Recorder). A product I've used for the better part of 4 years on and off, and I've been quite fond of it. More recently a rollout of DVB-C signal instead of the old analogue signal has reached my neighbourhood with HD and what have you. So now it was time to upgrade the old machine to something that could actually record DVB-C and play HD.

My approach was buy a new computer with a bang for the buck (purchase and running cost) point of view. After looking around for requirements I found consensus to be: 3+ Ghz quad-core, If there's no offloading to the graphics card (having had my share of "Why doesn't this binary blob work!" moments with nvidia, I didn't bother with gpu-offloading/VDPAU.). Thinking if i need to use this as a work server instead of just a MythTV appliance, then the choise was Intel I7 or AMD Phenom II. Thermal design was in the same ballpark, but Intel's had a lower idle power consumption. However the price difference of the 2 systems was huge, actually it was equivalent of the power-bill for a year+ of running full blast. So AMD it was.

So I bought the system, and played around with it. I settled for Ubuntu as my linux distribution - 9.10 was the release at the time. This lead to blood sweat and tears. I had now chosen a motherboard with a built-in Radeon HD 4200, this lead to the problem of graphics driver.

This table only covers Raden HD 4200, months ago.

After a short while with the radeonhd driver (Audio over HDMI was paramount). The radeon driver gained this functionality too, and the switch was done. This led to a long time of kernel-compiles and new bleeding edge xorg installations. Time went and Ubuntu 10.04 came along, with a new (-ish) radeon driver and a kernel that matched. This ended in a lot of compiles of custom kernels & bleeding edge xorg, to get everything working. Video output was getting there.

Meanwhile...

Finally I found a CamCard that worked with my TV and signal provider (CanalDigital), tried it in the MythTV box, and actually recorded some HD (1920x1080i@50) content. But playback, that was a whole different story. No matter what I did I couldn't get it to run at more than 23.5-24.5 fps when the target was 25. Fortunately Ubuntu 10.04 was right around the corner with a newer version of MythTV packaged. What a joy, the 0.23 release notes said 15% faster software H.264 decoder, and suddenly I could watch perfect HD content with a cpuload of 200-220%.

So all in all, Ubuntu 10.04 was my saviour.

The Master/Slave setup

Aka: "The Quest for Power Savings".

The MythTV Hardware

MythTV has an option for shutting down the backend if it's idle, and then waking up again, fx. by using the realtime clock and wake at a time function in the BIOS, or by asking a service for a wake-up call at given time. This looks great on paper, and having a small computer that runs 24-7 (firewall/access point witn <20W power consumption), implementing such a service wouldn't be such a problem. But then I would have to wake up the MythTV server just to schedule a recording using MythWeb, so the obvious way would be to make a master backend on the firewall, and let the other machine be a slave backend (recording/storage server) with playback capabilities.

The involved hardware is this:

The Software

The master/slave setup seemed to work great. It woke recorded and fell asleep again.

I moved the remote to the firewall and configured Lirc to send events over the net to the slave backend. The firewall got a trigger on the "Power" button of the remote, that woke up the slave. Since the master backend doesn't try to shut down the first 5 minutes after a slave has connected, I had plenty of time to find a recording and start watching it. And the slave isn't shut down when a frontend is connected, so as long as I was watching the recording, everyting was fine. But as soon as the recording ended the slave backend shut down.

When shutting down the master backend (for timed wake), there's an option to do a pre-shutdown-wakeup check (setting: "preSDWUCheckCommand"), but this wasn't implemented for the slave shutdown.

I looked at the source, the check was quite easy to implement. So I made a patch, and thought: "Maby others need this functionality too". So I went to the bug tracking system for MythTV, and checked to see if anybody else had a feature request for this, then I could just attach it to that. If I had done that first I would have saved some time by using the existing patch from ticket 7762. So I've decided to dropped my own patch and go with the one in the ticket tracking system.

I've packaged the sources:

mythtv_0.23.0+fixes24158-0ubuntu2bogeskov.debian.tar.gz
mythtv_0.23.0+fixes24158-0ubuntu2bogeskov.dsc
mythtv_0.23.0+fixes24158.orig.tar.gz

into mythtv_0.23.0+fixes24158-source.tar And you can build it like this:

tar xf mythtv_0.23.0+fixes24158-source.tar
dpkg-source -x mythtv_0.23.0+fixes24158-0ubuntu2bogeskov.dsc
cd mythtv-0.23.0+fixes24158/
fakeroot ./debian/rules binary
dpkg -i ../mythtv-backend_0.23.0+fixes24158-0ubuntu2bogeskov_`uname -m`.deb

Or if you trust me enough to run an unsigned application I've built some binaries:

• mythtv-backend_0.23.0+fixes24158-0ubuntu2bogeskov_amd64.deb

• mythtv-backend_0.23.0+fixes24158-0ubuntu2bogeskov_i386.deb

Install it with:

dpkg -i mythtv-backend_0.23.0+fixes24158-0ubuntu2bogeskov_`uname -m`.deb

Now you run the risk that, an update comes from Ubuntu, which will overwrite your new package, hence removing the ability to keep the slave awake. This you avoid by running this:

echo mythtv-backend hold | dpkg --set-selections

Then an "apt-get dist-upgrade" will tell that the mythtv-backend has been held back, and you can (build and) install a new version.

Don't fall a sleep

Software in place tested that it worked with exit 0 / exit 1. Decision time, then shouldn't it shut down.

1. When rebuilding/resyncing raid
2. When users logged in
3. When data disk has been active within the last, lets say 5 min
4. When remote has been used within the last 5 min

1 & 2 are dead given, if the raid isn't complete or you're logged in, you just don't it to shut down prematurely. 3 was mainly to give some time before shutting down after playback of recording has completed. 4 I didn't think was necessary, but in 2 cases I've been struck by this.

1. Playback completed, rewound played ending again, and stopped. Unfortunately all data was cached and the disk hadn't been used for the last 5 min. Shutdown!
2. Fired up the computer to schedule some recordings (no other computer booted), found a couple of shows, and 5 min in, no disk activity. Shutdown while editing a recording schedule.

Disk Idle Check

Run from cron every minute: myth-disk-status.bash that checks a list of LVM volumes disk statistics and if they haven't been used for 5 minutes set the state to idle.

Remote Idle Check

The myth frontend has an option to run a command every time a key has been pressed on the remote. It's called "LircKeyPressedApp". Unfortunately it doesn't seem to work, so I've reported a bug. Instead I run a small script from /etc/rc.local: myth-remote-monitor.bash, which touches (creates) a file every time a button on the remote has been pressed. And alongside the disk-status script there's a myth-remote-status.bash, which also is run every minute, and stores a state of idle or busy.

Pre Shutdown Check

The pre shutdown check is set to this: myth-pre-sleep.bash, which runs the 4 checks.

Slave - "currently not connected"

Every once in a while (rescently every time) the slave shuts down, the masterbackend declares it "currently not connected" instead of "currently asleep". This has previously been handeled by the myth-reload-wake.pl script. But I've now found the culprit. The "/etc/init/mythtv-backend.conf"s respawn option (ubuntu 10.04+).

When the slave shuts down as ordered by the master, the init process sees it as the mythtv-backend dies and respawns it. If your setup is sufficiently fast, the newly spawned backend connects to the master yelling "I'm back", and then gets killed by the init system. Which the masterbackend interpids as the backend crashed. The trick is to make a shutdown script like this:

#!/bin/bash

sudo /sbin/shutdown -h now
sudo /sbin/stop mythtv-backend

And it's needed to run the shutdown first, since the stop also terminates the shutdown script.

Every once in a while, the masterbackend also looses the connection to the slavebackend listing it as "currently not connected". I've only seen it a couple of times, usually when the slave has been shut down for loooong periodes. Like the weeks where there's nothing on but Soccer World Cup and reruns (slave has been shut down for more that 4 days straight).

This is handled by this script myth-reload-wake.pl, which is mostly a hack, unfortunately I don't know when it looses connection, which makes it hard to locate. I have a sneaky suspicion that it's related to logrotate, but has nothing but a gut feeling to claim this. the script is run from "/etc/cron.d/mythtv":

*/5 * * * *     mythtv [ -e /usr/local/sbin/myth-reload-wake.pl ] && /usr/local/sbin/myth-reload-wake.pl

and looks at the mythbackend status, and calls "/usr/local/sbin/myth-wake-$SLAVEHOSTNAME.bash" (which is also used by the masterbackend to wake the slave):

exec /usr/bin/sudo /usr/sbin/etherwake -i eth0 xx:xx:xx:xx:xx:xx

And "/etc/sudoers" containing this (in the appropriate sections):

Cmnd_Alias WOL = /usr/sbin/etherwake -i eth0 *
...
mythtv  ALL=(ALL) NOPASSWD: WOL

Show me what's on

Some time ago the most used (in Myth context) danish tv-listing site changed layout. I made a drop-in replacement of the grab'er that uses JSON as this is the underlying transfer encoding to the webpage. That's just wolderfull to work with. The drop-in is called: tv_grab_dk_dr. A colleague and I have been using it for months, and it seems to be stable. I havn't sent it back to the XMLTV community, since I don't have the time to maintain it. But feel free to use it.

If you need to fill in xmltvids manually, to match up with the channels you can use this command:

tv_grab_dk_dr --list-channels --config-file /dev/null

To dump the correlation between the channel names and the id's.

I can recommend to make a script with statements like this:

#!/bin/bash

. /etc/mythtv/mysql.txt || { echo "Cannot source /etc/mythtv/mysql.txt" ; exit 1 ; }

sed '1,/^__SQL__/d' $0 | \
    grep -v '^#'   | \
    mysql -v -u$DBUserName -p$DBPassword -h$DBHostName $DBName

exit 0

__SQL__
UPDATE channel SET xmltvid="td2.dr.dk" WHERE name="TV2 Danmark";
UPDATE channel SET channum="3" WHERE name="TV2 Danmark";
# Set all icons
UPDATE channel SET icon=CONCAT('/home/mythtv/.mythtv/channels/', SUBSTR(xmltvid, 1, 3), '.gif') WHERE xmltvid <> "";

And run it as mythtv user (or root).

Especially if you're not quite sure you don't make mistakes and have to rescan the tv-channels.

/Bogeskov