Some little additions here and there, cleanups and clarifications on the ivtv stuff, addition of a trouble-shooting section.
Fedora Core 3 has been released, but it'll be a little while before I have the time to update this document for it. I'm hoping to have the time to bump one of my boxes up to FC3 next weekend... Should be a slightly smoother transition from FC2 to FC3 than FC1 to FC2, but definitely a few things to sort through...
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, so if you find any inaccuracies, refer to this document for possible information to help you around them. (The new default sources.list comes to mind...)
MythTV is an open-source project, with its primary functionality being similar to that of TiVo, but with several way-cool add-ons and much greater flexibility. 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 Linux distributions put out by Red Hat, without having to compile anything. Quite a few people following this particular body of documentation have successfully created their own MythTV systems, and many of them frequent the mailing list. They can generally help you if you have a problem. I also frequent the mailing lists, and will help out in any way I can. 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. ;-)
It was suggested to me by a number of folks that I provide PayPal account information for those wishing to contribute. At present, contributions are being saved up for the next cool hardware purchase, whatever that may be. Plus, they 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 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. And I often reply on-list faster than off (because replies on the list are likely to help more people :-). 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. I try to keep this document as up to date and accurate as my time permits.UPDATED for FC2: quite a bit is changing with the migration to Fedora Core 2 and kernel 2.6. Its probably going to be a bit ugly if you try to follow this text for a Fedora Core 1 or earlier Red Hat Linux (i.e. 7.3 - 9) Myth box. A fair amount of the information here should apply to MythTV installed on just about any variant of Linux, but we're starting to get kernel 2.6-specific. Those running on 2.4 kernels might want to look at the old (no longer maintained) Fedora Core 1 version of this document.
Thank you, and enjoy!
Jarod C. Wilson, RHCE
I suggest you start here for information on hardware:
An excellent place many folks get their Myth box hardware from is NewEgg.com.
And those looking at building the quietest Myth box possible should probably check out SilentPCReview.com for advice.
Just about any computer that runs Linux and has enough processing power can be used as a MythTV box. For example, I had zero problems playing back full-resolution PVR-250 recordings on an Athlon 800 with a GeForce 4 MX. Here are the specs on the current production systems of both Christopher and I:
Jarod's Master Backend System:
Jarod's Slave Backend and Primary Viewing System:
Jarod's Secondary Viewing System:
Jarod's currently non-operational diskless System:
Christopher's Production System:
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:
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:
This guide is geared toward using Red Hat's Fedora Core 2 Linux distribution. It should apply pretty much equally to Fedora Core 3 when it hits download mirrors ever so shortly. 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:
The 2.6 kernel series now includes SGI's XFS (a journaling file system, well-suited for large files -- like Myth recordings), but Red Hat doesn't let you use it at system install time, unless you type in "linux xfs" at the boot: prompt when firing up the installer CD. Same thing with ReiserFS and JFS, just substitute reiserfs or jfs for xfs in your boot: command. 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, and XFS is my personal favorite file system to use for such a purpose. However, note that some people have had problems with XFS leading to system instability, while ReiserFS was rock-solid. Personally, I've used XFS on quite a few systems now without incident (and greatly improved performance), but you've been warned. ;-).
A suitable custom partitioning setup is as follows (assuming a single IDE hard drive):
|/dev/hda2||swap||same as RAM (ex: 512MB)||swap|
Be sure to choose XFS as the partition format type for the /video partition, as the selection will default to ext3. Do not use either XFS or JFS for the /boot or / partitions though, because there's a bug in the instaler that will prevent your system from being able to boot. This has been fixed in Fedora Core 3, but there's really no point in using XFS or JFS on /boot and /. See Red Hat's Bugzilla for more details on the bug.
At the installation type screen, you want to choose a custom installation, rather than workstation, server, etc., and 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:
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 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.
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, go with one of the ones Red Hat pre-populates the drop down menu with, or just go with pool.ntp.org, which is a dns alias that will try to find an ntp server in your vicinity.
This will make life MUCH easier!
Install Axel Thimm's ATrpms-kickstart from http://atrpms.net/dist/fc2/atrpms-kickstart/. This provides you with apt and a pre-configured set of apt repositories, which include everything we'll need.
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 update the apt package list and kick off an upgrade of all your installed rpms (this will take a while, lots of packages to download, roughly 165MB the last time I did it):
WARNING: Do NOT do 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:
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...
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. Run one more apt-get update at this point to make sure you've got updated repo metatdata:
You might want to install Synaptic, a graphical frontend to apt, which you can use in place of the command line if you prefer.
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:
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. I'm currently running KDE 3.3 from kde-redhat's testing tree on both my Myth boxes.
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:
Note that Axel maintains several different channels of rpms, with varying stability labels on them. Most of the packages used in this document are classified as "stable" now, 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 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 FreshRPMs core and updates repositories. 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:
As with any other mailing list, please search the archives first (you can find a link to them at the same location as above).
Many of the features one used to only find in Axel's custom kernels were back-ports from the 2.6 kernel. That means that pretty much everything we need is already in the latest Fedora Core 2 kernels, so I'm just using kernel 2.6.8-1.521, which you should install as well, since modules for earlier kernels aren't maintained:
Now edit /boot/grub/grub.conf and set default=0 (which should correspond to the first listed entry, for the just-installed kernel), save your changes and reboot to start using the new kernel.
We're going to set up a custom environment variable that will make life easier when installing kernel modules via apt. With the latest change in kernel module naming conventions (a coordinated effort between ATrpms, DAG, FreshRPMs and a few other rpm repositories), all systems can simply use this environment variable, like so:
To make this variable survive reboots, someone suggested having this variable set automatically. We can simply add this to rc.local:
This variable will NOT survive a reboot if you don't add the above. It is merely a short-hand convenience for the install procedure, not something that is present by default.
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.
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 in section 11.
On June 30, 2004, nVidia finally released a long-overdue driver update, 1.0-6106, since superceded by their 1.0-6629 release, which restores almost all the functionality broken in driver releases after 1.0-4363. This driver restores overscan functionality last seen in 4363, but retains the superior OpenGL performance of later drivers. However, the /dev/nvidia0 functionality from 4363 used for Myth's experimental vsync code is still non-existent (though the latest Myth code base has an OpenGL-based method that is almost as good). Oh yeah, this version will also work with the stock Fedora Core 2 kernels (versions prior to 6106 weren't clean for use with the 4kstacks feature in recent 2.6 kernels, including Red Hat's).
Anyhow, to make life easier, Axel has prebuilt kernel modules. Install for your active kernel like so:
Simply replace the 6629 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:
Axel's nvidia rpms insert a necessary line into modprobe.conf and generate an xorg.conf file for use with the nvidia driver, based on your initial xorg.conf file. This new file is saved as /etc/X11/xorg.conf.nvidia, and after peeking through it to make sure it looks appropriate, drop it into place. I suggest backing up the original file, and keeping a copy of the initial nvidia version, just for good measure.
Add 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-6629 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):
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:
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 should be reactivated at login if you do the following:
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: 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 (http://www.nvidia.com/view.asp?IO=linux).
Also, if you are having issues with stability, you might try removing the RenderAccel line from my config snippet above. Its worth having enabled if your system is stable with it. I haven't had any problems with it on any of my VIA chipset motherboards, though both my current Myth boxes are on boards with nVidia's own nForce2 chipset, which definitely ought to work. Release 6629 of the nvidia driver is supposed to have some fixes to help reliability and stability of RenderAccel on previously problematic systems.
For reference, and because many people have asked, I'm posting full copies of the xorg.conf files from both my primary and secondary systems. My primary 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.
The Asus Pundit's onboard video controller is made by Silicon Integrated Systems. 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
Note: http://www.winischhofer.net/linuxsisvga.shtml 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.
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:
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.
UPDATE: Just got a copy of Chris's xorg.conf file for the Pundit, which you're welcome to:
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.
Please note: 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 Axel does provide. If you're using a digital audio output, you'll also want to set up a .asoundrc file. I do recommend at least installing alsa-utils and gnome-alsamixer though:
I like to install gnome-alsamixer, as it is a bit easier to work with than the cli alsamixer, and tends to better cover all your card's features than KDE's kmix (it works just fine in KDE also, despite the Gnome name). Note that gnome-alsamixer comes from freshrpms, so if you don't have the freshrpms repo enabled, you won't be able to get it via apt, but it can still be installed like so:
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 'alias snd-card-0 snd-emu10k1' line 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".
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.
Next, create a .asoundrc file for your mythtv user (full path of /home/mythtv/.asoundrc). Just make a new text file called .asoundrc like so (adjust for your specific card):
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:
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:
The last time I looked, that one-liner installed 58 different packages, totalling about 50MB. 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...
Disclaimer! The ivtv driver for these capture cards is still considered beta, though it does work quite well. Driver development isn't entirely stable just yet, and thus parts of this section may become obsolete over time. But on with the show!
The last stable release of ivtv, (0.1.9, almost a year ago), does not work on FC 2.6 kernels, and constant development within the ivtv project results in almost daily builds of late. There are 0.2.0 release candidates that are starting to stabilize, but the most stable and tested build right now is 0.1.10pre2-ck100z (from Chris Kennedy's tree), a slightly modified version of which resides in ATrpms' stable tree (patched for newer tuners and 126.96.36.1991+ kernel compatibility). Various 0.2.0rc versions currently reside in the testing tree, 0.3.0 development releases in bleeding. I use the ck100z version myself.
Install the ivtv driver components, like so:
This has been broken down into multiple lines, due to apt flat-out not cooperating when it comes to dependency resolution (multiple kernel modules will satisfy the deps of ivtv, but it seems to like to install something other than the one we want, unless we install the one we want first).
Now, edit /etc/modprobe.conf to add ivtv-specific configuration info. For the PVR-250 and PVR-250 MCE, as well as PVR-350 users that aren't using its TV-Out, now for NTSC, PAL and SECAM alike, this should do the trick:
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:
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:
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).
PVR-350 TV-Out users: at present, the ivtv-fb module cannot be unloaded (it'll probably crash your system if you try), so if you're debugging, it might be best to comment out the ivtv-fb line in modprobe.conf. You'll also need to create some additional video devices for the PVR-350 to use once you do load up the ivtv-fb module. Due to differences in the way Red Hat handles device permissions, this command varies a fair amount from the version in the ivtv wiki's TvOutHowto. Anyhow, create the necessary devices with proper permissions using this command (all on one line):
Now try loading up the ivtv driver:
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:
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:
Again, the ck100zz 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. An easy way to get the required info out of your log file is to run this shell script:
You can subscribe to the ivtv-devel mailing list here:
PVR-350 TV-Out users: With the ivtv-fb line in your modprobe.conf, this will also 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:
Check that the card is being properly recognized:
The lspci output should return something like this for a PVR-250 within the output (rev2, iTVC16, thus "Unknown device 0016"):
Or like this for an M179:
And finally, like this for a PVR-350:
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:
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:
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:
PVR-350 TV-Out users: 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):
In this case, the PVR-350's TV-Out grabbed /dev/fb0, since there are no other frame-buffer devices loaded on the system. Most likely, you'll either get fb0 or fb1. You'll need to know that for your xorg.conf file later on.
PVR-350 TV-Out users: 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:
PVR-350 TV-Out users: If everything looks good at this point, unload the saa7127 module and reload it without the test pattern:
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 four lines 1) set NTSC as the video standard, 2) select the tuner for input, and 3) set the full NTSC resolution of 720x480 (you can set a lower rez if you really want, but I say use the best! But then I have an HDTV...). NOTE: The ivtv docs say that './ivtvctl -p 0' should set the tuner for input, but yours may vary (mine did, it is '-p 4'). Keep trying with different -p values (I think at least 0-8 are valid for some cards), doing a test capture after each change until you get the right one.
NOTE: If you have multiple cards, understand that the ivtvctl utility assumes you're operating on /dev/video0 if no device is specified. On any ivtvctl 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:
And finally, the SECAM version:
MythTV now controls some (all?) of these functions internally, so be sure to set similar values when we get to the MythTV setup portion. Now hook up your cable or antenna to the WinTV PVR-250'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.
Use that copy of mplayer you installed a bit ago (as part of the mythtv-suite install) to view the capture:
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:
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.
PVR-350 TV-Out users: to hear audio with this video capture when played back through mplayer, 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:
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):
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:
Then reload the driver yet again, and try the video capture one more time:
PVR-350 TV-Out users: 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:
PVR-350 TV-Out users: 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):
PVR-350 TV-Out users: if you got video, but there were like 20 to 50 evenly spaced horizontal lines overlaying it, try tweaking the ivtv-fb driver with this command:
Then run the dd test again, and with luck, the picture will look like it should. If not, rinse and repeat from the beginning...
Some people have run into issues with their cards generating a slight inverse ghosted image off to the right of the main picture, myself included. The recommended fix, which appears to be working for me, is to set the DNR mode to 0 (mine was initially set to 3), like this:
Also make sure that the values for DNR temporal and spatial filters are set to 0, for best results:
You can verify all the settings for your card, see possible inputs, video standards, etc., with this command:
NOTE: MythTV controls the capture resolution and bit rate internally, so scripts adjusting bit rate are no longer necessary (and will be overridden by MythTV's internal mechanisms).
For starters, recall the PCI bus ID of your PVR-350. Mine was 00:07.0 from the example output above, which is actually a hexadecimal value. What we'll actually need in xorg.conf is 0:0x07:0 to get the card properly recognized (it may not matter in this case, since 7 hex = 7 decimal, but it certainly does if your PCI bus ID is something like 00:0f.0).
Note that the ivtvdev X driver is included with the ck-series ivtv drivers, so no need to fetch it, just use it. Or so I believe. Gotta get my EPIA back up and running...
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:
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.
Log in as your mythtv user and launch mythfrontend if you don't have it already auto-loading. Go into Settings → TV Settings → Playback and go to the "Use PVR-350 Output" screen. Check the box, and make sure it reads /dev/video16. Click through to the "Finish" button of that section, and now you should be good to go for MythTV to take full advantage of the PVR-350's decoder and TV Output.
With the addition of the ivtvdev driver, I have no qualms about recommending the use of the PVR-350's output to anybody that either 1) doesn't ever want to play games on their system (no OpenGL acceleration) or 2) doesn't have an addiction to goom (one of the MythMusic visualizations). The video quality is second to none, for standard-def programming.
Oh yeah, and with the ivtvdev X driver, the measly 1GHz Via C3 in my EPIA (runs like a PIII-600) can decode and play back high-resolution xvid and ffmpeg4 encoded DVD rips without a problem.
A wide variety of TV capture cards utilize the Brooktree bt848, bt878 and other variants. The particular card I have is an AVerMedia AVerTV Studio, which has a chipset labeled Conexant Fusion 878A (Conexant bought out Brooktree some time ago). My lspci -v output looks like so:
The card was automatically recognized by kudzu (Fedora Core's hardware detection utility) at system boot time after I put the card in the machine, and a basic /etc/modprobe.conf entry was written for me, and the stock bttv module (v0.9.x) was loaded at startup. Everything worked fine in xawtv (once it was configured with the right parameters, i.e. ntsc, us-cable, tv input), and I was able to use it in MythTV.
While my card works with the single line, "alias char-major-81 bttv", and everything is correctly auto-detected, some more advanced features may not be enabled and some cards may not be properly detected. A script that appears to be of some use is ftvco, or Find TV Card Options, which you can find here: http://www.mind.lu/~yg/ftvco/. It'll ask you a few questions, then try a number of combinations, which you can preview in xawtv. Chances are, one of those combinations will work for your card, and then a file is written out with the necessary contents to be placed into /etc/modprobe.conf.
Unlike the PVR-x50s, which mux audio in with the video stream into mpeg2 files, I needed an audio jumper cable from the sound out on the TV card to the line in on my sound card. This is all well and good for xawtv, but you need to make a few quick tweaks for use with MythTV. Open up your sound mixer (Fedora/Red Hat menu → Sound & Video → Volume Control) and mark the check boxes for Mute and Record for the Line In on your sound card. Now when you try xawtv, you'll get no sound, but when you fire up MythTV, everything will be gravy. Trust me. Note that ALSA in the 2.6 kernels has a snd-bt8x8 modules (or something like that) which works with *some* bttv cards to get audio into your system without need for an audio jumper cable, but I haven't tried it.
Only some minor tweaks are required to get both the PVR-x50 and a bttv-based card running in the same system. You *might* have to spec a specific tuner type for either bttv or ivtv if they aren't auto-detected, but the latest versions of each should do that for you just fine (unless you have an M179 or MPG600, see above). Here is the pertinent section of my modprobe.conf file:
Note that I had only set up the PVR-250's remote in this dual tuner configuration. The PVR-250 was configured for /dev/video0, the AVerTV for /dev/video1, both tuner types were auto-detected.
I've got one PVR-250 and one M179 in my current production master backend system. The module configuration only differs from what you'd need for dual PVR-250s in that I have to tell the tuner module what type of tuner the M179 has. Here is the pertinent section of my modprobe.conf file:
The tuner= part of the options ivtv line simply says the tuner on /dev/video0 should be auto-detected (type=-1) and the tuner on /dev/video1 is type 2. If you have a pair of PVR-x50s, the options line is not needed. The alias char-major-81-X lines are alias definitions for /dev/videoX. These can be expanded for more cards as necessary, just add more lines (and more tuner types, if necessary).
UPDATE: finally made some spare time to get my pcHDTV card back into operational status, and its now fully integrated with my production Myth environment. Haven't had time to write anything about it yet, but I more or less followed David George's instructions.
Playback is perfectly smooth on all channels now, with HD content outputting within a 1080i mode, raw AC3 audio passed to my amp, and CPU usage hangs around 80% on an Athlon XP 3200+. No stutter or anything on OSD fades either. Kick ass. More to come...
As of this writing, the final version of lirc 0.7.0 still has yet to be released, and there are issues with it not compiling correctly against the ATrpms kernels, which are now patched with the latest i2c support. However, there is some very good news. We've now got pre-patched lirc rpms available from ATrpms, installable via apt and everything. However, it should be noted that at this time, as downloaded, they don't work with every single remote out there. LIRC is a bit of an ugly beast, in that it has to be recompiled for nearly every type of remote interface, and can't easily be compiled to support all at once, so creating rpms for all remote interfaces would be quite a task. 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. To finish the install, we need the appropriate kernel module as well. Simply install the kernel module like so:
Note that many people have been having issues with the very latest pre-release version, 0.7.0pre8, which doesn't seem to like to work right when started from its init script. 0.7.0pre7 has no such issues for me (haven't gotten around to try pre8), so you might give that a try if pre8 doesn't work (or load lirc from rc.local).
With the kernel module installed, we need to put the correct config file for lirc and the grey Hauppauge remote in place, which is provided by the ivtv folks. Say yes if prompted about overwriting an existing file.
Users with the older black Hauppauge remote, you'll need to go this route (there's some variation in the config files, because the two different remotes have different buttons):
Alternatively, you can also use certain universal remotes with you Hauppauge IR receiver. I'm now using a RadioShack 15-2116 remote to control MythTV. I've done a little write-up on what was required to make it work, complete with config files, which you can find here:
Now we add a bit to ivtv's setup in /etc/modprobe.conf to load the lirc modules. Add this line to the bottom of modprobe.conf, which should ensure ivtv is loaded before lirc_i2c, so we can access the i2c bus on the ivtv card:
Then add one line near the top of /etc/modprobe.conf, that reads:
To get started with lirc right now, we'll just modprobe...
If everything is still going like it should, let's set up lircd (the lirc receiver daemon) to start at boot time:
And go ahead and fire it up right now...
If you get one or two [OK]'s, then proceed to testing the remote (one is for lircd, one is for lircmd; you only really need lircd). If not, check /var/log/messages to see if you can figure out what went wrong. To begin testing, fire up the irw tool:
You should get some output corresponding to the buttons you pressed. Hit ctrl-C to stop irw.
The next step is to set up a file to map those remote button presses onto key combinations that MythTV understands, so your remote actually does something useful once we have MythTV working. I've got one already prepared and ready for download. You can view it here:
Getting it onto your MythTV box is a simple matter of:
Please be aware that this lircrc file is somewhat customized toward my own needs. For example, the VOL+/- buttons don't alter volume at all, because I use an external amp. However, the MUTE button does mute. Other notables are the YELLOW button, which seeks to the previous commercial cut point, the BLUE button, which seeks to the next commercial cut point, and the FULL button, which toggles the aspect ratio (very useful with my HDTV). Adjusting the buttons to suit your own needs is a simple matter of editing the lircrc file.
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 probably 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):
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:
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 type>. I simply did this:
At this point, I started up lircd:
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:
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:
Another popular USB combo is the ATI Remote Wonder, which isn't actually IR, but RF. RF doesn't have nearly as many directionality or range issues as IR, but I don't believe you can control anything but your Myth box with a Remote Wonder, and the receiver is only good for the Remote Wonder. These ship with some ATI TV tuner cards, and you can also find them as a stand-alone at NewEgg.com:
Those using an ATI Remote Wonder probably want to check out Tim Litwiller's doc on how he set up his:
You can easily build your own serial IR receiver, per the diagrams on the LIRC web site, or you can just pick one up online for a few bucks. The one I've got on the way is from a fellow MythTV user:
Another popular source for serial receivers is Zapway.de, which while in Germany, does ship globally.
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.
Set the mysql root password, replacing ROOT_PWD with your chosen administrator password:
Now we create the mythtv database (called mythconverg) to get us started:
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:
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...
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:
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:
WARNING: 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:
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, fill your database with programming info, like so:
BE PATIENT! This takes 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:
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 isn't as good as the above, 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).
Anyhow, when mythfilldatabase is done, start up the MythTV backend, which we'll daemonize a bit later:
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)...
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. 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). 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.
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:
If the backend isn't already running, save yourself a reboot and issue this command:
Now set mythfrontend to automatically start on login (there are a couple of ways to do it; I chose this one):
While logged in to an X session, you'll also have to run gdmsetup, to set autologin for your mythtv user. You'll have to get a root terminal open (if you aren't logged into your X session as root already, which is a no-no), then:
In GDM Setup, on the first tab ('General'), you should see a section "Automatic login". Check the box for "Login a user automatically on first bootup" and select your mythtv user from the popup menu. Alternatively, if you are not very comfortable with Linux just yet, and you suspect there may be occasions where you've mucked something up to the point that an auto-login will lock up the computer, you might not want to use Automatic Login. Instead, you might opt to use the "Timed Login" option, to log the mythtv user in a few seconds after the login screen first appears. This way, you can circumvent the mythtv user logging in, and log in as root to hopefully correct whatever you've broken.
NOTE: if you installed the packages from kde-redhat, they probably supplanted gdm as your display manager and put kdm in its place. I like the look of Red Hat's gdm much better than kdm, so I changed it back by editing /etc/sysconfig/desktop and setting "DISPLAYMANAGER=GNOME". Not that you should be seeing the login screen often, my box is always sitting there logged in with the Myth UI up. Maybe I'll add some kdm info in a bit...
Anyhow, I recommend setting the Kicker (the panel at the bottom of the screen) to auto-hide, so it doesn't end up on-screen during video playback, disabling the screen saver, and disabling any monitor-related dynamic power management, or you may not be able to wake your system up if you don't have a mouse and keyboard connected. You can use the KDE Control Center to disable your screen saver, and edit your xorg.conf file to disable dpms (or at least the screen blanking parts), but here is a nice, quick and easy method of disabling of dpms and your screen saver:
If your screen saver continues to come on, it may be that your display doesn't support dpms, and is thus bailing out on the above command without executing the "s off" part (look in your X log files). If so, remove the -dpms part and be happy. Not sure anymore what takes precedence over what, I have that stuff in rc.local, as well as some edits to my xorg.conf file and adjustment of settings in the KDE Control Center, just to be certain...
And finally, to turn on auto-hiding of the Kicker, right-click on the Kicker, choose 'Configure Panel...', then select the 'Hiding' tab, and select the radio button for 'Hide automatically'.
When you installed MythTV using apt-get install mythtv-suite, you not only installed MythTV, but also all of the add-on modules currently available. Starting in MythTV 0.13, all database population is done automatically, but there's a bit of setup you still need to do to make some of them functional...
You can also use the DVD playback application of your choice (MythTV → Setup → DVD Settings → Playback Settings), and as of version 0.12, there are preconfigured launch command lines for ogle, xine and mplayer. While mplayer doesn't properly support DVD menus just yet, both ogle and xine (with the right libraries) do.
The most critical part to getting all this to work is probably making sure MythDVD is pointing to your DVD drive (MythTV → Setup → DVD Settings → General Settings). Under Fedora Core, the device /dev/dvd isn't automatically set up. You'll either have to change this to /dev/cdrom, or create a link to /dev/cdrom. Note that some playback applications (Ogle comes to mind) require that you have a /dev/dvd entry, one way or another, so I went this route:
Another common problem is KDE auto-mounting DVDs (and CDs), which can interfere with playback, ejection, etc. You can easily disable auto-mounting like so:
Also note that if you happen to have multiple CD/DVD devices in your system, it is possible your DVD drive is actually /dev/cdrom1. (This is the case with my test system, which has a DVD drive and a CD burner).
For MythDVD's ripper to work in any mode other than perfect (i.e., to be able to transcode to xvid), you'll need to launch the Myth Transcode Daemon, mtd. I'd suggest simply sticking a line in rc.local to daemonize it at system startup:
You'll then have to configure MythGame through the MythTV configuration section (MythTV → Setup → 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 can't get any of the snes roms to work (zsnes never launches for some reason, I'm still investigating), and the 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...
UPDATE: According to Tim Harvey, the zsnes never launching problem is because MythGame is tailored specifically for snes9x. There's no apt-get installable rpm for snes9x yet, but hopefully will be in the near future... You can grab a binary from http://www.lysator.liu.se/snes9x/ that I'm told works just fine.
For more information, you might want to check out http://mythtv.info/moin.cgi/MythGameHowTo.
Now just point a web browser to http://your.mythtv.box.ip.or.dns.name/mythweb/ and go to town. Please note: MythWeb provides listings, lets you schedule recordings, and see what is already recorded. You cannot use this interface to control playback on your MythTV box in any way. There are also some controls for MythMusic and MythVideo.
Personally, I don't plan on using the web server on this box for anything *but* MythWeb, so I opted to move everything in /var/www/html/mythweb/ to /var/www/html/ and remove the mythweb folder, so I get to MythWeb with just http://htpc/ (htpc is the hostname for MythTV box). Alternatively, Zachary Hamm suggests creating an index.php file in /var/www/html/, containing the following to achieve the same effect:
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.
Upgrading your MythTV installation to a new release is now extremely 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+ requires ivtv 0.1.9+). The basic upgrade process should be as simple as:
Those without capture cards using the ivtv driver can obviously skip the ivtv line.
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 'apt-get 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 'apt-get dist-upgrade'. However, note that cases where the kernel version on a kernel module remains the same, but the module version is incremented, an 'apt-get dist-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...
...to get a full list of all the kernel modules you have installed on your system. With that list in hand, you can now install your new kernel, along with all the corresponding updated kernel modules. For example:
You might also want to install the corresponding kernel-sourcecode rpm, especially if you're compiling any kernel modules by hand. You can also uninstall an older kernel and its kernel modules with a single command:
This section has been moved to its own page, titled Tips 'n' Tricks.
I plan to populate this section over the course of the week, ran out of time this weekend...
The changelog maintained here was getting too long, and really didn't serve much purpose anymore. It'll continue to exist in my source repo for historical purposes, but from here out, people should go to http://svn.wilsonet.com/projects/mythtvology/timeline to see what has changed.