MythTV failing recordings and device mappings

After upgrading from FC12 to FC16, I began having some issues with failing recordings. After boot, recordings from certain channels would always fail (in this case channels using DVB CAM).

My setup is this:

• “ST STV0297 DVB-C” -> Free channels
• “ST STV0297 DVB-C” + CAM -> Pay channels
• “Philips TDA10023 DVB-C” -> Free channels

I had mythtv configured that my CAM card is on /dev/dvb/adapter2/frontend0.

What I eventually figured out was that after the upgrade from FC12->FC16, my DVB CAM card was no longer always being assigned the above adapter2 mapping. Instead, the hardware used for “adapter2” kept on changing each boot:

Jul 21 14:38:13 localhost kernel: [    7.187973] DVB: registering adapter 2 frontend 0 (ST STV0297 DVB-C)…
Jul 21 19:47:43 localhost kernel: [    8.625730] DVB: registering adapter 2 frontend 0 (ST STV0297 DVB-C)…
Jul 21 19:52:49 localhost kernel: [    8.572348] DVB: registering adapter 2 frontend 0 (Philips TDA10023 DVB-C)…
Jul 21 21:03:04 localhost kernel: [    7.606219] DVB: registering adapter 2 frontend 0 (Philips TDA10023 DVB-C)…

Still, mythtv assumed that adapter 2 had the CAM. This of course led to a situation where mythtv couldn’t record, because it didn’t have the hardware to decode the channel on the specified adapter. This was evident when watching live TV, the “LMSc” never changed to “LMSC”. The capital C means it’s successfully decoding.

So, basically, you need to fix this by manually assigning the device mappings. After doing that, I now have symlinks like these:

/dev/dvb/adapter-ttfree/frontend0 -> ../adapter0/frontend0
/dev/dvb/adapter-ttcam/frontend0 -> ../adapter2/frontend0
…

The instructions for setting up permanent device mappings can be found here: http://www.mythtv.org/wiki/Device_Filenames_and_udev

This is basically the file I ended up with:

/etc/udev/rules.d/55-dvb.rules
SUBSYSTEM==”dvb”, ATTRS{product}==”anysee*”, PROGRAM=”/bin/sh -c ‘K=%k; K=$${K#dvb}; printf dvb/adapter-anysee/%%s $${K#*.}'”, SYMLINK+=”%c”
SUBSYSTEM==”dvb”, ATTRS{vendor}==”0x1131″, KERNELS==”0000:07:01.0″, PROGRAM=”/bin/sh -c ‘K=%k; K=$${K#dvb}; printf dvb/adapter-ttfree/%%s $${K#*.}'”, SYMLINK+=”%c”
SUBSYSTEM==”dvb”, ATTRS{vendor}==”0x1131″, KERNELS==”0000:08:01.0″, PROGRAM=”/bin/sh -c ‘K=%k; K=$${K#dvb}; printf dvb/adapter-ttcam/%%s $${K#*.}'”, SYMLINK+=”%c”

Note, the file is hardware specified, so you need to create your own according to the instructions on the above page. Next reboot, you should have the device mapping symlinks setup correctly.

Now you just need to configure mythtv to use these symlinks instead of referring to adapterX directly. Personally, I deleted all mythtv capture card configuration and re-did it. I don’t think that’s strictly needed, but I just wanted to clean up my configuration a bit at the same time.

DVB subtitles missing

I did an upgrade from MythTV 0.23 to 0.25. After that I found that the dvb(-c) subtitles (Finland) would sometimes go missing from some recordings. The issue is not with the recording, but with the MythTV player. I wasn’t able to see subtitles on recordings that I had previously recorded and I knew had working subtitles. Also the subtitles could be seen with other applications, e.g. mplayer.

After getting quite desperate, I finally found a bug report that I believe is related to this. Apparently this fix wasn’t available in the Fedora repos yet, so I had to switch to rpmfusion repos to get this fix. After doing that, dvb subtitles are working again!

MythTV EIT language

I just upgraded from MythTV 0.23 to 0.25. One of the issues I noticed was that I started getting DVB EIT data with mixed languages. Living in Finland, we get EIT data in both Finnish and Swedish. I set the preferred languages in the MythTV frontend, but they didn’t have an impact. In my data I had listings in both languages.

This can be quite tricky because it will break recoding rules that record by title. Anyway, to get all of them in one language, I inserted the following configuration:

INSERT INTO settings(value, data) VALUES(‘PreferredLanguages’,’fin’);

You can clear the current EIT data by:

DELETE FROM program where starttime>now();

DELETE FROM eit_cache;

Then restart mythbackend, just to be sure. You should now get all the data in the language you’ve specified.

UPDATE: It seems that settings ‘ISO639Language0’ and ‘ISO639Language1’ must also be set to ‘fin’ in order to get non-mixed Finnish EIT data.

Technotrend C-1500+Technotrend CI+Conax CAM

I finally received my Technotrend CI module + Conax CAM order. So now I have the following hardware working (with some minor tweaks below): Technotrend C-1500 + Technotrend CI module + Conax CAM. These are my software versions: Fedora 12, kernel 2.6.32.21-168.fc12.i686 and MythTV 0.23.1.

Initially, I had some issues with recordings sometimes failing with the following error message in mythbackend.log:

2011-01-18 21:48:18.268 PID 0x1f9c status: Encrypted
2011-01-18 21:48:18.798 PID 0x1f9b status: Encrypted
2011-01-18 22:00:07.363 PID 0x44d status: Encrypted

Once I got this message, all subsequent recordings failed. What I quickly discovered was that if I restarted mythbackend, then the recordings would start working again. There seems to be some issue with the CAM or mythtv going into an invalid state if the DVB card/CAM is kept open for a long time.

So I changed the following mythtvsetup options under “2. Capture cards“:

Open DVB card on demand -> turned on
Use DVB Card for active EIT scan -> turned off
DVB Tuning Delay (msec) -> 2000
Tuning timeout (msec) -> 5000

Mythbackend deadlocks and auto-restart script

I recently bought two new DVB-C cards (two Technotrend C-1500). Until then I was using Anysee E30 Combo Plus. So now I have three cards altogether. As always, Linux and DVB hardware is a whole story in itself, I’ll write more about this upgrade in a later post. But anyway, I eventually got all three cards working together.

However, there seems to be some deadlock issue in mythbackend when you use multiple DVB cards. I’ve previously used multiple tuners for one card and never had an issue with that configuration. After I upgraded to three cards, every now and then (weekly) when a recording is ongoing and a new one is about to start or has just started, MythTV will deadlock. What I mean by deadlock is that it becomes completely unresponsive from mythfrontend and mythweb. Logs stop. There’s no particular error in the logs that would indicate any kind of problem. I do get an entry for the recording in the database, but the file it is pointing to doesn’t exist.

I found a ticket that sounds suspiciously similar, but the issue was fixed in revision 22814. According to the release notes, that fix should be in MythTV 0.23, which I’m using. Also, since the recording entry is inserted into the database, one might assume that it is not a scheduling issue?

I’m hoping this issue will go away with future upgrades, like these issues usually do. To handle the situation for now, I made a script to automatically restart mythbackend if it deadlocks or dies. This is a good idea to have even if your setup is relatively stable. You don’t want mythbackend to die shortly after you leave for that two-week vacation, and thereby miss all recordings, do you?

This is the mythbackend deadlock restart script I made:

#!/bin/sh
# print status
STATUS=`/sbin/service mythbackend status | grep -E "mythbackend .*is running"`
echo `date`: $STATUS
FILEDATE=`date +%Y%m%d_%H%M%S`
mv -f /tmp/mythbackend-status /tmp/mythbackend-status.previous
RESULT=`wget --timeout=10 --output-document=/tmp/mythbackend-status --retry-connrefused --tries=4 http://127.0.0.1:6544 2>&1`
if [ "$?" -ne "0" ]
then
        mv /tmp/mythbackend-status.previous /tmp/mythbackend-status.crashed.$FILEDATE
        echo -- ERROR: mythbackend is not responding... must restart: $RESULT
        echo `/sbin/service mythbackend status`
        echo `/sbin/service mythbackend stop`
        echo `/sbin/service mythbackend start`
        echo `date`: Restart done
else
        echo Service is responding: $RESULT | sed "s/Saving.*//"
        rm /tmp/mythbackend-status.previous
fi