Tales From The Geek Side

This spring I finally bought a modern receiver. My new receiver, like nearly all modern receivers, has multiple digital inputs. My Myth frontend machine is based on a VIA M10000 board which has a SPDIF (digital) output. There are a lot of reasons to use a digital output. One is that I suspect the digital to analog converters in the receiver are much higher quality than the cheap on-board ones found in most computer systems. Also if you watch DVDs or HDTV through Myth you can get Dolby Digital (AC3) and DTS multi-channel audio. I personally do not use MythTV for DVD watching nor for HDTV (without transcoding which trashes the AC3 audio stream) but I still wanted to use the digital audio output.

The basic setup steps are:

1. Identify the correct jumper settings to enable SPDIF output on the VIA M10000.
2. Test digital audio connection using basic ALSA tools.
3. Setup MythTV to use SPDIF output device.
4. Setup alsa to re-sample audio to 48000Hz.

Read the rest of this entry »

Today I paid my $15 to Schedules Direct.  That gives me three months access to their TV listing data which I use for MythTV.  The offer a free 1 week trial that I signed up for not too long ago.  When I paid my $15 via credit card through paypal I was surprised to see that my listing service was extended by three months.  I assumed they’d truncate the remainder of my trial period but they did not.  Their site reports that they have reached their break even point and it seems likely that they will be able to reduce the cost of the service to $20 per year.

Today I setup a trial account with Schedules Direct and configured my MythTV backend to use my lineups from Schedules Direct.  It went very smoothly.  The steps were:

• Create an account with Schedules Direct.  They offer free 1 week trials.  After a few days I’ll pay for 3 months.
• Update backend to latest from debian-multimedia.org
• Run mythtv-setup to change channel lineup source
• Run mythfilldatabase to grab listing information
• Test

Note that I did not have to update my myth frontends!
I had no hiccups at all along the way.  I was pleasantly surprised to find a nice simple interface for creating and managing lineups at schedules direct.  The only thing I’d like to see is a way to change the names of lineups.  I have an HD tuner card and an analog tuner card.  I like having a digital lineup and an analog lineup — both lineups are broadcasts.  To do this I have to use two different zip codes.  The result is that the names of the lineups are almost identical though the zip code is added to the name.  However, in mythtv-setup I can’t SEE the zip code (it’s truncated).  That makes setting the lineups a guessing game.

Last night I upgraded my custom built 2.6.17 kernel to the Debian built 2.6.18 kernel.  I had to do this because I run XFS and I was getting directory corruption.  This is a known bug in 2.6.17 that I covered in a previous post.

The most critical role of my file server is that of a MythTV backend.  I have a PC HDTV-3000 card and a PVR-150 card for DTV and analog tuners.  After repairing my corrupted file systems and installing the Debian provided ivtv-modules-2.6.18 package I found that I couldn’t tune my analog stations anymore.   In fact I found that the backend was crashing whenever I tried to view the tuner status in the information section from any frontend in the house.  It turns out the problem was that my drivers are loading in a different order now.  My PVR 150 card used to be /dev/video0 but has become /dev/video1 (or vice-versa).  A quick change in mythtv-setup fixed the problem and now I’m off and running again.

I was very happy to discover that Debian provides ivtv binary packages now.  I do not have to build any software for my backend machine now!  For the frontend I still have to build lirc-modules but I can live with.

I’ve always been annoyed that mythtv-setup is a GUI application.  It’s a tool to configure the backend.  The backend doesn’t need a GUI.  I would really prefer to edit a text file.  Oh well, you can’t have everything (for free!).

On my MythTV backend machine I run XFS file systems. Not too long ago I updated the system in an effort to finally start using the HDTV tuner card that I purchased a year prior. At that time the ivtv drivers for my PVR 150 tuner card required kernel 2.6.17 so I merrily built 2.6.17 and life has been good.

I’ve recently been testing a SATA controller card. The onboard SATA on my motherboard has a firmware bug that causes disk corruption when copying large data sets between drives. It’s an Abit NFS-7s that I bought used. I could upgrade the BIOS to fix this bug but I’m afraid to! My wife and I use MythTV nearly every day and we’d both be upset to go without it. I’m afraid that the BIOS upgrade process would fail and I’d be forced to buy a new motherboard when I really don’t want to. Also this machine acts as an NFS root for my desktop machine and my Myth frontend machine.

The XFS bug came to my attention while testing a SATA card to correct the firmware bug mentioned above. I have two 300G drives and I use rsnapshot to keep incremental backups. Because of the firmware bug I wasn’t able to do this and my spare 300G drive has sat idle for quite some time. My backups have been to a smaller IDE drive. To test the SATA card I’ve been using the spare 300G drive as the backup disk. With the onboard controller I found corrupted file systems very quickly. With the new controller I thought I was free from corruption until I ran xfs_check on the backup partition.

xfs_check found a handful of problems with directories. Googling I found this page from SGI that describes the bug. The bug exists in 2.6.17 and was fixed in 2.6.17.7.

I built a new 2.6.17.14 kernel to correct the XFS problem and I’ll hopefully run xfs_repair this evening on all of my file systems. Version 0.3 of the excellent System Rescue CD includes xfsprogs new enough to handle the problem. This bug bit me because I was using XFS and because 2.6.17 was required for the PVR 150 card.

Edit: I think I’ll probably use the 2.6.18 kernel from Debian. I also see that Debian has an ivtv-modules-2.6.18-4-686 package as well which should be perfect. I’d much rather use stuff from Debian than build things myself.

I can’t figure out why yet but my PCHDTV 3000 card stops working.  I suspect it’s the cx88 or related modules because I can get the system working again by removing the modules and then inserting them again.  Twice I’ve gone to watch some recordings to find Myth reporting that it “can’t find the file associated with the recording.”

Luckily I rarely record using the HD3000 card.  I don’t have an HDTV yet so I don’t have a huge reason to record in HD except for the perfect bit-for-bit recordings that result.  I’m happy with the analog recordings on my current TV and it’ll be a couple of years before I upgrade my TV.

Mytharchive is written to assume that the backend and the frontend machine are the same. To work around this I do the following:

1. Use a frontend to select recordings for export. I specify the output to be an iso image.
2. Allow mytharchive to fail. Then copy /tmp/config/mydata.xml to the backend machine
3. Install mythfrontend on the backend machine (grrrrrrr I HATE THIS but it is necessary because mythreplex is required and found in the frontend package)
4. On the backend machine modify /usr/share/mythtv/mytharchive/scripts/mythburn.py at line 134 by hardcoding the hostname of my frontend machine so that the configuration options are correct. Note that you will still have to insert a RecordFilePrefix entry into the ’settings’ table of the ‘mythconverg’ database for the frontend host. Mythburn.py uses this setting to find the recording files.
5. On the backend machine create $MA_TMP/logs and $MA_TMP/work where $MA_TMP is the directory that you configured as thetemp directory for mytharchive in the mytharchive setup options.
6. On the backend machine, as the mythtv user, run /usr/share/mythtv/mytharchive/scripts/mythburn.pl using the mydata.xml file that was created in /tmp/config on the frontend machine

After doing all of that you should have an iso image in /tmp/work/mythburn.iso on the backend machine. I then burn that to DVD over NFS.

The other night I switched my my Via M10000 based frontend to use the Retro MythTV theme (after I had learned that msttcorefonts is required for this theme). I also enabled OpenGL. Everything seemed OK, I even watched a recording or two. Then it started crashing left and right. I disabled OpenGL and I still had stability issues. Finally I gave up and reverted back to the good old Blue theme with no OpenGL. Now it’s rock-solid stable again.

The mytharchive plugin for mythtv is supposed to make exporting data from MythTV easy. My experience with mytharchive is not favorable. First, the GUI is very unintuitive. That’s partly because the GUI is not expected to have a mouse and designing a decent GUI for cursor controls isn’t easy. However, this GUI is just plain hard to use.

When I finally got to the point of creating a DVD mytharchive errored out. After looking at the source code for a while I found that it was because MythArchive wanted a value for ‘RecordFilePrefix’. That setting applies to the backend and tells myth where to store files. This was a big red flag because it meant that mytharchive expects files to be present to the local system. My myth frontends do NOT reside on the same machine as the backend. Ugh #1.

To resolve Ugh #1 I nfs mounted /var/lib/mythtv. I then inserted a ‘RecordFilePrefix’ to the settings table of the mythconverg database for the frontend that I was working with. That got me past the first problem.

Finally the DVD creation process started. It started and promptly stopped with a new error. This time it errored out because it couldn’t run mythtranscode which, again, exists on the backend and not on the frontend. At this point I had to give up all hope of running Mytharchive on the frontend.

My current approach is a nasty hack to get mythburn.py to run on the backend by messing around in the settings database until all of the incorrect assumptions made in the code are satisfied.

If you attempt to use the Retro theme for MythTV and you do not have msttcorefonts installed you will have no menu text. The debian-multimedia packages for this theme suggest msttcorefonts but they should be a dependency.