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

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

Setting up your remote control for MythTV

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