Tips 'n' Tricks

This page is dedicated to miscellaneous tips and tricks collected from my personal Myth experiences, things people have sent me, and assorted bits I've picked up on the Myth mailing lists. Feel free to ping me with anything you think is worthy of inclusion. I've already got a ton of stuff I still plan on getting onto this page...


I'm not a big fan of the default MythTV theme. However, Oscar Carlsson's G.A.N.T. theme and J. Donavan Stanley's Titivillus theme, both of which I rather like, are now included as official parts of MythTV. For these themes to flourish in their full glory, you'll want to switch your QT Style over to Keramik, otherwise you get Bluecurve's flat buttons and progress bars that just don't look right (to me, anyhow). In your frontend, go to Setup » Appearance and on the first screen, set QT Style to Keramik. My personal favorite themes for the OSD are Gerhard Aldorf's isthmus, which gets pulled in by mythtv-suite, and the Titivillus OSD.

Smoother video playback-

In cases where your system is pretty well taxed processor-wise (either you have a slow system, or you're playing back HD content), you may get an improvement in video output smoothness by letting mythfrontend run suid root. What this means is the frontend runs with root privileges, which allows for higher prioritization of the video output thread. There are security implications with this, but I go ahead and do this on all my Myth boxes, even those that aren't being taxed. It takes just one line to make this happen:

# chmod +s /usr/bin/mythfrontend

MythDVD and DVD Menus-

By default, MythDVD is configued to use mplayer for DVD playback. It plays back DVDs just fine, but has one major shortcoming. It doesn't support DVD menus. However, there are multiple alternatives to get DVD menus working: switch to xine, switch to ogle, or use MythTV's internal DVD playback support. Ogle is a DVD player only, xine is a much more general-purpose media player. Using MythTV's internal DVD player results in the most consistent user interface experiece, so I'd actually suggest that route (plus, you already have it installed). Simple adjust the DVD player command in the DVD settings section from the stock mplayer one to:


All done! I believe the capitalization there is important. Note that you can also use the Internal player with MythVideo to play back most of your video archive now as well.

MythVideo focus issue-

Yet another problem with MythVideo... When you exit, the remote ceases to function. This is because for some reason, KDE shifts focus to the Kicker, rather than the MythTV window, so your remote presses are trying to execute upon the Kicker, and do nothing. One possible fix is to change to a different window manager, but that's a fair amount of work, and outside the scope of this document. The easy fix is to change KDE's window focus behavior, so that you have focus following the mouse. This is a bit goofy for some people if they're trying to use the system as a normal computer, but works well if you dump the cursor in the middle of the screen, because when MythVideo (mplayer) exits, focus will return to MythTV, and your remote will function. You can change the window focus behavior by opening Control Center (off the Fedora/Red Hat/KDE menu), Navigating to Desktop → Window Behavior, and then change the Focus Policy to Focus Follows Mouse, and hit Apply.

Wide-screen tweaks-

I have a wide-screen HDTV. This does funny things to movies viewed with mplayer if you are connected via S-Video or composite video. Because you are feeding the TV a 4:3 video signal, which the TV stretches, movies that are already wide-screen get stretched, and only use about 1/2 of the screen vertically. To fix this, add a single switch in the mythvideo configuration section (MythTV → Setup → Video Settings → Player Settings), -monitoraspect 16:9, so mythvideo launches mplayer with this command:

/usr/bin/mplayer -fs -zoom -quiet -monitoraspect 16:9 -vo xv %s

This forces mplayer to compensate for the distortion, and movies look like they ought to. You can use this tweak for MythDVD also. Note that I'm actually connected to my TV via Component video now, using an Audio Authority 9A60 VGA to Component video adapter, feeding the TV an actual 16:9 signal, so I don't really need to specify that anymore, but including the monitoraspect statement doesn't hurt.

If you're using xine, I'm not entirely certain what would be necessary to force a 16:9 aspect. I've only recently switched to using xine, and I'm already feeding a 16:9 signal to my HDTV and a 4:3 signal to my analog TV, so xine's auto-detection of display aspect and how to output videos I'm watching works just fine... You're on your own if you're in the unfortunate situation of feeding a 4:3 signal to a 16:9 TV. :-)

Use native ALSA in MythVideo-

If you're using ALSA, you can use mplayer's native ALSA support, rather than OSS emulation, by adding the switch "-ao alsa" to the mythvideo launch command, so it reads (along with the wide-screen tweak):

/usr/bin/mplayer -fs -zoom -quiet -monitoraspect 16:9 -vo xv -ao alsa %s

Even better, if you have are outputting to an amp with Dolby Digital decoding capabilities like I am, you should pass raw ac3 audio to your amp (the comma is important, it tells mplayer to fall back to pcm if no ac3 audio is found in what you're playing):

/usr/bin/mplayer -fs -zoom -quiet -monitoraspect 16:9 -vo xv -ac hwac3, %s

Just like the wide-screen tweak, these options can also be applied to MythDVD.

Even better still, and much cleaner, is to drop most of these configuration options into ~/.mplayer/config so mplayer is always launched with those options (or at least put the options you always want to use in there). The following is an example mplayer config file:

# run full-screen
# zoom image to fill the screen
# disable mplayer's usual verbosity
# use XVideo for video output
# don't enable joystick
# if ac3 audio, send raw stream to my amp, else fall back
# my display is 16:9

If you're using xine, it ought to detect if ALSA is present on your system, and use that by default. You can also tell xine to pass raw ac3 to an external amp if you go into its settings UI (alt-s) and specify "passthrough" as the speaker setup on the audio tab.

MythVideo/MythDVD/mplayer/xine remote control consistency-

The switch from irxevent to MythTV native lirc broke my previous setup for controlling mplayer, but folks have been kind enough to contribute native lircrc file additions that restore (and extend) control of mplayer via remote. Many folks (including myself of late) actually prefer xine over mplayer, especially since it supports DVD menus, while mplayer does not. Such being the case, I've heisted xine key mappings from another Myth user for inclusion. They are already in the lircrc file linked in the lirc setup section, but we'll also need to create a ~/.lircrc symlink, so that mplayer and/or xine can find it without requiring an extra launch switch:

$ cd
$ ln -s .mythtv/lircrc .lircrc

The lircrc config file should provide at least similar behavior of the remote between mplayer/xine/mythvideo and mythtv.

Make Myth even more wife-friendly, aka make the power button do something more useful-

Once in a blue moon, my wife calls me at work saying she messed something up, and doesn't know what to do. While its rare anymore that I see a frontend lockup, its annoying to have to shell in from work to kill it off and restart it. So I finally got around to implementing something a number of others had suggested on the mailing lists, and the power button on my remote now executes a script via irexec that kills the frontend if it is running, and starts it up if it isn't. So two quick key taps, and my wife can recover the frontend, instead of calling me. :-)

First off, I edited my ~/.lircrc file to include the following stanza:

# Power Button
prog = irexec
button = OFF
#button = POWER # (for my RS15-2116 remote)
repeat = 4
config = /usr/local/bin/

Note that we need irexec running to make this all work. It should already be getting launched by my script, detailed in the main HOWTO. And finally, I created a trivial little shell script in /usr/local/bin/, called The basic contents of it are:

STATUS=`ps -e | grep $PROG | grep -v grep | wc -l | awk '{print $1}'`

if [ `echo $DISPLAY | grep -c ":0"` -ge 1 ]
    if [ $STATUS -eq 0 ]
        ( $PROG & )
        killall $PROG
exit 0

Remember to make that executable (# chmod +x /usr/local/bin/, and either log out and back in or start up irexec manually to see it function. I'd also remove any other .lircrc sections pertaining to the POWER button, or you may see multiple things happen at once. Not sure yet what will happen if I hit the button while, say, xine is in the foreground...

Customizing mythfrontend menus-

If you simply copy main_settings.xml and mainmenu.xml out of /usr/share/mythtv/ into ~/.mythtv/, you can edit them to your heart's content without screwing up your main install, and the changes will survive an upgrade. This is probably the easiest way to remove unwanted content from the menus, rename anything to your liking, etc., without breaking any of the packages.

Maximizing hard drive throughput-

Most of the time, the DMA capabilities of your hard drive are automatically recognized and enabled. However, there are some chipsets and/or drive combinations that don't always get properly recognized. The performance of your MythTV system will suffer greatly if DMA isn't enabled. You can quickly tell if DMA is active on your hard drive with this command:

# /sbin/hdparm /dev/hda |grep dma
(For Serial ATA, change hda to sda)

For reference, my system spits out this:

# /sbin/hdparm /dev/hda |grep dma
 using_dma = 1 (on)

You can force DMA on by adding a line to the end of your rc.local:

# echo "/sbin/hdparm -d1 /dev/hda" >> /etc/rc.d/rc.local

Note that Red Hat claims some chipset/drive combinations have DMA intentionally disabled, due to bugs in the chipset, the drive or the combination of the two. Use at your own risk.

Graphical boot-

If you installed the prescribed packages above, you've got graphical boot. Nothing more to do. Much easier than making it work under RHL9, eh? Note that it still has issues on systems with dedicated /usr partitions though. One of these days, I'll get around to posting a customized rhgb package, designed for use with Myth...

Remote front-ends-

Configuring a remote front-end is relatively easy. There are only a few steps you need to take on your back-end machine.

1. On the machine you're running mysql (typically the same machine as your MythTV master backend server), you need to allow mysql connections from other hosts on your network. This example assumes your local area network is, adjust accordingly for your network:

$ mysql -u root -p mythconverg
mysql> grant all on mythconverg.* to mythtv@"10.0.1.%" identified by "mythtv";
mysql> flush privileges;
mysql> quit

2. In the mythtvsetup application on your back-end, you'll need to make sure you set the variables for "IP address for <host>" and "Master Server IP address" to the IP address of the back-end's network card, rather than the loopback address (

3. On your remote systems, you'll need to edit one or more files. If your remote system is a remote frontend only, open up ~/.mythtv/mysql.txt, and change the DBHostName variable from localhost to the IP or host name of your back-end server (the one you just set in the previous step). If your remote system is a slave backend (i.e., it has a tuner card you want to use with MythTV), you'll need to make the same changes to /.mythtv/mysql.txt and /root/.mythtv/mysql.txt.

4. In the mythtvsetup application on your front-end, you'll need to make sure you set the variable for "Master Server IP address" to the IP address of the machine you just set in your mysql.txt file.

These are the primary changes that differentiate a setup with a remote front-end, but you'll also have to go through the bulk of the rest of the steps detailed here to get things working. A few of the packages installed throughout this guide aren't necessary for a front-end only system, but it won't hurt anything to install them anyway, so I'm not going to go into what they are.

Compiling stuff on your own-

Should you have need to compile any component on your own, you may need to drop the proper .config file into your kernel source tree. This is simply a matter of copying the appropriate file for your architecture out of /usr/src/linux/configs/ into /usr/src/linux. For example, on my single-processor Athlon MythTV box, I'd:

# cp /usr/src/linux/configs/kernel-2.6.9-i686.config /usr/src/linux/.config

Adjust accordingly for your architecture, but note that with 2.6 kernels, i686 encompasses Pentium II-IV and Athlon processors without any distinction.

It is also necessary to run a few commands in /usr/src/linux to make it possible to build some kernel modules:

# cd /usr/src/linux
# make oldconfig
# make prepare

For those wishing to install MythTV from source (or more likely, from CVS source), but wanting all the installation dependencies taken care of, you can still apt-get install mythtv-suite to get all the deps installed, then selectively remove (via rpm -e) all the myth packages. You'll also need lame-devel, so:

# apt-get update && apt-get install lame-devel

Now you can install from CVS source, with all the dependencies taken care of. There is now a document in the wiki detailing the process of upgrading from ATrpms release packages to CVS. You can find it here:

An alternate route you might take is to build your own CVS-based rpms. Axel also publishes MythTV CVS rpms from time to time, which you can use (at your own risk, of course), or at the very least, build your own using his spec files (just substitute something for the %atrelease macro). Check out Axel's CVS stuff here:

Controlling an external cable/sat box-

Never have had to do this myself, but some folks need to run two lirc instances, one to receive input from their remote, and one to send IR signals to a satellite or cable box to change channels. You end up running the one lirc instance from ATrpms for receiving, then compiling a custom patched version for sending. Update: actually, only one instance is required now, lirc 0.7.0 added multi-device support. Since I know next to nothing about the subject, check out the following links for some insight on how to do it. Note that the first one is geared particularly for Fedora Core 3 and one lirc, not sure what the latest is on the other links, I'm just linkin':

I was fortunate enough to have a cable box with an enabled serial port, so I simply used a serial cable and a little script to change channels. The necessary scripts and instructions can be found in the contrib directory of the mythtv source tarball. However, if you're in search of an IRBlaster and don't want to make one on your own, definitely check out, which is the site of a fellow MythTV user who makes a very nice IRBlaster. I've got one for evaluation purposes right now. Well-made unit, with a nice long cord to get from your Myth box to your cable box. I'll get it actually doing something one of these days...

Local package repo-

Tired of having to download a few hundred megabytes of packages every time you reformat your machine(s)? Give yam ("yum/apt mirroring") a shot:

I've got a machine set up with yam, mirroring the full install and update trees for several distributions, along with all of ATrpms, FreshRPMs and Dag's repo. That way, I've got only one machine that fetches all updates nightly, then serves as a yum/apt mirror for my entire home network. Saves quite a bit of download time... For reference, here's a viable example yam.conf file:

Alternatively, you might just want to save the contents of /var/cache/apt/archives/ off to another machine, then copy them back over after you've reformatted, and/or share that directory out to your other machines.

Exporting your recordings to play elsewhere-

Check out nuvexport, available on Chris Peterson's web site. This handy little perl script works with MythTV's built-in transcode daemon to help you export your recordings from .nuv format to a variety of different formats that are more readily playable on other systems that are without MythTV on them (such as a Mac or a Windows PC). You can also use the script to simply export the relevant sql information on a per-recording basis, if you want to move the recording from one system to another (or backup your recordings and corresponding info for a clean install).

Key bindings-

Many of the default key bindings, along with contextual functionality descriptions, can be found in the file /usr/share/doc/mythtv-/keys.txt, which for convenience, I'm stashing on this server, accessible through this link.

As of MythTV 0.13, these keys can be customized, through an interface in MythWeb. Once you have MythWeb up and running, simply point a web browser to http://your_mythbox_IP_or_hostname/mythweb/settings_keys.php and go to town.

Wirelessly networked Myth boxes-

Don't even think about trying it over 802.11b, unless you record at rather low (and crappy looking) bitrates. Many folks are successfully running Myth boxes connected wirelessly with 802.11g cards though. Seattle Wireless has a decent listing of g cards out there, along with driver support information (look for a card supported by either the MadWifi or prism54/ISL3890 driver):

Another route that requires no drivers at all (but likely a Windows machine for initial configuration) is to use an 802.11g "Game Adapter" or other wireless bridge device that you can simply connect to an Ethernet port.

Channel Icons in EPG-

Somewhere along the line, new setups stopped getting channel icons, at least in zap2it land. I presume it had something to do with the switch to DataDirect, I dunno. I've had the same database since well before the change, so I already had channel icons. However, on a new install, if you have none, there's a contributed script that'll get you some. Run these commands after you've already filled your database the first time:

$ cd
$ perl /usr/share/doc/mythtv-*/contrib/
$ mythfilldatabase --import-icon-map iconmap.xml --update-icon-map