Forum o satelitski, kabelski, zemeljski in IP TV
Danes je To Jun 06, 2023 9:22

Vsi časi so UTC+02:00 Evropa/Ljubljana

Napiši novo temo  Odgovori na temo  [ 3 prispevkov ] 
Avtor Sporočilo
OdgovorObjavljeno: Ne Jan 14, 2007 15:06 
Step-by-step guide to building a MythTV System on Fedora Core 6



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 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:, 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:, 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:, after which you may address your question to the mailing list. ;-)

Versions of this document for older Fedora Core versions are NOT maintained in any way, but are still available for historical purposes. I'd recommend just using 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. Donations 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!

2. Hardware

I suggest you start here for information on hardware:

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

And those looking at building the quietest Myth box possible should probably check out 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.

* Dedicated Master Backend System (not used at all for viewing):
o Case: Antec Full Tower
o PSU: Antec TruePower 480W
o Motherboard: Asus P2B-DS
o CPUs: Dual Pentium III 600MHz
o RAM: 4x 256MB PC133 DIMMs (1GB of RAM is excessive, but use it if ya got it)
o Hard Drives: 4x 7200rpm ATA/100 200GB Western Digital Caviar (in software RAID5 for video)
o Optical Drive: Generic CD-ROM
o Video Card: nVidia TNT2
o Sound Card: none
o NIC: 3Com GbE
o Video Capture Card: Hauppauge WinTV PVR-250
* High-Definition TV Capture and Playback System:
o Case: Antec Sonata
o PSU: Included Antec TruePower 380W
o Motherboard: Chaintech Summit 7NJL6 (full ATX nForce2 Ultra board)
o CPU: AMD Athlon XP 3200+ w/400FSB (overkill for most systems, but not for HDTV)
o RAM: 2x 256MB DDR-400 (PC-3200) for 512MB of RAM running in dual-channel DDR mode
o Hard Drives: 2x 7200rpm SATA 160GB Samsung SpinPoint (highly recommended by Silent PC Review)
o Optical: Black bezel 16x Sony DVD-ROM
o Video Card: 128MB 8x AGP Chaintech GeForce FX 5200 (fanless low-profile card)
o Sound Card: SoundBlaster Audigy OEM, feeding digital coax to a Yamaha amp
o NIC: Onboard Realtek
o Video Capture Card: pcHDTV HD-2000
o Display: 47" Panasonic HDTV, connected via an Audio Authority 9A60 VGA to component video transcoder
* Standard Definition Slave Backend and Playback System:
o Case: CoolerMaster ATC-620C-BX1 (black desktop micro-ATX)
o PSU: Enermax Whisper Series EG365P-VE 350W (adjustable fan speed for low noise operation)
o Motherboard: Asus A8N-VM CSM (nForce4-based micro-ATX)
o CPU: AMD Athlon 64 3500+
o RAM: 2x 512MB DDR-400 (PC-3200)
o Hard Drive(s): 7200rpm SATA 80GB Seagate
o Optical Drive: Black bezel Sony CD-RW/DVD-ROM combo
o Video Card: PCIe GeForce 6200TC (64MB onboard)
o Sound Card: SoundBlaster Audigy
o NIC: Onboard nForce4 GbE
o Display: 37" Westinghouse LCD High-Definition Television (via DVI at 1920x1080p)
* Standard-Definition Remote Playback-only System:
o Case: Travla C137 (the black one)
o PSU: external supply included w/case
o Motherboard: VIA EPIA M10000
o CPU: VIA C3 @ 1.0GHz
o RAM: 256MB DDR-266 (PC-2100)
o Hard Drive(s): 2.5" 4200rpm ATA/33 10GB Toshiba (laptop HD, requires adapter, but very quiet and low-noise)
o Optical: Samsung slimline (laptop-style) CD-RW/DVD-ROM combo drive
o Video Card: Onboard Unichrome/CLE266
o Sound Card: Onboard
o NIC: Onboard VIA Rhine-II LAN
o Display: 19" Monitor
* All-in-one Standard-Definition System:
o Case: ASUS Pundit (SiS chipset variant)
o PSU: Included with Pundit
o Motherboard: ASUS P4S8L
o CPU: Intel Celeron 2.0GHz
o RAM: 512MB DDR-333 (PC-2700)
o Hard Drive: 7200rpm ATA/133 200GB Maxtor
o Video Card: Onboard SiS 315 Integrated Graphics
o Sound Card: Onboard AC '97
o NIC: Onboard Broadcom BCM4401
o Video Capture Card: Hauppauge WinTV PVR-250

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:

The 2.6 kernel series includes several journaling file systems, 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 /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 (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, recent improvements to ext3 (such as b-tree hashed indexing) make it a perfectly suitable 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 /video 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 IDE hard drive):
Partition Mount Point Size Format
/dev/hda1 /boot 100MB ext3
/dev/hda2 swap same as RAM (ex: 512MB) swap
/dev/hda3 / 8-12GB ext3
/dev/hda5 /video Everything else ext3

If you wanted to use something other than ext3 for your /video 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 /video partition transparently across multiple drives. Details on how to do that can be found in the official MythTV docs, at 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:

* Desktop Environments -> KDE (K Desktop Environment)
* Applications -> Graphical Internet
* Applications -> Sound and Video
* Servers -> MySQL Database
* Servers -> Web Server

Optionally, you might also want to add these groups:

* Servers -> Windows File Server
* Servers -> Network Servers -> vnc-server
* Development -> Development Libraries
* Development -> Development Tools

As suggested on the MythTV site, we're going to use KDE as our 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 this doc is geared toward using KDE.

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

As an aside, I've used MythTV under Gnome 2.2 through 2.16, all without issue, as well as under XFCE4 (which 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 and damn! The desktop loads a helluva lot faster than KDE. Seeing as how I haven't had to do much of any debugging lately (and since I can just let the terminal I launch from be on my laptop), I'm somewhat inclined to switch to Rat Poison one of these days...
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 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. All further documentation assumes you are logged in 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: 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.18-1.2798.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/
(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
# wget

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 -- The primary classifications are as follows (from Axel's web site):

* stable packages imply minimal upgrading risk. They are considered very well tested. You will usually find slight modifications to Red Hat's own packages here.
* testing packages are provided on a "works for me" basis.
* bleeding packages means asking for trouble!

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: ... hrpms-list

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

* For users of the PVR-350's TV-Out:

Initially, you'll need another video output device hooked to a display in order to configure the PVR-350's TV-Out, unless you're extremely comfortable at the command line, in which case you can simply ssh into your PVR-350-equipped box (well, okay, you can also ssh in from another machine running an X server and run X-based apps over ssh's X forwarding, but...). I actually did all the setup of mine while the computer was connected to my TV via TV-Out on my GeForce 4 MX, in run-level 5. That way, I had a shell window and a browser window open, so I could easily cut and paste. Further instructions for configuring the PVR-350 can be found a ways down the page...

* For users of nVidia Video Cards:

Normally, Axel's nvidia rpms trigger the creation of an xorg.conf file, based on the one created by the installer, for use with the nvidia driver. However, the very minimal out-of-the box config is so minimal, the auto-creation step fails. The following work-around will take care of this problem:
# cat <<EOF>> /etc/X11/xorg.conf
Section "Files"

Section "Module"

nVidia's 8776 release works quite nicely for me right now (its what's pushing my own 1920x1080p LCD HDTV over DVI as I type). To make life easier, Axel has prebuilt kernel modules. Install for your running kernel like so:
# yum -y install nvidia-graphics8776-kmdl-$KVER
# yum -y install nvidia-graphics8776-libs nvidia-graphics8776

Simply replace the 8776 with another version number, and you can install the older version instead. Note that you can actually have multiple versions installed, and switching between them is as easy as:
# init 3
# nvidia-graphics-switch 8776 (or 9625, or whatever else)
# init 5
(you can *probably* get away with simply reloading X at this point, but reboot if you run into problems)

Axel's nvidia rpms insert some necessary lines into modprobe.conf and (as previously indicated) modify your xorg.conf file for use with the nvidia driver, based on your initial xorg.conf file, which is saved for safety's sake as xorg.conf.nvidia.bak. While not necessary, I suggest adding Load "v4l" in the "Module" section near the top of your xorg.conf file, to enable optimal v4l to X video transfer and v4l picture controls.

If you're in X right now, simply log out to relaunch X with the new configuration. If you're at the command line, either switch to run-level 5 ("init 5") or run "startx". Once you've verified this configuration is working, you'll likely want to look into the additional options below, to enable TV-Out, accelerated rendering, etc.

Here's an example Device setup section for a GeForce 4 MX video card using the 1.0-8776 nvidia driver to output to an NTSC television via S-Video (this should work equally for any GF4 or FX series card, as well as GF2/3):

Section "Device"
Identifier "Videocard0"
Driver "nvidia"
VendorName "Chaintech"
BoardName "nVidia GeForce 4 MX 440"
#Option "RenderAccel" "1"
# TV Out Setup
Option "TVStandard" "NTSC-M"
Option "TVOutFormat" "SVIDEO"

Those with particularly cantankerous displays and/or people who want to pass their signal through an A/V switchbox may have problems with their card/drivers not auto-detecting the attached display type, in which case, you can add an Option line to the above Device section to force the display type, such as this one:
Option "ConnectedMonitor" "TV"

As for overscan, nvidia driver versions prior to 6106 used a fixed value option in the above Device section, which required a restart of X when adjusting. The latest driver versions rely on the nvidia-settings utility to set your overscan with a slider, and you can do so without restarting X. You can also adjust gamma, contrast, color balance, etc., with the nvidia-settings utility. All the settings are saved on a per-user basis, and according to nVidia's docs, should be reactivated at login if you do the following:
$ echo "nvidia-settings --load-config-only &" >> ~/.xinitrc
$ echo ". /etc/X11/xinit/xinitrc" >> ~/.xinitrc

This isn't actually working for me right now, along with audio levels not being properly restored, so I did something else, which you can find down in the Configure Automatic Startup section.

Another excellent feature you can activate in nvidia-settings is the flicker filter. It helps to greatly reduce the effects of interlace jitter. With the filter enabled, I no longer bother enabling software deinterlacing in Myth for playback. Note that the flicker filter can only be enabled on TV-Out (SVideo or Composite), not over VGA or DVI.

Note: overscan is possible with some older nVidia cards, as well as some 3Dfx cards, by using nvtv, which but you can find here:

My secondary MythTV system had a GF2MX in it for a while, with which I was using nvtv to blow the picture up a bit. It did a fine job. Its been so long since I used it though, I can't remember anything about it that would be of use. Really, given the price, I just recommend upgrading to a GF4MX or GF MX 4000.

There are a few settings not explicitly specified in the above configuration, as most of them can be auto-detected. However, it is possible you'll have to force some settings if auto-detection doesn't work. All these options are well-documented on nVidia's web site in the documentation files available in the Linux driver download area (

Not sure exactly what has changed in the nvidia driver, but most folks no longer seem to be able to use the RenderAccel line without having problems. However, I'm not sure what added benefit it provides anymore, since contrary to my earlier belief, it isn't necessary for me to use XvMC... With 6629, I didn't have any problems with it on any of my motherboards with VIA chipset or nVidia's own nForce2 chipset, none of which play nice with RenderAccel enabled anymore, but it doesn't seem to make any difference, I can still play back even HDTV video just fine without it.

For reference, and because many people have asked, I'm posting full copies of the xorg.conf files from both my HDTV-connected and SDTV-connected systems. My HDTV system uses a custom 960x540p mode for the MythTV GUI and standard-definition recordings and a custom 1920x1080i mode for HDTV content to output to a High-Definition TV through an Audio Authority 9A60 VGA to Component Video converter. I used to feed this set via S-Video, and while the picture was good, it can't touch the signals I'm now feeding the HDTV w/the Audio Authority adapter. My secondary system outputs via S-Video to a plain old 27" analog TV.

* For users of SiS cards (and Pundit-S):

The original Asus Pundit's onboard video controller is made by Silicon Integrated Systems (the later Pundit-R has an onboard ATI Radeon). Accelerated video is not supported by Fedora Core's native video driver. You'll want to obtain the binary SiS driver, or MythTV performance will suffer greatly (and TV-out won't work right).

Use wget to get the binary SiS video driver
$ cd ~/sources
$ mkdir sis_drv
$ cd sis_drv
$ wget ... ent.tar.gz
$ tar -xzvf sis_drv.o_xorg_gcc3_current.tar.gz
$ su
# mv /usr/X11R6/lib/modules/drivers/sis_drv.o /usr/X11R6/lib/modules/drivers/sis_drv.o.orig
# cp sis_drv.o /usr/X11R6/lib/modules/drivers/sis_drv.o
# exit

Note: also lists a SiS Display Control Panel, which might be of use, especially for folks that need to tweak their display settings a bit and don't want to deal with command-line text-file hacking. I've used it myself, and it certainly is a handy tool. You can adjust overscan and underscan, flicker reduction, display mirroring, etc., all on the fly without restarting X.

Now run the system-config-display utility to change the video driver.
# system-config-display

Choose the 'Advanced' tab, then press the 'Configure' button for the video card type.

Choose the 'SiS 650' card. This will set the driver to 'sis'. Also click on 'Custom memory size' to the value you have set in the BIOS (8 to 64M).

Press the 'Ok' button, then press the 'Ok' button again.

Log out of your X session (if you had one active) and log back in for the settings to take effect.

Here is an example /etc/X11/xorg.conf 'Device' section for the ASUS Pundit:

Section "Device"
Identifier "Videocard0"
Driver "sis"
Option "XvOnCRT2" "true"
Option "ForceCRT2Type" "SVIDEO"
#Option "ForceCRT2Type" "TV"
#Option "CHTVOverscan" "false"
Option "CHTVOverscan" "true"
VendorName "Silicon Integrated Systems"
BoardName "SiS 315/650"
VideoRam 65536

And finally add Load "v4l" in the "Module" section near the top of your xorg.conf file, for optimal v4l to X video transfer and v4l picture control. For reference, here's an xorg.conf file for the Pundit:

* For users of Via EPIA onboard Unichrome graphics:

I'm now running my EPIA M10000 system as my secondary viewing system, using the onboard Unichrome graphics chip, outputting to a 27" analog TV via S-Video. The quality is quite good, and the Unichrome driver is coming along quite well. Current CVS Myth supports use of the Unichrome driver's XvMC support to enable hardware decoding of mpeg2 content (like PVR-x50 recordings) with very minimal cpu usage. I'm using the Unichrome packages provided by Terry Barnaby with my EPIA, which is still running FC2. Visual quality might not be quite as good as the PVR-350's output for TV, but this is a much better output for general-purpose use, and still very good (it passes the CNN ticker test). I have zero problems playing back any of my xvid/divx/ffmpeg dvd rips using the Unichrome for output, while with the 350, only some types of rips worked smoothly. I have yet to try transcoding a MythTV mpeg2 capture to mpeg4 to see how it does...

For reference, here is my xorg.conf:

More to come, as the Unichrome driver begins to stabilize, and we figure out how to include binary unichrome-enabled Myth packages on ATrpms...

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 find 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 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, 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 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

* For ivtv-based cards (PVR-150/250/350/500, M179, MPG600, etc):

As of this writing, the Hauppauge PVR-150, PVR-150MCE, PVR-250, PVR-250MCE, PVR-350, PVR-500, AVerMedia M179, Yuan MPG160 and Yuan MPG600 are all supported by the 0.7.x series and later ivtv driver, which is what'll get installed from the ATrpms stable repository. I have a PVR-150, PVR-250 and PVR-500 in production use myself, all working quite nicely.

Go ahead and install the ivtv driver components, like so:
# yum -y install ivtv-firmware
# yum -y install ivtv-kmdl-$KVER

For PVR-350 output on FC6, you'll need to install the ivtv_xorg package. This is done simply enough:
# yum -y install ivtv_xdriver

Now, edit /etc/modprobe.conf to add ivtv-specific configuration info. For the PVR-150/150MCE/250/250MCE and PVR-350 users that aren't using its TV-Out, for NTSC, this should do the trick:
# ivtv modules setup
alias char-major-81 videodev
alias char-major-81-0 ivtv

For a PVR-500, only one more line to append to the above (the PVR-500 appears to ivtv more or less as a pair of PVR-150 cards, so the setup for any two single-tuner cards is the same as the setup for a PVR-500):
alias char-major-81-1 ivtv

PAL and SECAM users may need an additional parameter, if video only comes in black and white (reportedly needed for some newer cards):
options ivtv tda9887=0

And other PAL users may need even more, for some newer cards that may not get everything auto-detected properly:
options ivtv ivtv_std=2 tda9887=0

NOTE: Dutch users are encouraged to check out the forum at for more information.

As for users of the M179 (and probably Yuan MPG600), tuner detection (and possibly msp detection) doesn't work on these cards just yet, so you may have to manually specify them, like so:
# ivtv modules setup
alias char-major-81 videodev
alias char-major-81-0 ivtv
options ivtv tuner=2
options msp3400 once=0 simpler=1 simple=0

Users of the PVR-350 will need an additional line if they want to enable TV-Out, so their modprobe.conf additions should look like this:
# ivtv modules setup
alias char-major-81 videodev
alias char-major-81-0 ivtv
install ivtv /sbin/modprobe --ignore-install ivtv; /sbin/modprobe ivtv-fb

NOTE: Most of the PVR-350 TV-Out information contained here is derived from the TvOutHowto on the ivtv wiki site, with slight modifications to be Fedora/Red Hat specific (and subsequent changes for 2.6 kernels).

We're going to make little modification to the kernel boot line in your grub.conf file that should force the ivtv frame buffer to load on /dev/fb1, as well as allow the ivtv-fb module to be loaded and unloaded. Without doing this, unloading the ivtv-fb module would probably crash your system. To the end of all 'kernel /vmlinuz...' lines in /boot/grub/grub.conf, append 'vga=791', then reboot your system. This tells the kernel to load a frame buffer for your video card at 1024x768, 16-bit color. I use this all the time myself, simply so I can see more when I'm not in X. I'd always done this on my 350-equipped box without even thinking about it, which could explain some of why I've not run into some of the problems other folks have...

Now try loading up the ivtv driver:
# /sbin/depmod -a
# /sbin/modprobe ivtv

If you run into problems along the lines of a message saying memory can't be allocated when trying to either modprobe ivtv or use the card (like cat'ing video from /dev/video0), many folks seem to need to use the following command:
echo 16384 > /proc/sys/vm/min_free_kbytes

Not sure why this is necessary for some folks and not for others (I don't seem to need it). But if that helps, make it permanent with an entry in /etc/sysctl.conf:
# echo "# Fix ivtv memory allocation problems" >> /etc/sysctl.conf
# echo "vm.min_free_kbytes=16384" >> /etc/sysctl.conf

Again, the version of ivtv from the ATrpms stable repository should include support for all the latest tuners, but lots of new ones seem to be popping up lately. If you do indeed come up with an unknown tuner type, you should post a message to the ivtv-devel mailing list, with the entire contents of /var/log/messages from between
ivtv: ==================== START INIT IVTV ====================
ivtv: ==================== END INIT IVTV ====================
and the good folks over there can help set you back on course (I'm on that list too). An easy way to get the required info out of your log file is to run this shell script:

tac /var/log/messages |
sed -n '/=\ \ END INIT IVTV\ \ =/,/= START INIT IVTV =/p;

You can subscribe to the ivtv-devel mailing list here: ... ivtv-devel

With the ivtv-fb line in your modprobe.conf, your system will automatically load up the ivtv-fb module. If you have that line commented out, you can load the ivtv-fb module up manually, with this command:
# /sbin/modprobe ivtv-fb

Check that your card is being properly recognized:
# /sbin/lspci -v

The lspci output should return something like this for a PVR-250 within the output (rev2, iTVC16, thus "Unknown device 0016"):
01:08.0 Multimedia video controller: Internext Compression Inc: Unknown device 0016 (rev 01)
Subsystem: Hauppauge computer works Inc.: Unknown device 4009
Flags: bus master, medium devsel, latency 32, IRQ 12
Memory at dc000000 (32-bit, prefetchable)
Capabilities: [44] Power Management version 2

Or like this for an M179:
01:07.0 Multimedia video controller: Internext Compression Inc iTVC15 MPEG-2 Encoder (rev 01)
Subsystem: Avermedia Technologies Inc: Unknown device a3cf
Flags: bus master, medium devsel, latency 32, IRQ 5
Memory at d8000000 (32-bit, prefetchable)
Capabilities: [44] Power Management version 2

And finally, like this for a PVR-350:
00:07.0 Multimedia video controller: Internext Compression Inc iTVC15 MPEG-2 Encoder (rev 01)
Subsystem: Hauppauge computer works Inc.: Unknown device 4000
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at e0000000 (32-bit, prefetchable)
Capabilities: [44] Power Management version 2

Those intending to run X on their PVR-350's output(s) will want to make note of their PCI bus ID, which is the very first part of that lspci output (the 00:07.0 part in the above example), because it'll have to be specified in your xorg.conf file.

Also check that your video device(s) exist:
$ ll /dev/video?
1 root root 6 Feb 13 18:23 /dev/video -> video0 lrwxrwxrwx 1 root root 6 Feb 06 2005 /dev/video -> video0
crw------- 1 mythtv root 81, 0 Feb 06 2005 /dev/video0
crw------- 1 mythtv root 81, 24 Feb 06 2005 /dev/video24
crw------- 1 mythtv root 81, 32 Feb 06 2005 /dev/video32

Make a note of what your video device has been set up as (device /dev/video0 in this case), as you will need to inform MythTV of this fact later on. You can determine exactly what device ivtv is configured on by looking in /var/log/dmesg just after loading the module. For example, you should see something like this:
# /bin/dmesg |grep Initialized
ivtv: Initialized WinTV PVR 250, card #0

I believe M179 users may see failure messages regarding i2c. I think the primary use of i2c on the PVR-x50 is for the IR interface, which the M179 does not have. I'm not certain on that one though... And if you've got multiple cards, you'll see multiple lines in dmesg, like so:
# /bin/dmesg |grep Initialized
ivtv: Initialized WinTV PVR 250, card #0
ivtv: Initialized WinTV PVR 350, card #1
ivtv: Initialized AVerMedia M179, card #2

If it isn't already obvious, card #0 corresponds to /dev/video0, card #1 to /dev/video1, etc.

You'll also need to take note of the frame-buffer device that ivtv-fb grabs. You can find that out with this command (followed by example output):
# cat /var/log/messages |grep "iTVC15 TV out"
Feb 7 21:17:39 htpc kernel: fb1: iTVC15 TV out frame buffer device

In this case, the PVR-350's TV-Out grabbed /dev/fb1. Most likely, you'll either get fb0 or fb1. You'll need to know that for your xorg.conf file later on.

The next step is to test the functionality of the TV-Out connection. First, remove the saa7127 module, so we can subsequently reload it with a test pattern. If you only have one input to your TV at your disposal, and you're already using it with your video card's TVOut, it is perfectly safe to unplug that connection and substitute the 350 for it. Simply switch the connections back when you've seen the 350 test pattern:
# /sbin/rmmod saa7127
# /sbin/modprobe saa7127 test_image=1

If everything looks good at this point, unload the saa7127 module and reload it without the test pattern:
# /sbin/rmmod saa7127
# /sbin/modprobe saa7127

I've heard at least one report that the test_image parameter doesn't seem to be working these days. I haven't actually used the output on my 350 in ages, so I can't easily confirm or deny that with the lack of spare time I've got these days. You might try forging ahead at this point, even if the test_image test doesn't work. Another test you might have more success with is this, which will attempt to play video off the card right back out to your TV:
# /usr/bin/ivtvfbctl /dev/fb0 -noglobalalpha -localalpha
# dd if=/dev/video0 of=/dev/video16 bs=64k
(control-c to stop)
# /usr/bin/ivtvfbctl /dev/fb0 -globalalpha -nolocalalpha

Now you need to set some aspects of the capture card for test capturing. In this case, we're going to make sure the card is set up for tuner input, using the NTSC (US) video standard, and full NTSC resolution (720x480). The next few lines 1) set NTSC as the video standard, 2) select the tuner for input, and 3) set the resolution. NOTE: Prior to ivtv 0.8.0, these settings were handled via ivtvctl, but as of 0.8.0, are rolled into v4l2-ctl, which aims to control any v4l2-compatible device, not just ivtv cards.
# /usr/bin/v4l2-ctl -s ntsc
# /usr/bin/v4l2-ctl -i 0
# /usr/bin/v4l2-ctl -v width=720,height=480

Note that not all cards have their tuner input at position 0, so take a look at the output of the following command to see what your other options might be:
# /usr/bin/v4l2-ctl -n

NOTE: If you have multiple cards, understand that the ivtvctl and v4l2-ctl utilities assume you're operating on /dev/video0 if no device is specified. On any ivtvctl or v4l2-ctl command lines, tack on a "-d /dev/videoX" to operate on any other card (i.e. add -d /dev/video1 to work on your second card).

And by popular demand, here is the PAL version:
# /usr/bin/v4l2-ctl -s pal
# /usr/bin/v4l2-ctl -i 0
# /usr/bin/v4l2-ctl -v width=720,height=576

And finally, the SECAM version:
# /usr/bin/v4l2-ctl -s secam
# /usr/bin/v4l2-ctl -i 0
# /usr/bin/v4l2-ctl -v width=720,height=576

MythTV controls these settings internally, so be sure to set similar values when we get to the MythTV setup GUI portion of our tour. Now hook up your cable or antenna to your cards's tuner input if you haven't already done so (or some other video source to the S-Video or composite input), and we'll try to capture some video... Press Ctrl-C to stop the video capture.
# cat /dev/video0 > /tmp/test_capture.mpg
(ctrl-c to stop capture)

Use that copy of mplayer you installed a bit ago (as part of the mythtv-suite install) to view the capture:
# mplayer -vo xv /tmp/test_capture.mpg

If you're using the PVR-350's output, you won't be able to use -vo xv, as the ivtvfb driver doesn't have any Xvideo support. Instead, substitute -vo x11, like so:
# mplayer -vo x11 /tmp/test_capture.mpg

If you get something that looks and sounds intelligible, then congrats, your card is good to go! If not, and you're using the tuner input, it may be that you aren't tuned to a channel you actually have a signal on. Try this combo, which will let you watch the mpeg2 stream off the card while changing channels:
# /usr/lib/ivtv/ &
# mplayer -vo xv /dev/video0

Use the ptune UI to change channels, frequency tables, TV standard, etc., as necessary, until you find a working channel. If you still get nothing, you probably should talk to the ivtv list.

NOTE: the latest mplayer builds from ATrpms try xvidix output before xv output. However, xvidix can only be used when running with root priveleges, and for whatever reason, some systems aren't properly falling back to xv when mplayer isn't run as root, mplayer either hangs, or even segfaults. The extra '-vo xv' tells mplayer to use X-video output, which is the same output method Myth (typically) uses.

To hear audio with this video capture when played back using mplayer and the 350's output, audio output is going to be through your sound card, not the PVR-350's audio outputs. Personally, I piped the 350's audio outputs back into the line in port on my sound card, and then the sound card feeds my speakers, because system, MythMusic and mplayer audio (currently) can only be output through a sound card (but work is underway to change that).

If you get the following error:
cat: /dev/video0: Input/output error

Run the following commands to reload the driver (this won't work for PVR-350 users if the ivtv-fb module is loaded -- see above):
# /sbin/rmmod ivtv
# /sbin/modprobe ivtv

Now try the capture again.

If you don't have any sound, it is possible that the correct msp3400 module didn't get loaded for one reason or another. To remedy that situation, follow these steps:
# /sbin/rmmod ivtv
# cd /lib/modules/$KVER/kernel/drivers/media/video
# mv msp3400.ko msp3400.ko.orig

Then reload the driver yet again, and try the video capture one more time:
# /sbin/depmod -a
# /sbin/modprobe ivtv
# cat /dev/video0 > /tmp/test_capture.mpg
# mplayer /tmp/test_capture.mpg

Now that you have video capture working, we'll try to play some video through the PVR-350's output(s). First, we'll tweak some of the cards settings, then read video in and immediately pipe it out:
# /usr/bin/ivtvfbctl /dev/fb0 -noglobalalpha -localalpha
# dd if=/dev/video0 of=/dev/video16 bs=64k
(control-c to stop)

At this point, you need to connect the PVR-350's video output to something you can actually see its output on. For those with a single TV input, once again, you can type the commands in, then move your cables around. Note that sound for this test will be fed out the 350's audio outputs. If you see and hear what you'd expect from television, you're ready to keep moving on, so reset the alpha settings on the card (which MythTV handles internally, so you shouldn't have to do this again):
# /usr/bin/ivtvfbctl /dev/fb0 -globalalpha -nolocalalpha

If you got video, but there were like 20 to 50 evenly spaced horizontal lines overlaying it (also described to me as a lot of yellow and green dots), try tweaking the ivtv-fb driver with this command:
/usr/bin/ivtvfbctl /dev/fb1 -alpha -on -globalalpha -nolocalalpha

Then run the dd test again, and with luck, the picture will look like it should. If not, rinse and repeat from the beginning...

You can verify all the settings for your card, see possible inputs, video standards, etc., with various flags to the v4l2-ctl command:
# /usr/bin/v4l2-ctl -h
(list all available options)
# /usr/bin/v4l2-ctl --all
(display all available information about current settings)
# /usr/bin/v4l2-ctl -n
(list inputs on the card)
# /usr/bin/v4l2-ctl --list-standards
(list standards -- could be particularly useful to set a specific pal variant

NOTE: MythTV controls the capture resolution and bit rate internally, so MythTV starts controlling the card, you shouldn't have to worry about any of this gunk.
Running X on the PVR-350's TV-Out-

For starters, recall the PCI bus ID of your PVR-350. Mine was 00:07.0 from the example output above. I'm honestly not certain what the "best" way to do this is anymore. What seems to work reliably is to take the output of lspci, convert it to decimal and throw a "PCI:" in front of it, so you'll end up having a line in xorg.conf that reads 'BusID "PCI:0:7:0"'. If your bus ID was something like 01:0f.0, you'd use 'BusID "PCI:1:15:0"'. See for more coverage on the matter.

You can simply download my (ntsc) xorg.conf file for the PVR-350, edit the PCI bus ID and frame-buffer device lines to match your system, and you *should* be good to go. PAL users will have to check out the ivtv wiki TvOutPal HOWTO for PAL-specific info. You can grab my PVR-350 xorg.conf file here:

To be on the safe side, I highly recommend making a backup of your current xorg.conf file before putting your tailored xorg.conf file into place:
# cp /etc/X11/xorg.conf /etc/X11/xorg.conf.pre350
# mv /path/to/customized/xorg.conf-PVR350.txt /etc/X11/xorg.conf

Assuming you're still in run-level 5 at this time, connected to your display with your video card's TV-Out, move your cabling and/or switch inputs on your TV over to the PVR-350 and hit ctrl-alt-backspace to kill off X and restart it on the PVR-350. You ought to be greeted by a login screen. If you are, you're in business. If not, you probably did something wrong, so retrace your steps from the beginning of this section. =)

NOTE: there is more X/TV-Out related info at the start of the ivtv-fb.c file in ivtv/driver if you download the ivtv source code.

Once you actually have MythTV up and running, you'll need to make some changes within the frontend specific to using the PVR-350's output, which are covered in section 13, Set Up MythTV.

The final touch is to rebuild your system's initial ram disk to include the drivers for the 350's output, so that you can have the driver load early enough in the boot process that rhgb will work over it. First up, you'll need to make some changes to /sbin/mkinitrd. A patch that adds an extra flag "--ivtvdev" can be found right here. This patch hasn't yet been heavily tested, but should do the job, if I haven't lost my marbles (again) -- feedback welcomed. Download the patch, make a backup copy of mkinitrd and apply the patch:
# wget --no-check-certificate ... ivtv.patch
# cp /sbin/mkinitrd /sbin/mkinitrd-ivtv
# patch /sbin/mkinitrd-ivtv <mkinitrd> testcap.ts
libiec61883 warning: Overlayed connection on channel 0.
You may need to manually set the channel on the receiving node.
Starting to receive
(hit ctrl-C)

You should be able to play the file back using mplayer:
$ mplayer -vo xv testcap.ts

At the moment, you'll have to figure out manually what channels do and don't work. I created a custom lineup with Zap2it containing only the channels I found I could get off the FireWire port on my box. You'll also need a way for Myth to change the channels on your cable box. If you're using a DCT-6200 series cable box, MythTV 0.18.1 debuted internal channel-change support over FireWire, so no external channel-change app required, which definitely simplifies setup. Once you've figured all that out, you're ready to set up the capture device for Myth to use.

Fire up mythtvsetup, and navigate into section 2 to set up a new capture device. Set the card type to "FireWire Input", FireWire port to 0 (unless you got something different from plugreport), FireWire Node to whatever plugreport said, FireWire speed to "100Mbps" (more than sufficient, this option may go away in the future) and leave Default Input as "MPEG2TS" (the only current option). Assign the custom lineup to your FireWire input, an external channel change command if you're not using a DCT-6200 series box, a known-good starting channel, and that's about it. Works for me, anyhow. :-)

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 rebuild for your specific remote, 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.

* Using the IR port on a PVR-x50:
* Using the IR port on your bttv card:

There are quite a few different possible remote control interfaces used across the wide array of bttv cards. Many of them SHOULD work with the latest lirc kernel module available from ATrpms, but maybe not all. You'll have to do some investigation of your own to figure o

Na vrh
 Naslov prispevka:
OdgovorObjavljeno: Po Jan 15, 2007 21:47 
* Using the IR port on your bttv card:

There are quite a few different possible remote control interfaces used across the wide array of bttv cards. Many of them SHOULD work with the latest lirc kernel module available from ATrpms, but maybe not all. You'll have to do some investigation of your own to figure out which lirc interface type your card uses, but the types that should work are (from the lirc driver types in the rpm spec file):
lpt1, sir_com3, it87, flyvideo, avermedia, tekram_bt829, udp, avermedia98, com1, hauppauge

My AVerTV Studio card uses the avermedia98 lirc driver, and works quite nicely with this rpm. The actual kernel module used is lirc_gpio, so I add this line to my /etc/modprobe.conf file:
alias char-major-61 lirc_gpio

Next, I dropped the appropriate lircd.conf file for my remote in place. Config files can be found in /usr/share/doc/lirc-0.7.0/remotes/<your>. I simply did this:
# cp /usr/share/doc/lirc-0.7.0/remotes/avermedia/lircd.conf.avermedia98 /etc/lircd.conf

* Using a serial IR receiver:

Most serial IR receivers should work with the lirc_serial module, but will need some extra parameters, such as port, irq, and possibly receiver type passed to them. All of them will require the following in /etc/modprobe.conf:
alias char-major-61 lirc_serial

If your receiver is hooked to the first serial port, aka COM1, you'll need these extra settings in /etc/modprobe.conf:
options lirc_serial irq=4 io=0x3f8
install lirc_serial /bin/setserial /dev/ttyS0 uart none ;\
/sbin/modprobe --ignore-install lirc_serial

If your receiver is hooked to the second serial port, aka COM2, you'll need these settings:
options lirc_serial irq=3 io=0x2f8
install lirc_serial /bin/setserial /dev/ttyS1 uart none ;\
/sbin/modprobe --ignore-install lirc_serial

The one other thing to look out for are serial receivers that are "Igor-style", which use a slightly different chipset, requiring an extra item "type=4" tacked onto the end of the appropriate "options ..." line above.

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 --no-check-certificate ... rc.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, but its a touch spendy, since you don't have the option to buy it without the MCE remote: ... 202&depa=0

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 ... 401&depa=0

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, 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>> /etc/rc.d/rc.local

Also note that Fedora Core 3 and later use HAL and udev, which as configured out of the box, break Myth's monitoring of optical drives for inserted discs, so to get it to work again, you need to change the line for your CD/DVD drive in /etc/fstab, altering the fstype from auto to iso9660 and add ",user" to the end of the mount options.

Within the Setup section of the MythTV frontend, you need to specify your image storage location (MythTV → Setup → Image Settings).

There are several packages you'll have to install to get a functional MythGame, namely all the emulators -- x-mame, fce ultra and snes9x. You can install the required packages via yum like so:
# yum -y install xmame fceultra snes9x

You'll then have to configure MythGame through the MythTV configuration section (MythTV → Utilities/Setup → Media Settings → Game Settings). Pretty much everything is already correctly configured when you use the mythtv-suite install method. MythGame launches fine for me, appears to find all my rom files, and drops me to the selection screen. The few roms I've tried with xmame all seem to do exactly what they're supposed to, though the volume level is a bit on the high side, and I haven't taken the time to try and adjust it. I have yet to try snes9x (works great on my Mac, just haven't got around to it on a Myth box), and my nes roms do launch fceultra, but in a very tiny window, or tiny, centered on a black background if I add a '-fs 1' to fceultra's location (I'm not sure how to make it fill the screen yet; other switches in the man page did pretty much nothing). More to come, if/when I have time, and/or when someone else can provide some insight...

For more information, you might want to check out

All prerequisite packages should have been taken care of when you installed the mythtv-suite, so it should simply be a matter of setting up your audio storage directories within the MythTV Setup section (MythTV → Utilities/Setup → Media Settings → Music Settings). Further information with respect to use and configuration can be found on the MythTV web site, at this address:

There isn't much to say about MythNews. Simply 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.

Not much to do, other than select your location and tweak the aggressiveness for the speed of your connection (MythTV → Utilities/Setup → Info Center Settings → Weather Settings). The MythTV website has plenty of documentation on this module, found here:

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

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.
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 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}\* | grep kmdl 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.18-1.2798.fc6
# yum -y install {alsa,ivtv,lirc,nvidia-graphics8776}-kmdl-2.6.18-1.2798.fc6

You can also uninstall an older kernel and its kernel modules with a single command:
# yum -y remove kernel-<oldversion>

Na vrh
 Naslov prispevka:
OdgovorObjavljeno: To Jan 16, 2007 8:11 
Site Admin
Uporabniški avatar

Pridružen: Pe Jan 16, 2004 9:54
Prispevkov: 5678
Upam, da bo to komu kaj pomagalo.

Na vrh
Prikaži prispevke prejšnjih:  Razvrsti po  
Napiši novo temo  Odgovori na temo  [ 3 prispevkov ] 

Vsi časi so UTC+02:00 Evropa/Ljubljana

Kdo je na strani

Po forumu brska: 0 registriranih uporabnikov in 1 gost

Ne morete pisati prispevkov v temi
Ne morete odgovarjati na teme v forumu
Ne morete urejati prispevkov v temi
Ne morete brisati vaših prispevkov forumu
Ne morete dodati priponk prispevkom

Pojdi na:  
Teče na phpBB® Forum Software © phpBB Limited