.:HOWTO| Tips 'n' Tricks| Universal Remotes| High-Definition| Weblog:.
MythTV on Fedora
Welcome HOWTO >Printer-friendly Tips 'n' Tricks Universal Remotes High Definition
MythTV Links
Official Web Site Official Docs Mailing List Archive
Misc Links
Fedora Core Linux ATrpms ivtv Project PVR Hardware Photo Gallery
Better Browsers
Safari Mozilla Firefox OmniWeb Konqueror
This web site is...
Powered by Red Hat Linux
Sponsored by Turbosphere

Step-by-step guide to building a MythTV System on Fedora Core 3 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: 97 $
    $Date: 2005-06-22 13:05:04 -0700 (Wed, 22 Jun 2005) $

TABLE OF CONTENTS:

  1. Introduction
  2. Hardware
  3. Initial System Setup
  4. Firstboot setup -- create MythTV user and enable ntp
  5. Get and install apt, update your OS packages
  6. Kernel choices
  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 3 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). Note that for various reasons, things aren't entirely smooth if you're using an x86_64 system yet (apt doesn't support multi-arch systems, so you need to use yum or smart instead). I finally just got a new Athlon 64 system myself, so look for more x86_64-specific instructions in the future. 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. ;-)

The old Fedora Core 1 version of this doc is still available for those that need/want it. It is NOT being maintained anymore though and hasn't been for some time, so if you find any inaccuracies, refer to this version of the document for possible information to help you around them. I'm doing the same with the last revision of the Fedora Core 2 version and Fedora Core 3 version of this doc, though 2 and 3 are still fairly similar to the Fedora Core 3 version, much more so than FC1 is.

It was suggested to me by a number of folks that I provide PayPal account information for those wishing to contribute. Recent donations helped me acquire some AMD64 hardware. Hopefully, I can now better sort through multi-arch problems people are running into... Donations also 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, mostly due to a new job and another kid due shortly. 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, and enjoy!
-- 
Jarod Wilson
jarod@wilsonet.com

2. Hardware

I suggest you start here for information on hardware:

http://www.mythtv.org/docs/mythtv-HOWTO-3.html#ss3.1

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:

http://pvrhw.goldfish.org/tiki-pvrhwdb.php

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

http://www.mattmarsh.net/computing/pundit/

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:

http://ivtv.writeme.ch/tiki-view_faq.php?faqId=1#q33

3. Initial System Setup

This guide is geared toward using Red Hat's Fedora Core 3 Linux distribution. For the most part, this document should still be applicable to Fedora Core 2 and 3 as well. You can download the iso CD images for Fedora Core from one of the many Red Hat mirrors out there, the official list of which can be found here:

http://fedora.redhat.com/download/mirrors.html

The 2.6 kernel series includes several journaling file systems, some of which are 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 /video (or similar) partition for storage of all your recordings. Previously, XFS was my personal recommendation for the file system to use for such a purpose, but some additional stability issues with using XFS 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 still running XFS myself, and have for ages without a problem, but I'd have to lean toward suggesting JFS right now, so boot the installer with "linux jfs", then choose JFS for your /video partition. ReiserFS is also an option, though I believe JFS performs a bit better (XFS is even better still, at least, when its stable...). An example partitioning setup can be found below.

At the Installation Type screen, you want to choose a Custom installation (rather than Personal Desktop, Workstation or Server), because none of the defaults give us everything we need and/or add junk we don't need.

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

Partition Mount Point Size Format
/dev/hda1/boot50-100MBext3
/dev/hda2swapsame as RAM (ex: 512MB)swap
/dev/hda3/8-12GBext3
/dev/hda5/videoEverything elsejfs

Be sure to choose JFS (or XFS or ReiserFS) as the partition format type for the /video partition, 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 JFS. That'll allow you to increase the size of your /video partition transparently across multiple drives (which is exactly what I'm doing w/three 200+ GB drives in my master backend). Details on how to do that can be found in the official MythTV docs, at http://mythtv.org/docs/mythtv-HOWTO-23.html#ss23.3.

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), but 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 Firewall Configuration page, life will be much easier if you simply disable both the firewall and SELinux. Again, the firewall being enabled probably won't cause a problem if you only have one Myth box (though I'd allow at least ssh and http traffic), but if not properly tweaked, would prevent any secondary systems from being able to contact the master backend. As for 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. I don't know enough about SELinux yet to know what changes are needed, or care enough to want it on a Myth box, so I just assume make life easier and disable it.

On the package selection screen, select (at least) these package groups:

Some other packages that might be of interest, but are not required:

As suggested on the MythTV site, we're going to use KDE as our X environment for running MythTV. If you happen to be running another window manager, you can fire up a terminal session, and issue the command:

$ switchdesk KDE

Note that there seems to be a bug in the FC3 installer, where if one only installs KDE, your user desktop will default to twm instead of KDE, so you may need to run the above command the first time you login to your box, then logout and log back in, and all should be well.

Or, you can try your luck with another window manager. Others will work, but this doc is geared toward using KDE. As an aside, I've used MythTV under Gnome 2.2 through 2.8, all without issue, as well as under XFCE4, which is now included as an install-time option in FC3 (but I didn't care for, since I couldn't get a shell to overlay video -- bad for debugging). It should be noted that full-featured desktop like KDE or Gnome does add some memory and cpu overhead that may be undesireable for lower-end systems. If you're short on cpu power, you should probably take a look at something like WindowMaker, twm, Black Box or Rat Poison. 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 Rat Poison. I've actually successfully used Jim's WindowMaker setup on my EPIA now, and damn! The desktop loads a helluva lot faster than KDE. However, I can't alt-tab and get a console window to overlay Myth, which I do often for debugging purposes, so I'm back to KDE for the moment.

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

At the first boot setup screen, create a user called mythtv, with a password of your choosing. All further documentation assumes you are 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.

In that same first boot setup area, there is an option to enable 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 (I happen to know time-nw.nist.gov is just up the road from me in Redmond, WA, on the Microsoft campus) or leave it with the pre-populated values, which are from the ntp.org pool (pool.ntp.org aliases to a bunch of time servers around the globe). I actually have one system on my network that slaves off time-nw.nist.gov (and a few others for redundancy) then serves as the ntp server for the rest of my home network.

5. Get and install apt, update your OS packages

Well, only get and install apt if you're not using a multiarch 64-bit system (i.e., an Athlon 64 or EMT64 P4, where you're running both 64-bit and 32-bit libraries, which is what you get on FC, unless you're very crafty). If you're on a 64-bit system, you're much better off using yum instead. I still prefer apt when I can use it, but yum doesn't have the multiarch limitations that apt has, and is getting better all the time. To get started with yum, go to http://atrpms.net/install.html and follow the instructions for yum. After doing a "yum upgrade" (yum's equivalent of "apt-get update && apt-get dist-upgrade"), basically any "apt-get install some-package" command in this doc can be replaced with a "yum install some-package". It'll work for both 64-bit and 32-bit systems.

Those on 32-bit systems, you can simply install Axel Thimm's ATrpms-kickstart from http://atrpms.net/dist/fc3/atrpms-kickstart/. This provides you with apt and a pre-configured set of apt repositories, which include everything we'll need.

# rpm -Uvh http://atrpms.net/dist/fc3/atrpms-kickstart/atrpms-kickstart-25-1.rhfc3.at.i386.rpm

NOTE: the version number for the atrpms-kickstart package may be different when you read this, so double-check Axel's site if you get a file not found error and adapt accordingly.

Now we'll run a command that fetches all the latest metadata for apt to process, so it knows what is out there and available to install:

# apt-get update

Now go ahead and kick off an upgrade of all your installed rpms. This will take a while, lots of packages to download, roughly 265MB the last time I did it and paid attention, and this number tends to increase a bit with the age of the distribution, as more and more base packages are superceded by updates.

# apt-get dist-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, 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

Note that the rebuilddb 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.

Anyhow, with recent changes on ATrpms, you should be primed for a successful installation without any further changes to your apt setup. In the past, we had to account for issues with kde-redhat, but not anymore. Now you get a bare-bones sources.list that contains only the essential repositories.

However, you might also want to install Synaptic, a graphical frontend to apt, which you can use in place of the command line if you prefer. As it is still under fairly heavy development and not guaranteed stable, its in the at-testing repository (note than I've never had a single stability issue with it though). Its easy enough to simply install it like so:

# apt-get install http://download.atrpms.net/testing/packages/fedora-3-i386/atrpms/synaptic-0.55.3-21.rhfc3.at.i386.rpm

The adventurous people out there might want to enable at-testing and install medley-package-config to get the old default sources.list that has a myriad of repositories pre-configured. The less-adventurous can skip on down to the next section. If you want to take the plunge, then edit /etc/apt/sources.list, replacing at-stable with at-testing. After that, run these commands:

# apt-get update
# apt-get install medley-package-config
# mv /etc/apt/sources.list.rpmnew /etc/apt/sources.list
# apt-get update

That should outfit you with access to a ton of different repositories. Personally, I run a modified full-blown config, with only os/core, updates, atrpms, freshrpms, dag and kde-redhat enabled. I generally don't need anything from any of the other repos, but I use quite a bit out of those ones.

On a related note, here's the apt-get line you need to use if you have kde-redhat enabled to get their packages to install cleanly:

# apt-get install kdebase qt arts kdelibs gtk+ gtk2 redhat-artwork
# apt-get dist-upgrade

As hinted previously, note that Axel maintains a few different channels of rpms, with varying stability labels on them. This entire installation can now 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):

For those that are attempting this installation using apt, but without installing the atrpms-kickstart package, note that you'll have to do some editing of your apt repositories. At a minimum, you need to be set up to use the ATrpms at-stable repository and the core and updates repositories (provided by FreshRPMs, among others). 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:

http://lists.atrpms.net/mailman/listinfo/

As with any other mailing list, please search the archives first (you can find a link to them at the same location as above).

6. Kernel choices

Many of the features one used to only find in Axel's custom kernels for Fedora Core 1 and earlier Red Hat releases were full of back-ports from the 2.6 kernel. That means that pretty much everything we need is already in the latest Fedora Core 3 kernels provided by Red Hat, which are based on then kernel.org 2.6.11 release. Generally speaking, you should always install the latest errata kernel, shortly after the release of which Axel should have 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 and 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 two kernels are supported. As of this writing, kernel 2.6.11-1.34_FC3 is the latest released kernel.

If you happen to have a working yum install and aren't certain what the latest kernel is, yum handles kernels a bit differently than apt. This is actually one of the few things where I think yum is worlds better than apt -- you can simply issue the command 'yum install kernel' and the latest kernel will get installed (or 'yum install kernel-smp' for HT-P4 and SMP boxes). If you don't have a functional yum install or simply want to stick with apt, then for single-processor (except HyperThreading P4) systems:

# apt-get install kernel=2.6.11-1.34_FC3

For multiprocessor or HyperThreading Pentium 4 systems:

# apt-get install kernel-smp=2.6.11-1.34_FC3

We're going to set up a custom environment variable that will make life easier when installing kernel modules. To make this variable get set automatically on boot, we'll drop a file in /etc/profile.d, created like so:

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

Now edit /boot/grub/grub.conf and set default=0 if it isn't already, (which should correspond to the first listed entry, for the just-installed kernel), save your changes and reboot to start using the new kernel.

# vi /boot/grub/grub.conf
# reboot

Following all subsequent reboots, you should have the KVER variable set. On with the show...

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

For starters, let me say that aRts (the KDE sound server) does NOT work well with MythTV in many cases, though work has been done recently to remedy that (I have no problems with it enabled on my systems anymore). It is still highly recommended that you disable aRts from starting up if you encounter audio problems. To do so, while logged in as your mythtv user, choose "Control Center" off the Fedora (Red Hat) menu. Navigate through "Sound & Multimedia" to "Sound System" and deselect "Start aRts soundserver on KDE startup" ("Enable the sound system" on KDE 3.3 or later) and then click "Apply". On subsequent logins, aRts will not launch.

Note: I'd previously recommended gnome-alsamixer for configuring audio settings in a slightly more user-friendly way than the cli alsamixer. For whatever reason, gnome-alsamixer isn't being packaged on freshrpms.net anymore, but my prior aversion to kmix has largely disappeared, as it has improved greatly, and now works just about as well with ALSA-powered sound cards as gnome-alsamixer did (necessitated by the fact ALSA became the default sound system in FC2). Anyhow, the rest of this step is not essential, you can 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 the card should have been auto-configured. If you have some flashy new card, there's a chance you might need a newer ALSA version, which ATrpms does provide (I generally run the latest ATrpms packages). Those wanting to install the latest ALSA packages from ATrpms should do so with these commands:

# apt-get install alsa-kmdl-$KVER
# apt-get 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:

http://www.alsa-project.org/alsa-doc/

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 find at:

http://www.mythtv.info/moin.cgi/DigitalSoundHowTo

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:

http://wilsonet.com/mythtv/asoundrc.txt

Note that it is set up with output via S/PDIF and hardware decoding (by my 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.

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, my FC3 box 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 apt... MythTV has numerous required dependencies to function correctly, which apt automatically takes care of installing with one simple command:

# apt-get install mythtv-suite

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

If you get some error about failed dependencies, package conflicts, etc., with gtk2, gtk+, redhat-artwork, or something like that, please refer to the part about kde-redhat in the apt installation section...

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. 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

The final version of lirc 0.7.0 was released just a bit ago. There are lirc rpms available from ATrpms, installable via apt 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 rebuild for your specific remote, if the prebuilt packages don't work for you.

The earlier "apt-get 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:

# apt-get install lirc-kmdl-$KVER
# apt-get install lirc

Expand the appropriate section below for your IR receiver interface.

UPDATE: I think I finally have a completely viable, universal fix to get both ivtv and lirc modules (no matter which lirc module you're using, as long as its in modprobe.conf) loading very early in the boot process. I simply made a few changes to rc.sysinit, which you can add to your system via a patch I've generated. You'll still need to remove the first line from /etc/udev/rules.d/lirc.rules, leaving only 'KERNEL="lirc0",   SYMLINK="lirc"' in there (easy way to do so included below), then download and apply a patch:

# tail -1 /etc/udev/rules.d/lirc.rules > /etc/udev/rules.d/lirc.rules.tmp
# mv /etc/udev/rules.d/lirc.rules.tmp /etc/udev/rules.d/lirc.rules
# wget https://svn.wilsonet.com/svn/mythtvology/trunk/rc.sysinit-mm.diff
# patch /etc/rc.d/rc.sysinit < rc.sysinit-mm.diff

With these changes, everything finally initializes correctly at boot time on my boxes. I never really looked into this one much earlier, since my boxes never reboot. ;-)

Anyhow, 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:

http://www.newegg.com/app/ViewProductDesc.asp?description=80-100-202&depa=0

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:

http://www.newegg.com/app/ViewProductDesc.asp?description=80-100-401&depa=0

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

http://www.litwiller.net/mythtv/remote.html

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. Starting with MythTV 0.12, 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.

# /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> FLUSH PRIVILEGES;
mysql> quit

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

$ mysql -u root -p < /usr/share/doc/mythtv-0.18.1/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 for the first time. And if you get an error that look like this:

ERROR 1064 at line 4: You have an error in your SQL syntax near 'TEMPORARY TABLES ON mythconverg.* TO mythtv@localhost IDENTIFIED BY "mythtv"' at line 1

You can safely ignore it. Everything got created just fine, that line is for people using MySQL 4.x, which does not ship with many distros yet, because of licensing issues. It isn't necessary to upgrade, Myth will work fine with what you've got, but feel free to if you like. I'm actually running MySQL 4.1.9 out of the Fedora development tree on my master backend right now. No real discernable difference from 3.x though, until I started tweaking the config. It is 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), these adjustments to my.cnf under the [mysqld] section improve performance with Myth and MythWeb:

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

UPDATE: Here are the MySQL 3.x versions of the same:

set-variable = key_buffer = 16M
set-variable = table_cache = 128
set-variable = sort_buffer = 2M
set-variable = myisam_sort_buffer_size = 8M

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 that your video device was set up as /dev/video0. 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:

http://mythtv.org/docs/mythtv-HOWTO-5.html#ss5.4

Before you dive into the setup, you may want to make one little change so that you can actually see all the text you're supposed to see. There's a bug in Fedora Core 3's urw-fonts package that causes fonts to display MUCH larger than they should. Details on how to fix this can be found here:

http://www.users.on.net/~jani/dvico-mythtv-10.html#ss10.1

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:

$ mythtvsetup

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 mythtvsetup 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 /video partition, per my example, should obviously set /video/recordings/ for storage of recorded shows and /video/buffer/ for their live TV buffer. However, 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 /video partition sometime down the road. Just make sure your mythtv user has permission to read and write to whatever location you choose.

It is highly recommended that you go through the setup steps in order. Follow the on-screen instruction, with aid from the MythTV website's documentation on this page:

http://www.mythtv.org/docs/mythtv-HOWTO-9.html

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. A change in MythTV 0.17 requires that you start up the backend first. We'll daemonize it a bit later, but for now, just start it up like so:

$ mythbackend &

Assuming all goes well and the process doesn't exit on you (if it does, check out the troubleshooting section below), 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... It is also recommended to run mythfilldatabase every night from cron, to keep your show information up to date. To help mitigate possible flooding of our listings provider's servers, we'll set mythfilldatabase to run at some random time after 2:30am, as suggested by David Rees on the mythtv-users mailing list. We'll simply add an entry to the mythtv user's crontab, like so:

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

Myth also has built-in support for scheduling when mythfilldatabase should be run. You can find it somewhere in the frontend's setup. The randomization wasn't as good as the above the last time I looked (its been a while), but probably sufficient. I still use the cron job myself, actually running sometime mid-day, to help easy zap2it's traffic load (most people hit them in the dead of night).

Now start up the MythTV front-end (I recommend doing this in a separate shell window, so you can distinctly see the different output for the backend and frontend processes)...

$ mythfrontend

There are various 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):

#!/bin/bash

# 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 ]
then
    # 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/X11R6/bin/xset -dpms
    # Disable screen saver
    /usr/X11R6/bin/xset s off
fi
exit

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