David Backeberg

MythTV is a homebrew PVR project. A PVR is a personal video recorder, much like a VCR, but far more powerful. Most Americans own a VCR, but few people have ever programmed their VCR. If you have, you would discover that you have few controls beyond setting what channel to record, when, and you're limited to a max of 8 hours per tape, assuming you have a high capacity VHS tape and you're setting it to the lowest quality recording speed.

A personal video recorder has many advantages, which are hard to understand without owning one. For starters, you can "pause" live tv, and then watch shows live, but with a delay. Some PVRs (MythTV for instance, but not TiVo) do very good, real-time commercial skip, which makes watching the 300 Simpsons episodes you've recorded fly by much faster. Did I mention real-time? Watching a show just a few minutes behind, MythTV can pick out the commercials and skip over them if there's a big enough buffer. MythTV also has support for closed-captioning, and can handle moving the captions to different parts of the screen.

In addition, a PVR has enhanced channel / television listings, which makes unattended recordings and channel surfing far more efficient. You can search by program name, and see every time your show will be on in the next two weeks, on any channel, for instance. You can record every episode of a show you like, but not record the reruns you've already seen. You can speed up and slow down television with perfect clarity, like a 4-head VCR on steroids.

How does MythTV differ from TiVo?

TiVo is a commercial appliance one must purchase from a TiVo retailer. In this way, TiVo is much like a VCR. A typical TiVo has a network connection which can be used to share video files with a computer. A TiVo, in most cases, has a single fixed capacity hard drive. Unlike a VCR, TiVo needs a subscription service to know television listings. Without these listings, the TiVo is much less useful. TiVo has recently dropped the price of their subscriptions, and you should consult their literature for actual price information for both the appliance and the subscriptions. You may qualify for a free TiVo appliance if you opt for a certain promotion run by your cable television provider.

MythTV is an open-source software project, which presumes that the user has their own computer hardware. One must have a computer system with a hard drive or access to a remote hard drive, network connectivity, and a television tuner / capture card. There are wide variations of the machine needed to process the video I / O, depending on the television tuner / capture card. TiVo, for instance, contains integrated circuitry that handles compressed video capture and playback of that compressed video. By offloading the hardest work to chips dedicated to this purpose, TiVo is able to contain a very weak cpu. If the tv tuner / capture card used for a system with MythTV doesn't contain integrated video compression / decompression circuitry, then this work must be taken on by the cpu, which may have other duties as well. For this reason, the less work done by the television tuner / capture card, the more that work must be done by the cpu, and therefore, the more powerful of a system the prospective MythTV user would require. Charts and examples are available on the MythTV website

As MythTV is an open-source software project, there is no cost for the software. There is also, at this time, no subscription fee to get the television listings. A website known as zap2it.com provides listings for free, as long as subscribers (meaning people who have signed up for a free account) fill out the occasional survey listing their viewing habits. Another advantage of MythTV is a free module called MythWeb, which allows the user to login to the system by remote from a web browser, and plan recordings, with almost all the same controls as if the user was present with the system.

The author thinks the single best feature of MythTV is it runs on top of linux, with all the power that entails. This means that instead of being limited to one hard drive, you're only limited by your budget and the physical limits of your hardware. The linux kernel supports very mature software raid, allowing ridiculously large amounts of television to be stored on the system. Running on top of linux also means the user can use scp, ftp, http, etc. to share videos with friends, all on the same machine.

Both MythTV and TiVo support remote viewing stations, where another unit can display video stored on a remote machine, perhaps stored in another room in your house. The difference is that for TiVo, this means buying another appliance. For MythTV, that junker system you've been using as a doorstop might be powerful enough to attach to a different television across your house and you now have a remote viewing station. Remote MythTV viewing stations do NOT need to have a television tuner / capture card. They don't really have to have a TV either, just a way to display picture, which could be a projector, or monitor.

Is MythTV for me?

Maybe. At present, I'm not aware of MythTV working on any operating system other than linux. If the prospective MythTV user is not familiar with linux, then they could easily be scared off by the prospect of what's involved in setting up and maintaining a MythTV system.

On the other hand, one can buy a computer system preinstalled with linux and MythTV from a number of people on eBay. There is much documentation in the world, and I'm hoping to contribute to that accummulation. If you have a lot of time on your hands, you're patient, you have a spare computer system and television tuner / capture card, and you want to learn a lot about linux and how computers work, MythTV may be just the project you're looking for.

I should also take a moment to say that I first set up a MythTV machine in 2003. Since that time, Mythtv.org and the drivers and documentation for my hardware have radically improved, along with the mythtv software itself. Much of this page used to detail weirdness I'd resolved, and how to customize kernels and drivers. My latest experiences are that almost none of that is necessary, and that's a credit to Open Source development, and the generosity of the hardware manufacturers in opening their specs so fully open drivers can be developed.

What are the Hauppauge PVR 250 and PVR 350?

The Hauppauge PVR 250 is a television tuner / capture card with integrated MPEG compression circuitry. This means that when MythTV wants to record a show, the cpu only needs to handle I / O to the hard drive, rather than also having to do MPEG compression, which could be taxing, depending on how powerful the system is.

Video decoding with a MythTV / PVR 250 system still must happen with the cpu. Enter the Hauppauge PVR 350. The 350 has the same MPEG encoder chip as the 250, plus an MPEG decoder chip. This allows a much weaker system to be able to run MythTV successfully.

When one purchases a Hauppauge PVR 250 / 350, they also get a remote control, and a cdrom containing Windows drivers. It used to be the case that portions of the circuitry on these cards were a secret of Hauppauge. Hauppauge has since changed their policy, and fully-open drivers are now integrated into the freely-distributed linux kernel. This was a long time coming, and makes working with the card much easier than it used to be.

What is the Hauppauge PVR 150?

A PVR 150 is a more recent version of the Hauppauge PVR x50 series, which seems to be cheaper than the PVR 250, but do the same things. Also, the remote control for the PVR 150 seems to have more functions than the remote that I own with my PVR 250. Hauppauge has also come out with the PVR 500, which seems to be two PVR 250s soldered onto a single PCI card. Theoretically, you could record two simultaneous shows using a single PVR 500 card. A drawback of the PVR 500 is that there is no remote control sensor. Some releases of the PVR 150 also do not come with a remote. A MythTV system can have multiple television tuner cards, so a system could have one PVR 250 card doing the remote control function, while perhaps watching the show being recorded by a different tuner. It is also possible to build or buy remote receivers that are compatible with linux, and not worry about remote support directly on the television card.

The ivtv driver support for the PVR 150 and PVR 500 are now supported, and other cards that use the same chips are also supported by the ivtv project.

What is the ivtv project?

THIS SECTION UNTIL THE END OF THE PAGE IS OUTDATED, AND NEEDS TO BE REVISED WHEN I GET AROUND TO IT. -Dave, Jul. 5, 2007. The ivtv project is an effort to make the PVR 250 and PVR 350 (and related cards) usable under Linux. The project only has published specifications from a portion of the chips used by the cards, and thus has had to reverse-engineer some of the way the card works to be able to write the driver. At present, the firmware used by the card is supplied by Hauppauge as a binary only, and thus, the ivtv driver as it exists at present will never be integrated into the linux kernel source code, as only fully open-source kernel code can be allowed into the freely-downloadable source tree.

Detailed specifications are available at the website, but the general idea is that as much of the driver that can be open source has been made open source. Development on the driver is VERY active, as you will quickly learn if you subscribe to the development mailing list. Revisions to the "stable" version seem to now be tied to the release schedule of the stable version of the linux 2.6 kernel. Thus ivtv 7.0 is designed for linux-2.6.17, and version 8.0 will work with linux-2.6.18.

While documentation is available, working with the ivtv driver is not for anybody frightened away by a command line. Also, documentation ends up getting outdated rather quickly, including mine. Thus, by the time a document makes it into a google search, it may no longer be true about the latest version of the ivtv drivers. One way to avoid this is to simply not keep up with the latest versions. I skipped between 2.6.14 and 2.6.17. Lots of things changed, and when I went to upgrade several things had changed, making the upgrade rather painful. Your milage may vary, but one idea is to get things working and swear you will never change the machine for a long time. This would be akin to using Mythtv / ivtv as an appliance.

I now successfully have 2.6.17 working with version 7 of the ivtv driver. There are several changes from the way ivtv used to work. Back in the 2004, almost all driver / module support needed for the card came in the ivtv project. As the kernel Video For Linux project has matured, individual chip support is now provided by code shipped with the kernel, and this support is therefore no longer provided with the ivtv driver, but must be built with the kernel.

A possibly better option is the KnoppMyth distribution, which combines MythTV with the Knoppix project, and also contains the ivtv drivers, and support for using the Hauppauge remote. I have not personally tried this distribution, but some people seem to rave about it. I made this page because I couldn't find the documentation I needed to troubleshoot why my formerly working ivtv drivers were no longer working, and what I should do to fix it.

How do I get a custom 2.6 kernel working with ivtv?

First step is probably obvious. Pull down the latest 2.6 kernel tarball from kernel.org, and extract it. I like to put mine in /usr/src

In earlier 2.6 kernels, it was necessary to patch the kernel with a patch provided by linux.bytesex.org, which provided certain i2c drivers and other things needed by the Hauppauge PVR cards. As of 2.6.13 or so, that patching step is no longer required.

Now you're ready to configure your kernel as normal. Ideally you already have a good idea of the stuff in the kernel you will need for your specific motherboard and components. ivtv-specific requirements include:

Driver Devices -> I2C support, built as a module (i2c-core)
Driver Devices -> I2C device interface, buult as a module (i2c-dev)
Driver Devices -> I2C Algorithms -> bit-banging-bus support, built as a module (this will automatically get built if you select other things properly)(i2c-algo-bit)
Driver Devices -> MultiMedia Devices -> V4L2 (Video for Linux) must be built as a module (videodev)
V4L2 (Video for Linux) module (videocore)

Sometime at or before 2.6.17 / release 7 of the ivtv drivers, some of the chips on the Hauppauge card have their support from V4L2 rather than from the ivtv drivers. These include:

msp3400 controls the sound recording on the PVR card

If you want to ever use the Hauppauge remote, make sure you set up Drivers -> Character Devices -> 8250/16550 and compatible serial support to build as a module

If you have trouble getting your drivers loaded, the combination of modprobe -v, dmesg, and really reading what the error messages tell you is very helpful. I had to use an insmod with a long path and one fewer argument than recommended by the documentation. I feel like I still need to work out a few things about my 2.6 ivtv setup.

There are probably more than this that I've forgotten...

AFTER the kernel build, and reboot you will need to build a version of the ivtv drivers that support 2.6. I've successfully built the ivtv-0.2.0-rc3g drivers, which at the time I grabbed them, had to be downloaded from the personal website of the developer. Keep in mind also, that if you haven't previously grabbed it, you'll need the Hauppauge driver file. Mine is called pvr250_17_21288.exe

After you extract and build the ivtv drivers according to the instructions in the tarball, you will also need to install the firmware file in the right place. Instructions and a utility for this purpose are in the utils directory of the source tree.

If you plan to be using the remote, you'll also need to make sure lirc is set for using the Hauppauge driver. I'm using gentoo, which means I tried to get portage to just handle this for me. Not such a great idea. If somebody has a custom ebuild that works, let me know. I used emerge to find the latest version and pull down the tarball, but I configured and built it myself. Just choose the Hauppauge remotes, and follow the rest of the lirc build instructions. The essential step is you will need the lirc_i2c driver module.

Now that you have all the driver modules built, the firmware file installed, and the driver support in place, you need to do some driver insertions

You can just try modprobe ivtv and in a perfect world, all the support needed will load properly. I had trouble with the drivers for tuner and ivtv. Specifically...

tuner: Unknown parameter `type'
ivtv: Unknown parameter `debug'

If you do a grep ivtv /etc/ you should notice that the parameters that anger modprobe are hiding out in /etc/modprobe.conf. These parameters for ivtv and tuner used to be recommended but they're apparently now unpermitted. I don't understand the details, but I do know that if you find the entries in modprobe.conf, you can just remove these lines completely. However, on Gentoo, you should instead modify /etc/modules.d/ivtv, then do a modules-update. Change these lines...

options ivtv debug=0
options tuner type=2

I'm using MythTV with the ivtv drivers, and in liveTV mode, on-screen display is broken. Also, I can't change channels.

This happens if the mythbackend service starts up before the ivtv tuner module is loaded. Even if you load the tuner module, then restart mythfrontend, it still doesn't notice the change. Magically, restarting mythbackend solves this.

How do I convert a mythtv .nuv file generated using the ivtv driver to a format that can be played on Windows XP?

There is more than one way to do this. In my case, I had recorded using the default video dimensions of 480x480 pixels, which contains aspect ratio data encoded in the mpg. Windows likes avi files, and avi files don't support the aspect ratio information, so in my case, I first needed to scale the 480x480 video to a true 4:3 format. I also needed to generate a Windows-playable avi. I did this after several tries at getting my arguments to mencoder correct.

mencoder is a piece of mplayer, which is the swiss army knife of media players for linux. The man page is intimidating, so I would pipe it into less, and search that for keywords I was looking for. The ultimate string I came up with was:

mencoder -vf scale=640:480 -vfm ffmpeg -oac mp3lame -of avi -ovc lavc filename.nuv

This generated a test.avi file in the pwd, so be careful if you try running this a second time on a different file. An amusing side effect was that not only did the file become playable on Windows, it also shrunk for a one hour video from just over 2GB to 450MB.

The ffmpeg website lists information about which video formats are able to be played by an "out of the box" Windows system. There is a nice command line tool ffmpeg, which almost fit my needs, but I couldn't figure out how to make it rescale my video. If you don't have that need:

ffmpeg -i inputfile.nuv -vcodec msmpeg4v2 -acodec mp3 outputfile.avi

Looks like it would work fine. I tried it out, but it generated a 480x480 video, which did me no good, except to show that the format would play properly.

I rebuilt the kernel, and now sound recording is broken. What happened, and how do I fix it?

For some reason, my kernel config is set to build the msp3400 driver. I haven't found where the option is to turn it off. Remember from above, that the msp3400 driver provided with the kernel is different than the version provided with the ivtv drivers, and the Hauppauge PVRx50 requires the ivtv version. Therefore, the modules-install blasted the wrong version of msp3400 over the correct version. For people like me using the proprietary Nvidia driver, rebuilding that is also required, but I'm used to this, and forgot about msp3400.

You don't actually have to rebuild the driver if you didn't change the kernel version (at least that worked for me). cp the msp3400.ko file from the driver folder where you built the ivtv drivers to the /lib/modules/kernel_version/kernel/drivers/media/video/ folder.

I rebuilt the kernel, and now the remote isn't working. What happened, and how do I fix it?

DISCLAIMER: Before about 2.6.17 or so, the kernel with mythtv didn't have any special support, (or at least I wasn't using it) but since then it makes sense to use something called dev/input. I haven't rewritten this section to talk about it. Very briefly, I configured lirc to listen to dev/input, then I configure dev/input with a special remote configuration file that maps the key presses to on the remote to keyboard equivalents. I don't have time to write this up right now, but you can email me directly and I'll try it get back to you. Ignore everything else I wrote about lircd if you're trying to use devinput.

The remote requires a few things. First, lircd needs to be built with support for the Hauppauge remote, and I don't know how to do that except to download the source tarball, ./setup.sh (choose Hauppauge driver and X support), make, make install, make sure lircd service is running, and then fire up irw. If lirc is working properly, running irw should look like a hung prompt, and every time a remote keypress is detected, it should display on the screen. A .lircrc file needs to be in the home dir of the user logged into X for lirc to be able to map the keypresses to the action it should take. If this mapping is happening properly, the irw display will list the infrared code received, as well as the action this code maps to. At this point, the remote should be working with mythtv, unless mythtv wasn't compiled with lirc support, but I believe the default for mythtv builds is that lirc support is compiled in.

I've had a case where lirc basically seemed broken. lirc_i2c and lirc_dev modules were loaded, every time I fired up lircd it started, but ipw would immediately fail, and tail-ing /var/log/messages would reveal the following:

Oct 30 11:49:15 cheryl 0.7.0[9710]: accepted new client on /dev/lircd
Oct 30 11:49:15 cheryl 0.7.0[9710]: could not get file information for /dev/lirc
Oct 30 11:49:15 cheryl 0.7.0[9710]: default_init(): No such file or directory
Oct 30 11:49:15 cheryl 0.7.0[9710]: caught signal O
This would repeat indefinitely. My fix was to check out the lirc
website, which had no help for this, but I did notice that version 0.7.2
was available. I built this with the ./configure, make install, and
everything has been fine since then.

Furthermore, the lirc_dev and lirc_i2c module need to be built for
each kernel. lirc 0.7.2 refused to build for me on 2.6.14, so I tried
out lirc 0.7.3pre1. It compiled and started up properly on the first
try. Kudos to the lirc team for fixing my problem before I knew about
it.

My remote isn't working, and I haven't touched the kernel. /dev/lirc doesn't exist, but it should. What happened and how do I fix it?

After having my remote mysteriously stop working yet again, I tried to figure out what was causing this to happen. I found the same messages as the previous error messages in /var/log/lircd. The /dev/lirc device was not in /dev at all. If I did a /etc/init.d/lircd status it claimed lircd was running, but it wouldn't show in a ps aux.
lsmod | grep lirc showed that lirc_i2c and lirc_dev were loaded. All operations involving the ivtv drivers were working properly except the remote itself. If I did a /etc/init.d/lircd stop it claimed there was no instance of lircd running (duh!). To clear this I did a /etc/init.d/lircd zap
If I did a /etc/init.d/lircd start the process repeats itself. The moment I type irw lircd crashes, /etc/init.d/lircd doesn't know what to do until you zap and restart, and the same error messages occur in /var/log/lircd. Reloading the lirc kernel modules seems to make no difference.
The only solution I've found that works is to go to the source
directory where I built lirc(d) and do a make install again. This seems
to fix the missing entry in /dev and magically make everything work
again. (after I restart the lircd script with a zap and a start).
However, after reboot, the problem is back.
I found this hereWhen you are using
devfs or sysfs with your kernel, the /dev/lirc device node will disappear
again once you reboot your machine. In that case the LIRC kernel module
will generate the required entry every time it is loaded. But the device
node won't be visible as /dev/lirc, but might be located in a different
location like e.g. /dev/lirc/0. Please be aware of this fact when
starting programs that access the device node like mode2 or lircd. You
will have to use the --device command line option of these programs to
point them to the correct location. When using sysfs together with the
udev daemon you should copy the lirc.rules file located in the contrib
directory of the source package to /etc/udev/rules.d/. This will make
sure that the device node will be created.
This was my real problem; udev / sysfs wasn't creating the devices
properly after reboot, and copying the rules file to /etc/udev/rules/
fixed this.

What else should I configure along with MythTV and the ivtv drivers?

NTP It's important to synchronize your system clock so that your recordings start at the appropriate time. There's a good guide to setting up Network Time Protocol here
RAID If you want to store a lot of data, linux has mature software raid support. I'm using a RAID 0 over LVM configuration. The system overhead for this is minimal and allows you to combine the capacity of multiple hard disks.
LIRC You'll definitely want to get the remote
working. The user that will be logged in while running
mythfrontend will need to have a .lircrc file in their home
directory. This should have bindings both for mythtv AND for
mplayer, which is used if viewing dvds (and I think vcds) through the mythvideo plugin.

Yikes! My MySQL database is corrupted. Now
what?!

First of all, the prospective mythtv user should have a cron job that
daily backs up the mythconverg database. I have a script that uses the
mysqldump command to dump the database to a single file, then compresses
this file using bzip2, and I've also added a rotation logic to the script
to throw away the 30 days ago-th backup so I keep that many backups on
hand. This of course can be tuned for longer or shorter retention
times. Now that I've been running MythTv for almost two years, I think a
smarter approach would be to perhaps retain fifteen days of backups, taken
twelve hours apart, or maybe three / day, made eight hours apart. My backup
script is on revision two, and revision three will do that. When I do
this I'll post the script here.
So ideally, I will never lose more than a day worth of changes to the
database. But MySQL has some data recovery logic to attempt to recover
previous transactions, akin to a journaling filesystem. Check out your
mysqld.log file for errors to track down exactly which table(s) are
corrupted. In my case, the log indicated there was an error with my record
table. This was evident in the fact that after a hard shutdown,
mythfrontend claimed "no recordings were available" but all the recordings
were present in my files.
MySQL comes with a tool named myisachk, which takes as an argument the
path to the actual MYI files that host the database, which might be
somewhere like /var/lib/mysql/mythconverg. cd to that directory,
then run myisachk tablename where tablename is the name of the
table that was reported as corrupt in the log.
In my one case where I've tried this, it fixed five errors, and I was
able to access my recordings without having to resort to my 18 hour-old
backup. Naturally, I was impressed with the abilities of this tool.

Commercial skip and jumping time within my
recordings are broken. What happened, and how do I fix it?

In addition to the symptoms already listed, if I pressed the i key to
check my position in the file, the times were way wrong, like a thirty
minute program grew to 1 hour 24 minutes, and then as the file played this
time dercremented one second for each second of play. The commerical skip
was completely broken, claiming that the recording wasn't flagged, even
though the icons on the recordings list said it was. After playing the
file long enough, the skip buttons didn't work at all, and the time
listings were even more wrong.
This happened to me when my MySQL database got corrupted in a different
way, specifically, my recordedmarkup.MYI file was corrupted. The mythtv
website recommends running
mythcommflag --all to reflag the commercials in every recording.
I tried this, and mythcommflag gave tons of errors about not being able to
do an INSERT into the recordedmarkup table.
I then did a myisamchk
/var/lib/mysql/mythconverg/recordedmarkup.MYI which found many
errors, and recommended I repeat the command with the -r flag,
which performs some recovery magic. This restored the database, but I
tested some recent programs that had commercial skip corrupted, and they
were still broken, so I ended up running the mythcommflag --all
to reflag every recording again. This took several hours, and was a bit
frustrating, but the good news is you can watch the output of
mythcommflag to find out which recordings have been fixed and
will now be watchable.

Suddenly mythcommflag, mythtv, and other programs complain about missing libGL.so.1.

Trying to run mythcommflag yielded results like: