My MythTV backend server. This thing may seem whimpy, but it’s not really meant to do particularly CPU-intensive tasks (other than commercial flagging and transcoding, which this thing can handle nicely). The real key is the paired hard drives, which are set as RAID-1 mirrors (I’d hate to lose all my recorded content thanks to a drive failure) beneath an LVM volume (for my purposes, basically RAID-0, but easier to manage).

The primary goal of this thing is expandability. Thus, I got a motherboard with 4 PCI slots, which is enough capacity to control 3 DSTBs.

Software

Thanks to a fantastic tutorial on installing MythTV on Fedora Core 5, it was a no-brainer to go with FC5 for the backend software stack. In addition, it’s running:

  • Apache, for use with MythWeb.
  • DHCP and TFTP, for diskless frontends.
  • Samba, so Windows boxes can mount the MythTV repositories.
  • Azureus with the Swing plugin running daemonized, which is used for downloading video directly to the backend.
  • vncserver, to allow remote configuration of the backend (it requires X).

I highly recommend going with Fedora for your backend… installation was an absolute snap, and was completed in short order with little difficulty.

In addition, I’m getting my guide data (the TV broadcast schedule) from Zap2It Labs. These guys have a terrific program which allows (North American) Myth users to download their high-quality guide data for free, provided they fill out a survey every three months. It really is a great service, and is an excellent example of a company coming up with a positive solution to a problem (in this case, Myth users screen scraping guide data from their website and generating excessive load as a result).

Update:

Well, so much for Zap2It. The go-to guys are now Schedules Direct. ‘course, this deal is actually even better, IMHO. $20 per year, but I get support as part of it. Sounds good to me!

Filesystems

Well, I started this thing off by basing my system on XFS. Large filesystems, fast deletes, it seemed like a pretty good idea. Since then, however, I’ve encountered a variety of stability issues, primarily when a lot of small writes and seeks are going on (for example, when downloading torrents directly to the MythTV RAID).

As such, my plan is to (eventually) switch over to traditional ext3, while enabling the incremental delete option in the backend. Hopefully this will resolve any lingering stability issues on the backend.

Update: Well, the switchover is complete. It was pretty simple:

  1. Using mdadm, fail the second disk in the mirror and remove it from the RAID.
  2. Create a new RAID with the previously failed disk.
  3. Using lvm, create a new Volume Group, Logical Volume, and Physical Volume using the new RAID (ignore warnings about it thinking this is part of an existing LV, and make sure to quit and restart lvm after creating the PV… the mirror confused it).
  4. Format the new volume as an ext3 filesystem and mount.
  5. Copy data from old volume to new one (this took a long time). Make sure to monitor disk space… ext3 isn’t as efficient as XFS, so I had to delete a few things.
  6. Delete the old VG, LV, and PV.
  7. Stop the old RAID.
  8. Add the remaining disk to the new RAID as the second disk.
  9. Fix fstab.
  10. Mount new volume at correct position in filesystem.

Et voila!

DSTB Tuning

One problem with any unofficial PVR device (ie, one not supplied by the cable operator), is the inability to directly tune digital cable channels. You see, these channels are encrypted and QAM modulated (no, you don’t need to know what that means :), and so they can’t be tuned directly, hence the need for a digital settop box. Thus, digital cable subcribers need to wed their backend server with a DSTB (or DSTBs, if multiple tuners are involved), in order to get the video.

But here’s the rub: now you need to be able to control the DSTB, in order to perform channel changes! Thus, we come to the IR blaster. This is basically a computer-manipulated remote control which allows your backend to manipulate the DSTB through the standard IR interface. Cute, eh?

And the best part? The guy who runs irblaster.info has done a fantastic job creating specially designed, custom-built IR blaster devices for just this purpose, which attach directly over the DSTB IR receiver and can be controlled through the serial port on the backend server. They work like a charm, and are perfectly compatible with Linux when used in conjuction with LIRC.

Of course, driving multiple serial port blasters (as in my setup) can be a bit tricky. See, LIRC uses IR device drivers in the form of kernel modules. But only a single module with a given name may be loaded at a time, which means that the lirc_serial module can only be loaded once. Thus, you have to hack up the code to compile additional copies of this module, each with a different name, so that they may be loaded at the same time. Fortunately, there are a few recipes out there for doing this (though, I just hacked up a solution for myself).