nerdylorrin.net wiki: MythTV

Hardware Requirements

1 GHz CPU is just about the minimum for simultaneous software based encoding and decoding of standard definition content. With hardware MPEG compression (e.g. Hauppauge WinTV PVR-250

) CPU requirements are drastically reduced. Standard definition MPEG decompression isn't terribly CPU intensive so there's not much to gain from doing that in dedicated hardware (e.g. WinTV PVR-350).

Compressing high-definition content in real-time is currently not possible with consumer hardware. With cards like the pcHDTV-3000 no compression takes place; the input is already/still an MPEG stream. Decompressing high-definition content is CPU intensive; a fast dual-CPU machine is required. An Intel Core2 Duo E6600 2.4 GHz should be sufficient. Less CPU needed if some of the decompression is offloaded onto the GPU. See http://www.mythtv.org/wiki/index.php/XvMC

General installation

See MythTVUbuntuFeistyFawn, MythTVUbuntuEdgy and/or MythTVDebianSarge.

Graphics Card

See nVidia.

For Intel (e.g. G965 on-board video) install the xserver-xorg-video-intel package (Debian/Ubuntu), which replaces the older xserver-xorg-video-i810.

Analog TV capture card

On Ubuntu, see MythTVUbuntuEdgy.

On Debian, ee Bttv for Hauppauge WinTV (non-PVR) cards based on the Bt848 and Bt878 chipsets. For Hauppauge WinTV PVR cards use the Ivtv drivers.

Digital TV / HDTV

Easiest route is HDHomeRun

The pcHDTV-3000 can record over-the-air (OTA) HDTV broadcasts and it ignores broadcast flags.

Regardless of transmission medium HDTV is broadcast with MPEG-2 compression. This is handy since no consumer grade equipment (2004-11) is powerful enough to compress the flood of raw data in real-time. Since it's already compressed all that has to be done is to stream it to disk.

AntennaWeb lets you look up what OTA digital broadcasts are available in your area and what type of antenna you'll need to receive them.

HDTV from cable or satellite is trickier. First it's QAM-encoded. pcHDTV currently doesn't decode QAM. More importantly, it may be encrypted, in which case you're hosed. So you need to get the data after it has been decrypted but before the MPEG has been decoded into a unmanageably huge raw data stream. Cable boxes are required by law to have IEEE-1394 jacks on them now. That data is always pre-decompressed but, most of the time (depends on the box), it's also pre-decrypted.

In the future you could probably get the final DVI output and encode that with a more powerful computer. Unless, of course, the DVI isn't DVI but HDCP, which stands for High Definition Copy Protocol. The latter is encrypted and currently uncracked.

LIRC

See LIRC

Channel Listings

In North America Zap2It provides the easiest way to get channel listings. See the Configuring the Zap2It.com DataDirect service

section of the MythTV HOWTO for information on how to get a (free) account.

Encoding settings (analog broadcasts)

On a Pentium 4 2.8 GHz, MPEG-4 with 640x480 @ 2200 Kbps and high-quality encoding and 4MV enabled CPU load when watching LiveTV is about 50%. Without the high-quality settings CPU load is closer to 30%. Despite the apparent headroom, however, the high-quality settings cause occasional clicks in the audio, especially during seen changes.

640x480 is the native NTSC resolution (or as close to a native resolution as NTSC has). Lowering the resolution seems to dramatically reduce image quality.

Although higher bitrates do slightly increase the CPU load this seems to be the least CPU intensive way of getting more image quality. I'm currently experimenting with recording at 8000 Kbps (high quality disabled) and transcoding to 4400 Kbps (high quality enabled).

With my PVR-250 I'm recording at the default 4500 Kbps (but also at 640x480).

The MythTV GUI provides two ways of setting the font size. Under Setup -> Appearance you can change Font size between big, small, and default. Select what seems appropriate. You can also set point sizes for small, medium, and big fonts. Leave those settings at their defaults (12, 16, and 25). The reason is that the theme files /usr/share/mythtv/themes/*/ui.xml already specify explicit point sizes for each font when rendered big or small.

Another option is to change the global DPI setting in /etc/X11/XF86Config-4. Find the "Monitor" section and add DisplaySize width height where width and height are in millimeters. To compensate for TV screens being fuzzy use values that are on the small size (but keep the correct aspect ratio). For my 20" TV I use 208 by 156.

Tweaks

If your graphics card supports OpenGL (e.g. with the nvidia-glx driver) enable MythTV OpenGL support

In Setup -> TV Settings -> General it's a good idea to set recordings to start and stop with an additional buffer (e.g. 120 seconds).

In Setup -> TV Settings -> Playback -> Deinterlace / Kernel, OpenGL vertical sync, Seeking->Smart Fast Forwarding

Issues

Image quality sub-par. Primarily seems to be due to crappy S-Video out on my graphics card (ELSA GeForce 2 MX). To figure out where to place the blame there are two comparisons to make: compare xawtv to real TV and compare xawtv to MythTV. I found that, viewed on a monitor, xawtv and MythTV looked similar and both were comparable to real TV. But either seen through TV-out looked poor in comparison to real TV.

Output improved by reducing flicker correction in nvtv. Unfortunately below 50 digital artifacts appear. Turning off interlacing gets crisper output but jaggies appear. Dialing saturation down a notch improves image slightly.

Should nVidia's drivers be used instead of the open-source nv drivers? Not sure if they're needed for 3D or if they'd help with MPEG playback as well. Linux.ars covers installation under Debian Sarge.

Troubleshooting

If DVDs aren't playing, try cat /dev/dvd. Often you'll get a no medium found error which can be cleared up by washing the DVD or blowing some dust out of the DVD drive.

After upgrading from 0.15 to 0.16 I had a couple problems.
- Upcoming recordings blank even though shows set to record. Problem was new input settings in mythtv-setup weren't configured.
- Recordings were made of the wrong channel. Problem was MythTV couldn't change the channel. Dumping the channel information, re-running mythfilldatabase and restarting the backend solved the problem.

Volume keeps getting changed: Check out the settings in Myth Frontend. You can change whether MythTV changes the volume and what it sets it to by default. Note separate settings for Master and PCM volume levels.

Program guide time is off by an hour. This is a known bug, apparently. Recordings should still be done correctly because normally the computer clock and listing data are all in UTC; the only broken part is how the times are shown to you; they're wrong because of daylight savings time. To fix, try using a time zone that has the same hour number but isn't on daylight savings time. E.g. Pacific Daylight Time is the same as Mountain Standard Time, and Arizona doesn't observe daylight savings time. So pretend you live in Arizona instead of Seattle. Whenever you change the timezone, run mythtv-setup, delete your channel data, configure it again, and run mythfilldatabase. Otherwise recordings will be made at the wrong time.

mythfilldatabase / SchedulesDirect grabber reports DataDirect: Not adding channel 'channel name' (channel callsign). Subsequent runs skip the channel altogether.
- When the channel table contains only empty strings in the xmltvid column, mythfilldatabase attempts to add all channels downloaded from DataDirect. This fails if the channel numbers don't match. You'll have to manually match up the channel numbers picked up by your digital tuner (e.g. 7.2) with the channel numbers ScheduleDirect expects (e.g. 107) and set them via mythtv-setup. Not sure if the callsign has to agree as well.
- When some rows in the channel table have an xmltvid, mythfilldatabase does not try to match up the remaining ones. In mysql: update channel set xmltvid = ''

Jerky / corrupt HD playback may be due to limited network bandwidth when streaming from an HDHomeRun. The stream is about 18 Mbps. If the data is being streamed to the MythTV backend, from there to a NAS, and then back out for LiveTV or commercial flagging, it's easy to see how 100 Mbs may be insufficient for smooth playback if other network activity is going on.

Program Guide incorrect for a channel:
- Edit the channel (either press E while watching or use mythtv-setup)
- Set the xmltvid to the correct one
  - Either look in SchedulesDirect or, better, zap2it.com
- Quit MythTV and run mythfilldatabase --refresh-today --refresh-all (mythfilldatabase with no args is not enough!)