IRMan serial infrared receiver in Fedora 18

Fedora 18 broke my IRMan serial infrared receiver. It no longer seems to use the configuration defined in /etc/sysconfig/lirc.

Instead, you apparently need to specify the configuration directly in the daemon script /usr/lib/systemd/system/lirc.service:

So I set the correct driver and device parameters in that script:
ExecStart=/usr/sbin/lircd –driver=irman –device=/dev/ttyS0

Also, I found that Fedora 18 no longer automatically started the lirc service after the upgrade. So you need to enable it:
systemctl enable lirc

This should work after a reboot…

If it doesn’t you can try to kill all lircd instances and run:
/usr/sbin/lircd –driver=irman –device=/dev/ttyS0

followed by:
irw

This should produce output whenever you press a button on your remote.

MythTV Airplay with iPad

I installed MythTV 0.25 without even realizing that it actually had support for airplay. It is a feature that is very easy to miss unless you read the change log, because there are no visible menus or settings for it. Anyway, this means I can now stream video and music from my iPad to my TV. This is really cool! I can start a clip on youtube and then just set MythTV as the output device. Or use Spotify on the iPad and output the music to my stereo. There still seems to be some issue supporting all types of content though, for example photos don’t seem to work. Also, outputting video from some apps doesn’t seem to work with MythTV.

When setting up, I followed the instructions on http://www.mythtv.org/wiki/AirTunes/AirPlay. I had some additional issues with the networking. I have two network interfaces in my MythTV machine, this caused some issues because MythTV isn’t on the same network as my iPad is. So I needed to change the mythtv backend address to be one that the iPad can reach. I also had some issues setting up the firewall. Strangely, I couldn’t find any instructions exactly what ports are required. Based on trial and error, I found that this iptables configuration seems to work:

-A INPUT -p udp -s <insert-ip-for-local-machine-that-is-reachable-by-ipad> –dport 5353 -j ACCEPT
-A INPUT -p tcp -s <insert-ip-for-local-machine-that-is-reachable-by-ipad> –dport 5100 -j ACCEPT
-A INPUT -p tcp -s <insert-ip-for-local-machine-that-is-reachable-by-ipad> –dport 5000 -j ACCEPT
-A INPUT -p udp -s <insert-ip-for-local-machine-that-is-reachable-by-ipad> –dport 6000 -j ACCEPT
-A INPUT -p udp -s <insert-ip-for-local-machine-that-is-reachable-by-ipad> –dport 40000:65535 -j ACCEPT

 

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!

MySQL server has gone away

I recently began getting failed MythTV recordings a few times per week (MythTV version 0.23.1/MySQL version 5.1.47). When I looked in the mythbackend log I found that there was some underlying database connectivity issue. The logs would fill up with error messages like these:

2011-01-16 05:26:30.699 Error preparing query: SELECT chanid, useonairguide FROM channel, dtv_multiplex WHERE serviceid=:SERVICEID AND networkid=:NETWORKID AND transportid=:TRANSPORTID AND channel.mplexid=dtv_multiplex.mplexid AND channel.sourceid=:SOURCEID
2011-01-16 05:26:30.699 Driver error was [2/2006]:
QMYSQL3: Unable to prepare statement
Database error was:
MySQL server has gone away
2011-01-16 05:26:30.700 DB Error (Looking up chanID):
Query was:
SELECT chanid, useonairguide FROM channel, dtv_multiplex WHERE serviceid=:SERVICEID AND networkid=:NETWORKID AND transportid=:TRANSPORTID AND channel.mplexid=dtv_multiplex.mplexid AND channel.sourceid=:SOURCEID
Bindings were:
:NETWORKID=42249, :SERVICEID=3, :SOURCEID=1, :TRANSPORTID=5
Driver error was [2/2006]:
QMYSQL: Unable to execute query
Database error was:
MySQL server has gone away

The system did eventually recover (within an hour or so), but all recordings during this time would fail to start. Interestingly enough, they would still manage to get inserted into the table of recordings. To me this indicates that there is still partially functioning database connectivity. Even though the message says that MySQL server has gone away, I could perfectly well connect to the database during the time that mythbackend was filling my logs with these kind of errors. My conclusion was that the problem was with the database connections between mythbackend and MySQL, not with MySQL itself.

So, I began investigating what could be the cause of these errors. What I found was that MySQL has a timeout on all database connections that’s by default set to 28800 seconds (8 hours).

To see your connection timeouts, do this:

mysql> SELECT @@global.wait_timeout, @@session.wait_timeout;
+-----------------------+------------------------+
| @@global.wait_timeout | @@session.wait_timeout |
+-----------------------+------------------------+
|                 28800 |                  28800 |
+-----------------------+------------------------+
1 row in set (0.00 sec)