Fedora 18 pulseaudio/ALSA and nvidia hdmi audio

Fedora 18 replaced my ALSA audio setup with pulseaudio. I managed to get the nvidia hdmi audio disabled, but I still had some issues when I used MythTV’s timestretch feature. The audio would start cracking and the video would also freeze every few frames.

So I decided to revert back to ALSA:
yum erase pulseaudio

This removed the following modules:
pulseaudio pulseaudio-module-gconf pulseaudio-module-bluetooth pulseaudio-esound-compat paprefs gnome-bluetooth bluez

The next problem was that my system was confused whether I wanted audio played through nvidia hdmi or my motherboard. In this case the motherboard is my option.

To fix this, I did “aplay -l” and took note of the card and device ids through which I wanted my audio. Then I put the audio device in /etc/asound.conf (make sure there are no overrides of this file in the user’s home directory):

pcm.!default {
type hw
card 0
device 0
}

Then I just set mythtv to use the correct ALSA device. After a restart, MythTV is now back to using ALSA audio again.

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 settings reset due to database problems

A couple of days ago I started getting wrong language EIT data – and therefore a lot of missed recordings (because the program titles had changed). This seemed very strange, because I had been getting correct EIT language data for over two months since the setup.

I then started investigating a bit more and noticed that ‘ISO639Language0’ and ‘ISO639Language1’ settings had been reset back to ‘eng’ (from ‘fin’). This seemed strange, so I started digging in my DB backups and was able to pinpoint a date when this reset had occurred. Then I looked at mythconverg.logging and found these entries:

mysql> select distinct message from logging where message like '%savesetting%';
+---------------------------------------------------------------+
| message                                                       |
+---------------------------------------------------------------+
| SaveSettingOnHost('FreqTable') - No database yet              |
| SaveSettingOnHost('ISO639Language0') - No database yet        |
| SaveSettingOnHost('ISO639Language1') - No database yet        |
| SaveSettingOnHost('TVFormat') - No database yet               |
| SaveSettingOnHost('VbiFormat') - No database yet              |
| SaveSettingOnHost('prefDupMethod') - No database yet          |
| SaveSettingOnHost('Country') - No database yet                |
| SaveSettingOnHost('DateFormat') - No database yet             |
| SaveSettingOnHost('EnableMHEG') - No database yet             |
| SaveSettingOnHost('Language') - No database yet               |
| SaveSettingOnHost('MythArchiveVideoFormat') - No database yet |
| SaveSettingOnHost('ShortDateFormat') - No database yet        |
| SaveSettingOnHost('TimeFormat') - No database yet             |
+---------------------------------------------------------------+

I then looked at the timestamp for those messages and looked at my mythbackend logs and found a bunch of these messages a few seconds later:

2012-09-14 18:00:43.237945 E [20573/17377] HttpServer245 mythdbcon.cpp:213 (OpenDatabase) - Unable to connect to database!
2012-09-14 18:00:43.237956 E [20573/17377] HttpServer245 mythdbcon.cpp:214 (OpenDatabase) - Driver error was [1/1040]:
QMYSQL: Unable to connect
Database error was:
Too many connections
2012-09-14 18:00:43.238098 I [20573/17386] HttpServer281 mythdbcon.cpp:808 (prepare) - MySQL server disconnected

So, what seems to have happened here is that mythtv was unable to connect to the database, so it somehow reset those values and they were eventually stored in the database, silently overriding the real configuration. This can be a quite nasty bug, with big unknown consequences.

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.