Expand everything   |   Expand non-PVR-350 Output bits   |   Expand PVR-350 Output bits   |   Close everything
*** Current setting: Everything closed ***

Life's been busy... (2008-09-20)

So a few people have asked me if I've fallen off the face of the earth, seeing as how I haven't got around to updating this page in about a year and a half (aka 3 whole Fedora releases)... Nope, still here. I'm just quite busy with work (still at Red Hat) and family (kids keep growing, had a little combined party today for my son's 6th birthday and daughter's 3rd birthday). I'm largely not doing any sort of work directly on MythTV these days, though I *am* now maintaining MythTV packages in Livna and the forthcoming RPM Fusion repository. Most of my spare hacking time outside of work is being spent on the Linux Infrared Remote Control drivers, and getting them into shape such that they can be merged into the upstream Linux kernel. They've grown in the wild (aka outside the kernel tree) for over a decade, so its been no small task. Big thanks to Janne Grunau, another MythTV and DVB/V4L developer, who has been doing a ton of work on them as well. (Work-in-progress lirc git tree here).

Should also mention that we, the MythDora devs (me, Ryan Pisani and Dennis Hand), put out a Fedora 8-based MythDora 5.0 a few months ago, and the next release is coming along quite nicely, though its been largely Ryan's handiwork. I think we're gunning for releasing it right around the same time as Fedora 10, using Fedora 10 as its base...


Ugh, I meant to post this up here weeks and weeks ago... I helped write a book about MythTV earlier this year (part of it while moving from coast to coast), titled Hacking MythTV, and its been on bookshelves for a while now. Go out and grab yourself a copy if you're so inclined! A lot of the book is based on the contents of these pages, but there are some more in-depth parts, as well as some entirely new or rewritten material. I've actually been meaning to update the tips page with some of the advanced hacking stuff I wrote for the book, but for now, I guess you'll have to get a copy of the book for those nuggets of knowledge... :)

Update (2007-01-03): Actually, bits and pieces of the book can be found on the ExtremeTech web site. Just ran across the performance tweaking chapter I wrote a few minutes ago...


Step-by-step guide to building a MythTV System on Fedora Core 6 w/ATrpms

Compiled by Jarod C. Wilson <jarod@wilsonet.com>
Made possible by information gathered from all over the Internet (Google is your friend)...
    $Revision: 121 $
    $Date: 2007-03-26 00:27:51 -0400 (Mon, 26 Mar 2007) $


  1. Introduction
  2. Hardware
  3. Initial System Setup
  4. Firstboot setup -- create MythTV user and enable ntp
  5. Get your system up-to-date
  6. Configure 3rd-party package repositories
  7. Get and install video card drivers
  8. Audio setup
  9. Get and install MythTV
  10. Get and install capture card driver(s)
  11. Get and install lirc
  12. Set up MySQL
  13. Set up MythTV
  14. Configure automatic startup
  15. Configuring MythTV add-ons
  16. Upgrading your system
  17. Miscellanea
  18. Trouble-shooting
  19. Changelog

1. Introduction

MythTV is an open-source project, with its primary functionality being similar to that of a TiVo on steroids, with far more features, much greater flexibility and the ability to handle an extremely wide variety of content. The project's founder and leader is Isaac Richards. The official documentation can all be found on MythTV's official web site, at http://www.mythtv.org/. The project is supported by the contributed time and effort of the open-source community, with the primary lines of technical support being the documentation on the project web site, and the project's mailing lists. It is highly recommended that if you are intending to install MythTV, join at least the mythtv-users mailing list, which you can subscribe to here: http://www.mythtv.org/mailman/listinfo/mythtv-users/, and read through the official docs.

While the official documentation attempts to be as distribution-agnostic as possible, this document is geared specifically toward building a MythTV system on the Fedora Core 6 Linux distribution put out by Red Hat, with all components installed from binary packages using automatic dependency resoltion tools (i.e., you won't need to compile anything or manually deal with any twisted dependency issues). Quite a few people following this particular body of documentation have successfully created their own MythTV systems, and many of them frequent the MythTV Users mailing list. Someone on the list can generally help you if you have a problem. I also frequent the mailing lists, and will help out in any way I can, though my spare time is in very short supply these days. However, please search the mailing list archive, found here: http://www.gossamer-threads.com/lists/mythtv/, before you mail the list, because there is a good chance you'll find your answer there. If you are unable to find the answer there, then read this document: http://catb.org/~esr/faqs/smart-questions.html, after which you may address your question to the mailing list. ;-)

Versions of this document for older Fedora releases are NOT maintained in any way, but are still available for historical purposes. Just use the latest version, unless you have some very compelling reason to do otherwise. The old versions can be found here:

Fedora Core 5 version
Fedora Core 4 version
Fedora Core 3 version
Fedora Core 2 version
Fedora Core 1 version

It was suggested to me by a number of folks that I provide PayPal account information for those wishing to contribute. Contributions help persuade my wife that I'm doing more than just wasting my time! Certainly don't feel obligated, but go ahead and click on the little PayPay button if you feel inclined. =)

Anyhow, I try to answer any email I get, but of late, there's no way I can keep up (I'm at least a month and a half behind on replies as I write this). I often get some of them the same questions/problems over and over, so chances are, someone on the list can answer your question, even if you don't find what you needed in the mailing list archive, and you'll likely have a solution faster than I can respond. I used to be very active on the mailing list myself, but just plain haven't had the time lately (work and family has been taking precedent). However, if you think you've found a problem with something in this document, or have a suggestion for an improvement, please don't hesitate to contact me directly via email, and I'll try to get to it when I have the time. I try to keep this document as up to date and accurate as my time permits -- time just isn't permitting much these days... :(

Thank you for reading, and enjoy!
Jarod Wilson

2. Hardware

I suggest you start here for information on hardware:


An excellent place many folks get their Myth box hardware from is NewEgg.com.

And those looking at building the quietest Myth box possible should probably check out SilentPCReview.com for advice.

Just about any computer that runs Linux and has enough processing power can be used as a MythTV box. For example, I had zero problems playing back full-resolution PVR-250 recordings on an Athlon 800 with a GeForce 4 MX. I've recently shuffled around a ton of hardware at home, so the systems listed below are merely examples of setups that I'm familiar with and know to be functional.

A good place to look at other examples of what people are using for their MythTV boxes, and how they rate their systems, is Mark Cooper's PVR Hardware database, browseable here:


Pundit users might also find Matt Marsh's "Pundit MythTV Device" site of use:


Additionally, if you're like me, the SPDIF output being on the front of the Pundit case is a big turn-off. One enterprising reader has put together some notes on how they added one to the back of their case:


Also note: the WinTV PVR series and AVerMedia M179 cards may have issues running correctly on some motherboards based on VIA chipsets. Check the ivtv FAQ to see if your chipset is on the list of known offenders:


3. Initial System Setup

This guide is geared toward using Red Hat's Fedora Core 6 Linux distribution. You can download the CD images for Fedora Core from one of the many Red Hat mirrors out there, the official list of which can be found here:


As with most any Linux distribution, several file systems are available for you to use, some of which are a bit better suited for use with large files -- like Myth recordings -- than Red Hat's default file system, ext3. However, Red Hat doesn't let you use anything else at system install time, unless you type in "linux <otherfs>" at the boot: prompt when firing up the installer CD, where <otherfs> is something along the lines of reiserfs, jfs or xfs. I'd *highly* recommend a custom partitioning scheme rather than auto-partitioning, with a dedicated /storage (or similar) partition for storage of all your recordings, movies, music, photos, etc. Previously, XFS was my personal recommendation for the file system to use for such a purpose, but some additional stability issues with using XFS (and JFS) on Fedora Core's stock kernels have been brought to my attention. In the case where you're stacking software RAID, LVM and XFS all together, stack overflows tend to crop up. I'm simply running ext3 myself, and have been for ages without a problem. While not the speediest kid on the block, its still fast enough for MythTV use, and its generally a more robust (and better supported by Red Hat) file system than the other options. But if you want the best in performance, you might try your hand with XFS (which I believe has since had most issues remedied). Think of ext3 as your reliable family car, XFS as a sports car... :) If you want to go XFS, boot the installer with "linux xfs", then choose XFS for your /storage partition. An example partitioning setup can be found below.

On the Disk Partitioning Setup screen, choose to Manually partition with Disk Druid. A suitable custom partitioning setup is as follows (assuming a single SATA hard drive):

Partition Mount Point Size Format
/dev/sda3swapsame as RAM (ex: 512MB)swap
/dev/sda5/storageEverything elseext3

If you wanted to use something other than ext3 for your /storage partition, be sure to choose XFS (or JFS or ReiserFS) as the partition format type, as the selection will default to ext3. Note that there's really no point in using anything but ext3 on / and /boot. Red Hat tests ext3 heavily, its the only one that is pretty well guaranteed to be problem-free for / and /boot. Those expecting to add additional hard drives to their system for more video storage might want to set the partition type for hda5 to LVM, then create a logical volume over the top of it, formatted with the file system of your choice. That'll allow you to increase the size of your /storage partition transparently across multiple drives. Details on how to do that can be found in the official MythTV docs, at http://mythtv.org/docs/mythtv-HOWTO.html#toc24.1. Note that neither XFS or JFS volumes have the ability to be reduced in size, while ext3 and reiserfs do, which could be of concern in an emergency, should you need to remove a disk from an LVM group for some reason...

On the Network configuration screen, I highly recommend setting a static IP address (could either be truly static, or a staticly mapped DHCP address). It really isn't a huge deal if you only have one Myth box, though you probably don't want MythWeb to be a moving target, and it could cause major headaches once you have more than one machine, since non-primary systems wouldn't know where the master backend was anymore if the address changed.

On the Package selection screen, uncheck all the check boxes and select the "Customize now" radio button. At the next screen, you'll be able to re-add the components we need/want. Minimally, add (at least) these package groups to those already selected:

Optionally, you might also want to add these groups:

Because MythTV is heavily tied to the same toolkit as KDE, we're going to use KDE as the desktop environment on top of which we'll run MythTV. However, you're welcome to try your luck with another window manager. Pretty much any desktop environment/window manager will work, but you may have to make minor deviations from this document in KDE-specific parts. Personally, I run ratpoison instead of KDE on my dedicated MythTV frontend, since I don't need a full-fledged desktop, it loads up faster, and reduces the system memory footprint. If you're short on cpu horsepower and/or memory, switching to something lighter-weight than KDE may be worth the little boost in system performance.

Switching from one desktop environment to another is as simple as selecting a different one via the Session menu on the login screen and saying yes, you want to always login with that desktop environment. Alternatively, you can also use the 'switchdesk' command to make the change. For example:

$ switchdesk kde

For those that are interested, Jim Chandler has already gone down the WindowMaker path, and contributed these notes, and Greg Hawley has compiled some notes on setting up Myth on a low-end system, which include notes on using twm. Users on the MythTV mailing lists have written assorted information to the list about using Black Box and RatPoison. My own RatPoison setup is dead-simple, so one of these days, I ought to write something about it...

4. Firstboot setup -- create MythTV user and enable ntp

The first time you start up your system following installation, you should be greeted by the Firstboot setup utility, which contains various modules for configuring bits and pieces of your system.

In the Firewall configuration module, its easiest to simply disable the firewall for minimal headache. The firewall being enabled probably won't cause a problem if you only have one Myth box, but if not properly tweaked, would prevent any secondary systems from being able to contact the master backend. If you really want to enable it, I'd suggest permitting SSH, WWW (HTTP), Secure WWW (HTTPS), as well as adding port 6543, protocol tcp and port 6544, protocol tcp, both of which are used by the mythbackend process. Permitting Samba and NFSv4 may be of interest as well.

In the SELinux configuration module, disable SELinux. There are a number of things that just plain won't work right if you have it enabled. ResierFS doesn't work well with SELinux (known bug in Red Hat's bugzilla) and MythWeb (or more specifically, the web server, apache) can't communicate with MySQL without some work (actually relatively trivial, I just don't have the notes handy...). Personally, I don't care enough about security on my Myth box to want SELinux on it, so I just assume make life easier and disable it. Note that this means your system will restart once you're done with Firstboot.

In the Date and Time module, you have the option to enable the Network Time Protocol (ntp). This is highly recommended. You want your shows to start (and stop) recording at the right times, don't you? ;-) Check the box to enable ntp, and either enter an ntp server you know of near you or leave it with the pre-populated values, which are from the ntp.org pool (which aliases to a bunch of time servers around the globe).

In the Create User module, create a user called mythtv, with a password of your choosing. From here on out, most of this document assumes you are logged into the system as the user mythtv.

The Sound Card module should let you test out your sound card, but there's really nothing that should need to be done here. Good to know if it works, I guess, but if necessary, we'll tweak out the audio later on in this document.

5. Get your system up-to-date

Again, this document assumes you're logged in as the user mythtv. Lines with $ as the prompt are executed as user mythtv, lines with # as the prompt are executed as root. You should NEVER log in to your machine directly as root. Log in with the normal user account, then assume root privs with 'su' wherever a command needs to be run as root.

For the beginners out there, type 'su' (without the quotes) then hit return, and you'll get prompted for the root password. After entering that, you'll have a root prompt. Do what you need to do as root, then type 'exit' (again, without the quotes) to get back to your normal user prompt.

WARNING, DOUBLE-CHECK THIS NOW: there's a nasty bug in the FC6 installer that will result in an i586 kernel, instead of an i686 kernel, getting installed on some 32-bit x86 systems. Any 32-bit x86 processor newer than a Pentium I, with the exception of some Via C3 processors, should be running an i686 kernel. You can double-check whether you've been bitten via the following command:

# rpm -q --qf='%{name}-%{version}-%{release}.%{arch}\n' kernel

If you see i586, follow the directions in the Fedora wiki to remedy the problem:


While at one time the red-headed step-child of automatic dependency resolution and package download/install tools, Fedora's native yum utility has gotten considerably better with each new release, to the point where its pretty much all I use anymore for installing/updating software on my Fedora boxes. With the addition of a few little files and one plugin, it handles kernel upgrades, including upgrading the associated 3rd-party kernel modules needed on some MythTV systems, quite smoothly.

To get your system fully updated, simply run the command:

# yum -y upgrade

WARNING: Do NOT attempt any other rpm activity while the upgrade is in progress. Performing multiple exclusive rpm operations at the same time can lead to very bad things happening (rpm database inconsistencies, race conditions, completely hosed database, etc). After the big upgrade, you MAY get an error about being unable to open the rpm database (this used to happen to me w/RHL9, but hasn't ever with FC). If you do encounter this error, try the following:

# rm -f /var/lib/rpm/__db*
# rpmdb -vv --rebuilddb

The database rebuild will take quite a while to complete. After it completes, you'll see an error message, but you can safely ignore it and move on to see if the rebuilddb cleared the problem. If not, good luck... Note that the presence of those __db* files doesn't indicate a problem, they're supposed to be there, they just get corrupted every once in a while.

Among the packages upgraded just a minute ago via yum should be your kernel, updated to the very latest errata release. Additionally, your boot loader should have been automatically updated to use the new kernel, so all you need to do is reboot to start using the new kernel, which you'll want to do in just a minute. As of this writing, 2.6.20-1.2944.fc6 is the latest released errata kernel. You should be using at least this kernel, if not a newer one. Note that in FC6 and later, only 32-bit PowerPC has a separate smp kernel, all other architecures use a single kernel for single-processor and multi-processor systems.

Generally speaking, you should always install the latest errata kernel, shortly after the release of which Axel typically has all the needed kernel modules available. Kernel modules are NOT maintained for older kernels, because of two things. First, a new kernel from Red Hat usually fixes some flaw in earlier kernels (security hole or bug fix), so its good practice not to use the flawed kernel. Second, building kernel modules for every kernel would take forever and a day and cause assorted other headaches for Axel. To make providing kernel modules feasible, only the very latest one (or maybe two) kernels are supported.

To make life simpler after we've rebooted and are prepared to start installing drivers for some of our hardware not supported natively by the kernel, we're going to set up a custom environment variable, KVER, that will help avoid problems from typos, user error, confusion, etc. Simply drop a file in /etc/profile.d, like so:

# echo "export KVER=\`uname -r\`" >> /etc/profile.d/kver.sh
(those are back-ticks, not single-quotes)

Now you're ready to reboot into that new kernel and start installing kernel modules for your tuner card(s), remote, etc., as necessary.

# reboot

On with the show, once your machine comes back up...

6. Configure 3rd-party package repositories

We won't touch any packages from and 3rd-party repositories until a bit later, but you'll need to tell yum about the ATrpms and FreshRPMs package repositories, and since we were on the subject of yum already, go ahead and set it up now. This is a simple matter of adding a configuration file for each repository in /etc/yum.repos.d/. Pre-configured files can be simply downloaded to your system like so:

# cd /etc/yum.repos.d/
# wget http://wilsonet.com/mythtv/atrpms.repo
# rpm --import http://atrpms.net/RPM-GPG-KEY.atrpms
# wget http://wilsonet.com/mythtv/freshrpms.repo

As hinted previously, note that Axel maintains a few different channels of rpms, including many packages besides those needed for a functional MythTV install, with varying stability labels on them. This entire installation can be done using nothing but packages classified as "stable", but even "testing" is generally pretty stable. The only channel to *really* watch out for is the "bleeding" channel. If you enable it, you've been warned; things may break. You're on your own to fix 'em, so be prepared (Axel appreciates bug reports though -- http://bugzilla.atrpms.net/). The primary classifications are as follows (from Axel's web site):

Generally, any problems encountered with ATrpms and ATrpms packages should be addressed on the atrpms-users mailing list before being taken to the MythTV list. You can subscribe to the ATrpms lists here:


FreshRPMs is structured a bit different than ATrpms -- it generally only provides add-on packages, while ATrpms provides both add-on packages packages that replace/upgrade/enhance packages originally provided by Red Hat. FreshRPMs only has one channel of packages. You can subscribe to the FreshRPMs mailing list here:


As with any other mailing list, please search their respective archives first (you can find links to them in the same locations as above).

7. Get and install video card drivers

While Fedora Core includes video drivers for most video cards, they aren't always the best ones for the needs of a MythTV user. For example, many video cards require experimental 3rd-party or proprietary drivers to enable TV-Out. Without nVidia's own proprietary video drivers, the performance of cards based on their chipsets will suffer greatly, even if you aren't using TV-Out. Instructions for installing accelerated drivers for nVidia and SiS cards can be found below. You're on your own for other cards. Click to expand the appropriate section for your video output device...

8. Audio setup

Note: outside of setting your audio mixer levels, this step is not essential. Just set your volumes with the mixer program of your choice and move on to the next step if you like. ALSA is the default sound system in the 2.6 kernel, so you've already got it, and your sound card should have been auto-configured during firstboot. If you have some flashy new card, there's a chance you might need a newer ALSA version, which ATrpms typically does provide. Those wanting to install the latest ALSA packages from ATrpms should do so with these commands:

# yum -y install alsa-kmdl-$KVER
# yum -y install alsa-driver

If you have multiple sound cards you want to use, you may have to edit your /etc/modprobe.conf file for your specific card. Details for supported cards can be found here:


I'm including a copy of my /etc/modprobe.conf ALSA configuration excerpt, which is for a SoundBlaster Audigy sound card. This should be valid for SB Live! and Audigy2 cards as well. If your card isn't one of those, check out the ALSA site's sound card matrix to find information for your card. The differences are very minor for most cards, and usually only the driver name has to be changed. For example, to configure ALSA for use with the onboard audio of an nForce2 board, it should be a simple matter of replacing all instances of "emu10k1" in the following modprobe.conf and .asoundrc with "intel8x0".

# Example modprobe.conf entries for my Audigy
alias snd-card-0 snd-emu10k1
install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && /usr/sbin/alsactl restore >/dev/null 2>&1 || :
remove snd-emu10k1 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-emu10k1

For those folks out there unfortunate enough to need dual sound cards, I'm including a theoretical modprobe.conf ALSA snippet for a SoundBlaster Audigy and nForce2 onboard (i810) audio.

#Example modprobe.conf entries for Audigy and nForce2 onboard (i810) audio
alias snd-card-0 snd-emu10k1
options snd-card-0 index=0
install snd-emu10k1 /sbin/modprobe --ignore-install snd-emu10k1 && /usr/sbin/alsactl restore >/dev/null 2>&1 || :
remove snd-emu10k1 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-emu10k1
alias snd-card-1 snd-intel8x0
options snd-card-1 index=1
install snd-intel8x0 /sbin/modprobe --ignore-install snd-intel8x0 && /usr/sbin/alsactl restore >/dev/null 2>&1 || :
remove snd-intel8x0 { /usr/sbin/alsactl store >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-intel8x0

Next, create a .asoundrc file for your mythtv user (full path of /home/mythtv/.asoundrc). Technically, this isn't necessary, but it can help out quite a bit in some cases (especially if you're outputting via an S/PDIF connection), and can't hurt. Anyhow, just make a new text file called .asoundrc like so, adjusting for your specific card, substituting for "emu10k1" where necessary:

$ cat > ~/.asoundrc
pcm.emu10k1 {
type hw
card 0

ctl.emu10k1 {
type hw
card 0
(Now hit Control-D to end cat input)

This is a *very* basic .asoundrc file, which worked for me just fine for some time, but I'm currently forging forward with native ALSA digital output in Myth, which requires a bit more complex setup. Mike Dean did an excellent writeup on the matter of digital sound, with details on a fully fleshed out .asoundrc, which you can now find in an evolved and fleshed-out form at:


I put together my own tweaked-out .asoundrc for my Audigy based on the long version for the nForce2 sound card found at the above link. It basically amounted to four changes. You can grab my full .asoundrc here:


Note that it is set up with output via S/PDIF and hardware decoding (by an external amp) as the default output method, so adjust accordingly. I'm actually not certain everything in here is correct, but audio on my box does everything it should, so I've left well enough alone. Additionally, this page may be of interest if you're on the subject of passing raw digital audio streams (i.e., Dolby Digital Surround-Sound or AC3 audio) to an external amp:


Anyhow, now fire up the audio controller of your choice (aumix, alsamixer, kmix or gnome-alsamixer) and adjust the volumes, inputs and outputs to your liking. While enabling S/PDIF out for my Audigy was a matter of a checking a box in gnome-alsamixer, some folks have reported having to set a particular slider (IEC958 something-or-other?) to zero to enable the S/PDIF output on their sound cards. Go figure.

A simple way to test whether or not you've got sound is to use ALSA's aplay utility, like so:

$ /usr/bin/aplay /usr/share/sounds/KDE_Startup.wav

For whatever reason, one of my boxes doesn't like to restore all my audio levels, despite my having stored them with an 'alsactl store'... To get around this, along with my nvidia-settings not loading, I used a short shell script you can check out in the Configure automatic startup section below.

9. Get and install MythTV

Now, here's why we REALLY like automatic dependency resolution and installation tools like yum... MythTV has numerous required dependencies to function correctly, which are automatically taken care of with one simple command:

# yum -y install mythtv-suite

The last time I looked, that one-liner installed 115 different packages, totalling about 102MB. Just a wee bit easier than hunting down all the rpms by hand, let alone compiling everything from source... :)

10. Get and install capture card driver(s)

MythTV supports a myriad of different video capture cards, and as of version 0.17, firewire input from certain cable boxes as well. See the official MythTV docs at http://mythtv.org/docs/mythtv-HOWTO-3.html#ss3.1 for details on exactly what are and are not supported. Below you'll find details on setting up a number of popular capture devices under Fedora Core.

Click on the links by the + signs to expand and/or collapse the sections you need. If you've got more than one of the same type of card, the setup process for one card should actually get all cards of that type working. If you've got different types of cards (say one dvb and one ivtv), just configure each of them independent of one another, but take note of which driver loads first, as it may impact which card grabs /dev/video0 versus /dev/video1. Enable or disable display of PVR-350 Output information right here.

Show PVR-350 Output info   |   Hide PVR-350 Output info
*** Current setting: Hiding PVR-350 Output info

11. Get and install lirc

There are lirc rpms available from ATrpms, installable via yum and everything. However, it should be noted that they don't work with every single remote out there. Axel has attempted to roll in as much support for the most popular remotes as possible, and quite a few do now work. It is also possible to obtain the source packages, and potentially build it for your specific remote/receiver, if the prebuilt packages don't work for you.

The earlier "yum -y install mythtv-suite" command installed part of LIRC for us already (lirc-lib). To finish the install, we need the appropriate kernel module as well. Simply install the remaining bits like so:

# yum -y install lirc-kmdl-$KVER
# yum -y install lirc

Expand the appropriate section below for your IR receiver interface.

Note that most lirc drivers don't get automatically loaded, but Fedora has a neat little facility to force the loading of modules early in the boot process, via a file in /etc/sysconfig/modules/. I've got a script you can download which should load up any lirc modules you've configured in /etc/modprobe.conf. Set it up like so:

# cd /etc/sysconfig/modules/
# wget http://wilsonet.com/mythtv/lirc.modules
# chmod +x lirc.modules

At this point, you should be able to start up lircd:

# /sbin/service lircd start

The start command should return an OK or two (look in /var/log/messages if you don't get an okay for some possible insight as to what went wrong). Now fire up irw to verify that lircd is receiving signals from your remote:

$ /usr/bin/irw

You should see some output when you press buttons on your remote that correspond with each button press. Hit ctrl-C to stop irw.

At this time, you're on your own to create a lircrc file for your remote. I have mostly implemented one for my AVerTV Studio remote, mostly just to verify that it work and until I get something better (quite frankly, it is utter junk, especially for use with MythTV).

Hopefully, this section will be of some aid to those using a different remote interface also...

Other routes to consider for an IR receiver if you either don't like the one that comes with your capture card or have a remote frontend without a capture card are serial port and USB receivers. I'm a huge fan of the USB receiver from Windows XP Media Center Ed., because they have a nice long cord to get them optimally placed (versus the very short cord on the PVR-x50's receiver) and have much better range and multi-directionality than any other one I've used. I've also got a serial one on the way shortly.

You can get a USB XP MCE receiver from NewEgg.com, but its a touch spendy, since you don't have the option to buy it without the MCE remote:


It should be noted that there are two different lirc USB MCE remote drivers, one for an early model (which I have and love), which uses the lirc_mceusb driver, and the newer-model ones (which is all NewEgg carries now), which use the lirc_mceusb2 driver. Both are bundled in the ATrpms lirc packages.

Another popular USB combo is the ATI Remote Wonder, which isn't actually IR, but RF. RF doesn't have nearly as many directionality or range issues as IR, but I don't believe you can control anything but your Myth box with a Remote Wonder, and the receiver is only good for the Remote Wonder. These ship with some ATI TV tuner cards, and you can also find them as a stand-alone at NewEgg.com:


Those using an ATI Remote Wonder probably want to check out Tim Litwiller's doc on how he set up his:


You can easily build your own serial IR receiver, per the diagrams on the LIRC web site, or you can just pick one up online for a few bucks. One popular source for pre-build serial IR receivers is Zapway.de, which while in Germany, does ship globally.

12. Set up MySQL

We'll need to enable MySQL to load at startup, set some passwords, and create the MythTV database, which we'll populate shortly. The population of this database is handled by mythtvsetup in the next step, and all MythTV add-on module database additions must be done AFTER running mythtvsetup at least one time.

# /sbin/chkconfig mysqld on
# /sbin/service mysqld start

Set the mysql root password, replacing ROOT_PWD with your chosen administrator password:

# mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('ROOT_PWD') WHERE user='root';
mysql> quit

Now we create the mythtv database (called mythconverg) to get us started:

$ mysql -u root -p < /usr/share/doc/mythtv-0.20/database/mc.sql
(enter the password you just set above when prompted)

Again, all subsequent database population for MythTV's add-on modules must now be done AFTER running mythtvsetup at least one time. Anyhow, It's worth customizing some parameters in /etc/my.cnf for optimal performance with Myth. I know next to nothing about the topic, but from experimentation and listening to people who do know what they're doing (I think), I found these adjustments to my.cnf under the [mysqld] section improve performance with both MythTV (esp. in the GUI) and MythWeb:

key_buffer = 16M
table_cache = 128
sort_buffer_size = 2M
myisam_sort_buffer_size = 8M
query_cache_size = 16M

13. Set up MythTV

There are a number of things you might want to figure out in advance to successfully complete your setup. First, recall what your video device was set up as (likely /dev/video0 if you have a single v4l card, DVB #0 if you have one DVB card). Note that the actual device number is NOT what determines what order MythTV will use your cards in. What matters is the order that you enter them in mythtvsetup, so your best card doesn't have to be /dev/video0. Set up /dev/video8 first, and it'll be the first card used for recordings.

You will also need your zip code (please tell me you know this...), and it would help to know the right listing from http://www.zap2it.com/ (for US users, other countries use different listings sources) that matches your service provider, so xmltv gets the right program listings (I screwed up the first time, because I was guessing, and most of the programming info was askew). US folks will also have to fill out some paperwork to use zap2it's new xml data feed listings (the only way to go now). See this page in the MythTV docs for details:


Now on to launching the MythTV setup utility. For this part, you need to have an X session started up, as the setup utility is an X application. Fire it up like so:

$ mythtv-setup

I'm told that non-US folks may have issues correctly getting through the tv_grab_xx/xmltv part of the setup if "focus follows mouse" is already set (in KDE's Control Center), so keep that in mind. Just set "focus follows mouse" when everything else is already configured.

Recent changes in the mythtv-setup and database population methodology broke the default path settings for the MythTV rpms, which should be /var/lib/mythtv/ for storage of recorded shows, and /var/cache/mythtv/ for live TV buffer. These directories are automatically created at install time, but you'll have to manually enter them in section 1 of mythtvsetup.

Those using a dedicated /storage partition, per my example, are recommended to create a /storage/recordings directory, and set it as their video store. You can do pretty much whatever you like here, such as recording to an NFS or samba mount, a software RAID array, or even to an LVM group so you can expand your /storage partition sometime down the road. Just make sure your mythtv user has permission to read and write to whatever location you choose.

Go through the setup steps in order. Follow the on-screen instruction, with aid from the MythTV website's documentation on this page:


NOTE: your system may appear to hang at step 3; give it time, it isn't locked up, that part just takes a while!

Once you've gone through the setup, you have to populate the MythTV database with some program info. I spent a good long time tweaking my channel lineup on zap2it's site to remove all the junk channels I didn't really care to have show up. Once you have your listings to your liking, you're ready to fill your database with programming info, so lets get some guide data:

$ mythfilldatabase

If you're using a guide data source other than zap2it (i.e., anyone outside the US and Canada), I'm told that you may well need to add a "--manual" flag to the end of that command to get it to work. Look at the output of "mythfilldatabase --help" for more clues if you have problems. Also, BE PATIENT! This step can take a fairly long time, depending on your internet connection speed and how many channels your service provides...

Of course, you'll need to re-run mythfilldatabase regularly, to keep your guide data up to date. Fortunately, MythTV has built-in support for scheduling when mythfilldatabase should be run. You can find it in the MythTV frontend under Utilities/Setup -> Setup -> General, on the last page of that section. Go ahead and fire up the backend and the frontend (I recommend starting them in separate shell windows, so you can differentiate backend and frontend output). In one shell window:

$ mythbackend

And in the other:

$ mythfrontend

I like my guide data updated daily, so I set the Run Frequency to 1. I recommend either leaving the execution window at the default size (Start at 2, End at 5), or increasing it slightly, as well as leaving the "Run mythfilldatabase at time suggested by the grabber" option enabled. If your grabber supports this option, it will help to distribute the load on your guide data provider's servers (zap2it does support it). Really, any good-sized window in which you generally don't have any recordings scheduled will do (note that the hours are in military time, i.e., 13 == 1:00 pm). Personally, I leave my window set to Start at 10:00 am and end at 2:00 pm, since I'm usually not recording anything in that window, and I should still get the latest and greatest guide data in time for each evenings' recordings.

It is also possible to run mythfilldatabase every night from cron, but this is no longer the preferred method. But if you insist, here's a reasonable crontab entry:

$ crontab -e
#----Insert the following text into your mythtv user's crontab----#
### Run mythfilldatabase every night at some random time after 10:01am
01 10 * * * sleep $(expr $RANDOM \% 14400) && mythfilldatabase > /var/log/mythtv/mythfilldatabase.log 2>&1
#----Cut above here (don't include this line)----#

There are various other options within mythfrontend that you can tweak... In the past, I've recommended enabling "De-interlace Playback", even if you're using an interlaced display (like a TV). However, I've found with the latest nvidia driver and its flicker filter, this is no longer necessary for TV output (note that the flicker filter can only be used on SVideo or composite TV-Out, it isn't an option for DVI or VGA). You're on your own for the rest of the settings. Just be sure to go through every section, and get to the point where you click a "Finish" button, otherwise some values seem to not get initialized (most notably, you may get crashes that say something about not being able to open the dsp).

Another setting I'd recommend enabling, especially if you're using an nVidia video card (not sure about others) is OpenGL VSync, which recently became a toggleable option. It isn't stable for everybody, but works very well for me on several systems (and I find it to be a must for optimal HDTV playback). If everything appears to be working, once you've gone through all the configuration steps, you can set your system up to automatically load everything at startup. And congrats, you've done the bulk of the work. You can stop here if you want, but if you're like me, you'll want everything to load automatically when the system boots.

14. Configure automatic startup

The necessary init script for the MythTV backend to automatically start at system boot is already in place for you, just simply turn it on:

# /sbin/chkconfig mythbackend on

If the backend isn't already running, save yourself a reboot and issue this command:

# /sbin/service mythbackend start

Now, because I have a few things that don't seem to want to play nice anymore (i.e., nvidia-settings don't load like they should, alsa volume levels aren't restored), I decided to create a quick little shell script in ~/.kde/Autostart/myth-load.sh to handle loading up all the extra goodies I need/want to auto-start, as well as force stubborn things to work. This script loads my nvidia settings, restores alsa volumes, launches irexec for my little power button script (on the Tips 'n' Tricks page), then launches mythfrontend, all in one fell swoop. Just copy and past all this into ~/.kde/Autostart/myth-load.sh (adjust accordingly for different desktop environments):


# Only do this stuff if we're on the main display
# (i.e., don't do this in a vnc session)
if [ `echo $DISPLAY | grep -c ":0"` -ge 1 ]
    # Load nVidia driver custom settings
    nvidia-settings --load-config-only &
    # Restore audio settings
    /usr/sbin/alsactl restore
    # Launch irexec for myth power button stop/start
    irexec &
    # Launch myth frontend
    mythfrontend &
    # Disable dynamic power management (screen blanking)
    /usr/bin/xset -dpms
    # Disable screen saver
    /usr/bin/xset s off

Don't forget to make it executable:

$ chmod +x ~/.kde/Autostart/myth-load.sh

While logged in to an X session, you'll also have to run gdmsetup, to set autologin for your mythtv user. You'll have to get a root terminal open (if you aren't logged into your X session as root already, which is a no-no), then:

# gdmsetup

In GDM Setup, on the first tab ('General'), you should see a section "Automatic login". Check the box for "Login a user automatically on first bootup" and select your mythtv user from the popup menu. Alternatively, if you are not very comfortable with Linux just yet, and you suspect there may be occasions where you've mucked something up to the point that an auto-login will lock up the computer, you might not want to use Automatic Login. Instead, you might opt to use the "Timed Login" option, to log the mythtv user in a few seconds after the login screen first appears. This way, you can circumvent the mythtv user logging in, and log in as root to hopefully correct whatever you've broken.

NOTE: if you installed the packages from kde-redhat, they probably supplanted gdm as your display manager and put kdm in its place. I like the look of Red Hat's gdm much better than kdm, so I changed it back by editing /etc/sysconfig/desktop and setting "DISPLAYMANAGER=GNOME". Not that you should be seeing the login screen often, my box is always sitting there logged in with the Myth UI up. Maybe I'll add some kdm info in a bit...

Anyhow, I recommend setting the Kicker (the panel at the bottom of the screen) to auto-hide, so it doesn't end up on-screen during video playback, disabling the screen saver, and disabling any monitor-related dynamic power management, or you may not be able to wake your system up if you don't have a mouse and keyboard connected. You can use the KDE Control Center to disable your screen saver, and edit your xorg.conf file to disable dpms (or at least the screen blanking parts). Note that the above myth-load.sh script actually issues a pair of commands at login time that should also disable dpms and the screen saver, but you can turn it off everywhere you can to be sure...

And finally, to turn on auto-hiding of the Kicker, right-click on the Kicker, choose 'Configure Panel...', then select the 'Hiding' tab, and select the radio button for 'Hide automatically'.

15. Configuring MythTV add-ons

When you installed MythTV using "yum -y install mythtv-suite", you not only installed MythTV, but also all of the add-on modules currently available. You've likely still got a bit of work to do to make some of them functional. The MythTV wiki and official docs cover the plugins much better than I ever did, so the following is mostly just a list of references.











Most of the emulators can be installed using yum, like so:

# yum -y install xmame fceultra snes9x




There isn't much to say about MythNews, its just a simple RSS feed reader. Go into MythTV → Utilities/Setup → Info Center Settings → News Settings and select the news feeds you want, and you're done with the setup.



Within the Setup section of MythTV, configure your movie storage directory (MythTV → Utilities/Setup → Media Settings → Video Settings → General Settings). You might want to look at the Tips 'n' Tricks page for some additional info on configuring mplayer and/or xine, especially if you have a wide-screen TV. Edit/insert metadata about your video collection in Utilities/Setup → Video Manager.




The mythtv-suite put almost everything where it needed to be. You need to read conf.php (/var/www/html/mythweb/config/conf.php) and configure things in that file accordingly. Once that's done, all you have to do is enable apache:

# /sbin/chkconfig httpd on
# /sbin/service httpd start

Now just point a web browser to http://your.mythtv.box.ip.or.dns.name/mythweb/ and go to town. Please note: MythWeb provides listings, lets you schedule recordings, and see what is already recorded. You cannot use this interface to control playback on your MythTV box in any way. There are also some controls for MythMusic and MythVideo.

Personally, I don't plan on using the web server on this box for anything *but* MythWeb, so I opted to move everything in /var/www/html/mythweb/ to /var/www/html/ and remove the mythweb folder, so I get to MythWeb with just http://htpc/ (htpc is the hostname for MythTV box). Alternatively, Zachary Hamm suggests creating an index.php file in /var/www/html/, containing the following to achieve the same effect:

<?php header("Location: /mythweb"); ?>

This works better for those who also run other web-based apps on their MythTV box (like phpMyAdmin, for example), and keeps the apache doc root a bit tidier.

If you wind up with a blank page when you try to use mythweb, it may be that you've left SELinux enabled. You can either disable it by setting SELINUX=disabled in /etc/sysconfig/selinux and rebooting, or alter the security context solely for httpd, like so:

/usr/sbin/setsebool -P httpd_can_network_connect=1

Additional MythWeb documentation:

16. Upgrading your system

Upgrading your MythTV installation to a new release is fairly straight-forward. As of MythTV 0.13, all database changes are handled automagically, so you merely have to upgrade your mythtv rpms when they become available. Occasionally, driver updates are also required (such was the case with the ivtv driver when upgrading to MythTV 0.13, and PVR-350 output in 0.14+ required ivtv 0.1.9+). The basic upgrade process should be as simple as:

# yum -y upgrade mythtv-suite

Note that this will NOT suffice to upgrade all sub-packages in the event of an updated build from ATrpms of the same major version. In other words, say 0.18.1-115 packages are released with some bugfix not in 0.18.1-114 (-114 and -115 are ATrpms build numbers), but mythtv-suite is already satisfied w/0.18.1-114 (mythtv-suite only needs 0.18.1 packages of any build number), so you'll have to specify all components manually (rpm -qa | grep myth for a list of 'em), or you can try the following:

# yum -y upgrade \*myth\*

If you experience any sort of problem following an update of this nature, try running a full yum upgrade of all packages. I believe Axel hates the above suggestion, but its always worked well for me... :)

If a driver update is required, you may need to:

# yum -y install <somedriver>-kmdl-$KVER <somedriver>
(<somedriver> could be ivtv, lirc, nvidia-graphics, etc.)

A general note about upgrading and installing rpm packages: you should NEVER use --nodeps to install or remove a package. If you can't get around using --nodeps, there is likely a packaging problem, which you should report upstream, to have it fixed. A tanked rpm database can do Very Bad Things™ to your system, and recovery is sometimes impossible. Try 'yum check' to verity its integrity, should you happen to have committed the --nodeps sin in the past.

Upgrading your kernel is a little bit more involved than upgrading only MythTV, because all custom kernel modules, both rpm-installed and source-installed, will have to be updated also. Kernel modules carry two different versions, one for the kernel they are for (the 'kernel version') and one for the actual module itself (the 'module version'). Everything but kernels and their matching kernel modules get upgraded automatically by 'yum upgrade'. However, note that cases where the kernel version on a kernel module remains the same, but the module version is incremented, an 'yum upgrade' will upgrade that kernel module. Essentially, you really only need to take extra measures when upgrading your kernel, as everything else gets handled automatically.

When you do come to a point where you need to upgrade your kernel, one of the nice features of installing from packages, rather than source, shows itself. For all the ATrpms kernel modules, you can simply type in the command...

# rpm -qa {alsa,ivtv,nvidia-graphics,lirc,video4linux}\* |grep kmdl

...to get a full list of all the kernel modules you have installed on your system. With that list in hand, you can now install your new kernel, along with all the corresponding updated kernel modules. For example:

# yum -y install kernel-2.6.20-1.2944.fc6
# yum -y install {alsa,ivtv,lirc,nvidia-graphics9755,video4linux}-kmdl-2.6.20-1.2944.fc6

You can also uninstall an older kernel and its kernel modules with a single command:

# yum -y remove kernel-<oldversion>

17. Miscellanea

This section has been moved to its own page, titled Tips 'n' Tricks.

18. Trouble-shooting

First and foremost, READ THE OFFICIAL DOCUMENTATION!!! Specifically, the page on Troubleshooting, at http://mythtv.org/docs/mythtv-HOWTO-22.html. Second, search the MythTV users *and* developers mailing list to see if this isn't already a known problem that might be fixed in CVS or have a work-around. Again, you can search the archives online at Gossamer Threads. Third, check out the wiki over at http://www.mythtv.info/, which also contains quite a bit of valuable information. Fourth, take a look at ATrpms Bugzilla and the Fedora Myth(TV)ology Wiki and Bug-tracker.

When trouble-shooting, I suggest exiting the frontend, stopping the backend and opening a pair of terminal windows. From one, start up the backend (as root, just type "mythbackend"). In the other, launch the frontend with verbose output (just type "mythfrontend -v all"). There should be a fair amount of output spit to the terminal windows that should give you (and the developers) a better idea of what is going wrong with your system. Please include that output when asking for help. Additionally, if you're getting a segmentation fault, your best bet for getting help determining the cause of the problem is to download the myth source code and compile it yourself in debug mode, then run it with gdb, the GNU debugger (how to do that is detailed at the above link). Only with a backtrace can the developers really help you if your setup is causing Myth to segfault.

I plan to further populate this section over time, when I can...


The changelog maintained here was getting too long, and really didn't serve much purpose anymore. It'll continue to exist in my source repo for historical purposes, but from here out, people should go to https://svn.wilsonet.com/projects/mythtvology/timeline to see what has changed.