Posts Tagged ‘mythtv’

IRMan serial infrared receiver in Fedora 18

June 18, 2013 Leave a comment

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:

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


MythTV Airplay with iPad

August 3, 2012 Leave a comment

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 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

August 3, 2012 1 comment

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:

This is basically the file I ended up with:

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

July 23, 2012 Leave a comment

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

January 27, 2011 Leave a comment

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:
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)

Read more…

Technotrend C-1500+Technotrend CI+Conax CAM

January 19, 2011 5 comments

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 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

Read more…

Setting up your remote control for MythTV

January 16, 2011 Leave a comment

The remote control receiver I use for my MythTV setup is a 10-15 year old IR-receiver called IRMan, which attaches to the COM-port. The software I use with the receiver is lirc.

You probably want to mainly follow the instructions here. But I’ll list a few pointers here nevertheless, in case you have any issues with the instructions on that page.

  • Make sure you have lirc installed
  • Make sure lircd is not running (in Fedora type service lirc stop)
  • You need to create a configuration file /etc/lirc/lircd.conf that maps all the keys of your remote control, you can do this with the following command:
irrecord --driver=irman --device=/dev/ttyS0 /etc/lirc/lircd