On my recent travels, I read an article in an in-flight magazine titled "Digital Studs and Duds," which panned the idea of putting a computer next to the TV, saying that "if your computer is next to your TV, the first website it should take you to is one that teaches you to overcome your interior-design problems." Even as it mocked those of us who have computers specifically designed to handle our televisions, it told us that DTV was like "discovering the secret of the universe. Only better." In mid-flight, I quietly snickered to myself because my case looks quite nice, and a MythTV computer makes HDTV much better.
In the first article in this series, I went through picking out the hardware for my new machine. Now, it's time to make the software work. Once again, I'll need to break with the guide put together by the Electronic Frontier Foundation. I tried KnoppMyth, but it didn't work straight out of the box. After my failure with KnoppMyth, I started working on a traditional operating system installation so that I had better control. This article is the story of the software installation and basic configuration.
The biggest constraint with using an Athlon64 is that I needed to use a distribution that supported the x86_64 architecture. I didn't put too much thought into it. I chose Fedora Core because it was well documented by Jarod Wilson's MythTV on Fedora Howto. I was able to follow the first half of the Howto closely until some architecture-dependent problems cropped up. I finished off the system by compiling several packages directly from source, which made the final system an odd mishmash of packaged software and locally-built software. I rushed through the last few steps because I was about to take a month-long business trip. As I looked forward to, or dreaded, the many long plane flights ahead, I wanted to have the ability to export video to my laptop.
Partway through my first stop, I logged in remotely to my machine. As it sourced my profile, I received ominous error messages like "/bin/grep: unable to execute binary file." A touch of digging through the log showed that my system had been invaded, and a root kit installed. Although I had only exposed the ssh daemon to the outside world, it was enough. My system was taken over too badly, and I shut it down remotely.
When I returned home at the end of the trip, I restarted from scratch. I returned to the list of Linux distributions that supported the AMD64 architecture, and decided to go with Gentoo for two important reasons. The major reason is the high level of control over the software packages that get installed, which keeps the system simpler and easier to understand, as well as conserving disk space. Gentoo is also easy to keep up-to-date, and I knew from my experience with the first Fedora-based system that a more recent kernel would be welcome. Many of the drivers that are useful to MythTV are available as part of the 2.6.12 kernel distribution.
A secondary reason for Gentoo is that packages get compiled from source, and can be optimized to the hardware in use. HDTV playback is a taxing process, which makes any performance optimization worthwhile. The main drawback to compiling everything directly is that the installation process takes a much longer time, especially if you need to compile the X Window System.
The long build time is mitigated somewhat by Gentoo's package system. If you ask for a high-level package name, it may install a large number of required prerequisite packages. Although it takes a long time to build the X Window System, it is somewhat easier if you can set the system to the task overnight.
The package system also keeps track of multiple versions of the same package. Newer versions of many packages, especially those under heavy development, are flagged as unstable, and must be specifically requested.
MythTV needs a lot of space to store video streams. With HDTV, count on five to seven GB per hour of TV. Some of that can be recovered with transcoding after the program is complete, but expect the system to suck up as much disk space as you can find for recordings. The Linux Logical Volume Manager (LVM) allows you to create a "virtual" disk that is supported by several physical partitions. I store my video streams in /video, which is an LVM partition. If I ever need more space to store recordings, I can just drop in another disk and add it to /video.
Both /boot and / are ext3 file systems, which is the native Linux file system. ext3 is not the best file system for large files, though. I am currently using ReiserFS, which is a good all-around file system, though its large-file deletion performance is not quite as good as XFS or JFS. At some point, I may do a comparison of file system performance and change the type of filesystem in /video.
I am using a custom-built kernel. The main modifications I needed were customizing the build to my processor (with AMD64 extensions and the CPUfreq driver to enable throttling down the CPU when idle), a change to the I/O scheduler to improve disk performance, and the video subsystem (both Video4Linux and DVB support, with necessary hardware drivers). My current kernel configuration is here: mythtv-kernel-config.txt.
For maximum performance on an nVidia graphics card, you need to use a binary-only kernel module. Some glue code needs to be compiled against the current kernel, but the build process is quick. The driver can be retrieved directly from nVidia's website, but Gentoo also makes it available as a package. Just type "emerge nvidia-driver" to install it.
By default, the package system will install the latest driver marked stable, which is version 6629 from November 2004. The absolute latest driver, from June 2005, has much faster performance, but is marked unstable, and requires special configuration to unmask it. In a simple test of the frame rate with glxgears, I found the difference between the 6629 driver and the 7667 driver to be about 50 percent (1,400 frames per second versus 2,000 frames per second).
During troubleshooting, one of the nifty features of the nVidia X driver is that it can simultaneously output to multiple devices through the same card. I have an external monitor hooked up to the VGA port, as well as a TV hooked up to the S-Video port. Each is a "screen" to the X server. I have configured an nVidia extension called TwinView for simultaneous display on both the TV and the monitor.
Configuring TwinView is, for the most part, straightforward. Each display is given a mode line, and the TV display must be told what type of TV is attached. Mine uses NTSC, which is the U.S. standard, though the driver supports many different TV standards throughout the world. The one wrinkle with simultaneous display is that TwinView can confuse programs using the X server because it works in part by assembling a virtual display from the physical displays. When watching 16:9 HD broadcasts on a standard-definition TV, they will be distorted unless the Xinerama X server extension is disabled. The key modification to my X configuration is in the usage of the display device, which enables TwinView:
Section "Device" Identifier "Videocard0" # -- NVidia-accelerated driver Driver "nvidia" VendorName "Giga-Byte" BoardName "NVIDIA GeForce FX 5200" Option "TwinView" Option "TwinViewOrientation" "Clone" Option "ConnectedMonitor" "CRT,TV" Option "SecondMonitorHorizSync" "30-70" Option "SecondMonitorVertRefresh" "60" Option "MetaModes" "1024x768, 1024x768" Option "TVStandard" "NTSC-M" Option "TVOutFormat" "COMPOSITE" # -- Disable xinerama extension for TwinView Option "NoTwinViewXineramaInfo" "true" EndSection
One of the best ways to reduce the resource requirements for displaying HDTV is to offload some of the graphics processing from the system CPU to the graphics card. When the XVideo-Motion Compensation (XvMC) extension is used, parts of the video decode are done in the graphics hardware. Unfortunately, there is a bug in the latest nVidia AMD64 driver that prevents XvMC from working. For now, I am stuck with software decode. (nVidia released a new driver on August 9, but I have not had a chance to test it yet.)
Although I am old enough to remember television without remote controls, I do not have fond memories of it. Without a remote, MythTV is cumbersome. Getting up to walk to the keyboard to fast-forward through commercials defeats the purpose of having a powerful TV-playback device.
Linux Infrared Remote Control (LIRC) software turns a PC into a universal receiver. By programming LIRC with the codes from your remote, the PC can respond to any remote you already own. Flexibility presents a challenge. I use a universal remote control, which is designed to adapt to the equipment it is configured to control. If the equipment is a universal receiver, it will expect to adapt to the remote control, presenting a slight chicken-and-egg dilemma. To get a remote working with basic functions, I used my TiVo remote, though I plan to set the system up with my universal remote in the future.
As a receiver, I selected the Home Electronics IRA-3. Hardware installation of the IRA-3 is a snap because it simply plugs into a serial port and draws power from it. There is a small red light that comes on when the receiver is powered up, and it blinks when an IR flash is detected. The IRA-3 uses the IRMAN protocol, which requires the use of libirman on Linux. However, one slight modification is necessary. The IRA-3 has a longer startup delay than the brand-name IRMAN device, as described by Pratap Pereria in a message to the LIRC mailing list.
To use LIRC with the IRA-3, first build the libirman library with this patch: ira3.patch.txt. I tinkered with the emerge build instructions for libirman to get the patch applied automatically as part of the installation process. By default, LIRC will build with support for generic serial devices, so change the build process to support irman devices. On Gentoo, this is done by setting the USE flag. When compiling from source, it is an option to the configuration script.
On startup, the main software process needs to be passed the -H flag to select the right driver. I have also found that the serial driver needs to be in control of the port. If lircd doesn't start, try configuring the port to be under control of the serial driver with a command like "setserial /dev/ttyS0 uart 16550."
I have used the Advanced Linux Sound Architecture (ALSA) with MythTV, and it's clearly the way to go. My nForce3-based motherboard has an nVidia CK8S chip for built-in sound, which is supported by the intel8x0 driver in ALSA.
The nForce sound chip can provide both regular analog stereo output as well as digital output. Sound is configured for each user with the .asoundrc file in the user home directory. The definitive configuration file for nForce motherboards is found here. I have used it successfully on an nForce3 motherboard, even though the title says it is for nForce2 and nForce4 motherboards. I am currently using analog stereo output, and a future home theater upgrade will use the 5.1 audio capabilities.
With ALSA, the audio mixer is muted by default. On many distributions, you must use alsamixer to unmute the mixer channels and turn the volume up, otherwise there will be no sound. Some distributions also require that these settings be saved on shutdown. Gentoo includes scripts to start up and shut down ALSA that automatically save and restore audio settings.
Recording TV is only useful if it starts and ends at the correct time. Many recording devices have a way to update their clocks for accuracy. One of my VCRs uses a time signal from PBS. Network devices can use NTP. (In fact, one of the first steps when a TiVo connects to the TiVo service is a time update from NTP.)
I installed two NTP programs, following the Gentoo NTP HOWTO. The ntpdate program is a one-shot time update that runs as part of the system boot process, and updates the time. On an ongoing basis, I use ntpd to keep the system clock accurate.
The Silverstone LC03V case has a small vacuum fluorescent display (VFD) panel with a parallel port connector. Support for LCD devices on Linux is provided by LCDproc. MythTV can control an LCD panel through LCDproc. In most cases, it will display the time. With NTP configured, the LCD panel became the most accurate clock in the house.
LCDproc has drivers for many common display-control chips. The LC03V uses the NEC D16314AGJ, which is fully compatible with the Hitachi HD-44780. When configuring LCDproc, I configured the HD-44780 driver. By default, it is set up for a two-row panel with 20 characters. The LC03V has only a sixteen-character display, however. I also had to use a ConnectionType of "winamp" to make the screen light up.
# LCDd.conf # [server] Driver=HD44780 Bind=127.0.0.1 Port=13666 User=nobody # All clients can control backlight Backlight=open InitialBacklight=on BacklightBrightness=255 BacklightOffBrightness=0 [HD44780] # I/O port. 0x378 is the usual place for the first parallel port Port=0x378 ConnectionType=winamp Size=16x2
Before installing MythTV, you need to get all the prerequisite pieces in place. First, you will need to build a custom kernel with the features needed to support MythTV, most notably support in the kernel for video capture. You will also need to install the Qt toolkit, LAME, and MySQL. While it is possible to compile MythTV from source code, there are also many package systems that will check dependencies and fetch everything for you. On my Gentoo box, I issued the command "emerge mythtv" and it went off and fetched everything, though it was quite time consuming to compile several of the intermediate steps. Before setup, it will also be necessary to sign up for a free account with Zap2It Labs; see the MythTV HOWTO for the sign-up code.
There are two threads of development in Linux video. The older API, Video For Linux (V4L), supports mainly older video capture cards. The newer API, the Digital Video Broadcasting (DVB) API, was originally designed for cards that support DVB, the European standard for digital TV broadcasts. Initially, the DVB API was designed only for DVB cards, but it is generic enough that it now supports many capture cards, including the HD-3000.
I chose the DVB driver because it looks like will be the main development platform for video capture cards in the future. Starting with kernel version 2.6.12, DVB drivers for the HD-3000 are included in the kernel source tree. To configure the kernel, DVB must be enabled. However, the driver for the HD-3000 is selected under the Video for Linux configuration. When the right module is selected, an option to build a DVB driver will be revealed.
The driver is not the end of the software support for the card. In addition to a driver, the HD-3000 needs firmware loaded every time it starts. The Linux hotplug system can download firmware from /lib/firmware every time it starts. The firmware is the only component that must be copied from the HD-3000 CD or downloaded from the Web site. There are two different firmware versions for the API in use, so be sure to get the DVB firmware.
When the system first attempts to use the HD-3000, it will need to load firmware. Firmware load is accompanied by a pause as the firmware is located and loaded into the card, and it looks as if the system hangs. Firmware loading is only required once. If the MythTV software crashes, it can be restarted without needing to load firmware on the cards.
When I first went to scan the airwaves and create a channel lineup, I added a splitter into my antenna system. I have one antenna, and I split the signal in three parts: one to my existing digital TV receiver and TiVo (as described in my earlier article), and two separate feeds for the two tuners in the MythTV machine. A four-way splitter, though, splits the signal four ways, so even strong signals start to fade away. Once I replaced the splitter with a ChannelMaster 3044 distribution amplifier, though, most of the signals were strong enough to lock on to.
MythTV organizes channels through the Zap2It guide data. Every channel throughout the country is given a number, the XMLTVID. When the DVB drivers are used, MythTV does not learn the XMLTVID numbers for DVB channels. You will need to retrieve the listings from DataDirect, note the XMLTVID number, and then copy it into the scan results for the DVB card.
At this point, I had a running system, though not one that performed well. Straight off the installation, performance was inadequate when playing back full high-definition recordings, and I had a problem with setting up the audio on one particular channel. In the next installment, I'll write about performance tuning, and some of the major troubleshooting to get the system running well enough to be usable on a daily basis.
Return to digitalmedia.oreilly.com