MythTV Install Log

Table of Contents

General Hardware

Netboot via PXE
Supporting network boot via PXE required a few changes to various configurations.

Server side changes


On my Gentoo system, I needed to

emerge tftp-hpa
rc-update add in.tftpd default

The configuration change for in.tftpd was in /etc/conf.d/in.tftpd:


# Config file for /etc/init.d/in.tftpd
# Remove the -l if you use [x]inetd


I already had a DHCPd running on my server, so the setup here was fairly trivial for me. I can remember, though, that the DHCPd setup was mostly easy in the first place. There were some global settings that needed to be provided, as well as settings specific to the MythTV host I was installing.


  • Global changes:

    allow booting;
    allow bootp;
    option subnet-mask    ;
    option broadcast-address;
    option routers        ;
    option domain-name-servers;
    option log-servers    ;
    option domain-name              "house";

  • Host specific:

            # The MythTV box.
            host myth {
                 hardware ethernet  00:0c:6e:25:cd:e0;
                 filename           "";

Now that all the pre-requisites are setup, the PXE boot step is next. PXE does most of the heavy lifting for network boot in my case. The first step is to install the pxelinux.0 file in the proper place. This is the file that the remote client asks for as a "kernel" image when netbooting.

pxelinux.0 seems to load enough brains into the machine to figure out to go ask for a host specific configuration file which will tell it what Linux kernel file to ask for. From that point, the kernel boots, mounts the root filesystem via NFS and the boot process is the same as a normal boot.

When the PXE ROM begins booting, it does the following:

  1. DHCP for an IP address. This address will include information about what kernel filename to download. In the case of my setup, it's
  2. TFTP the kernel file specified by DHCP.
  3. pxelinux.0 tries to TFTP the configuration file for PXELinux. This file is located, on my system, in /export/tftpboot/ Naming the file default is sufficient.
  4. PXELinux follows the instructions contained in the configuration file.


label linux
kernel root/boot/bzImage-2.4.26
   append nfsroot=,wsize=8192, \
               rsize=8192,nfsvers=3 video=vc:64-64
   ipappend 1

This file is pretty similar to what you'd see in a lilo.conf or grub.conf. A kernel image is specified, and then any necessary boot paramters are listed. It's also possible to specify an initrd image to be used, but I've found that I really don't need that at this time.

Client side changes

This was simple: Simply specify in the BIOS to use the Broadcom network bood ROM to boot the system. Et voila!

NFS Settings
  • Stale NFS File Handles

    For some time, I was receiving a large number of "Stale NFS file handle" errors when accessing the NFS mounted file systems. This was especially true for the root partition, which was mounted with the nfsroot= option in my PXE boot setup. I have not seen the problem since I changed my mount options for all NFS mounts to include the following:


    I believe it's the tcp and nfsvers=3 options that are eliminating the problem. It reappears occasionally, but it's not nearly the troublemaker it once was.

Automatically Starting Backend

I wanted to have the backend startup just like any other service under Gentoo. I wrote the following mythbackend script that lives in /etc/init.d/mythbackend:



#OPTIONS="--daemon --logfile $LOGFILE --pidfile $PIDFILE --verbose all"
OPTIONS="--daemon --logfile $LOGFILE --pidfile $PIDFILE"

# Start up the MythTV backend server and lircd.

depend() {
        need net netmount lircd

start() {
        local retval=0

        ebegin "Starting MythTV backend process"
        export HOME=$MYTHTVDIR

        # Clean the NFS lock file
        [ -f $NFSLOCKFILE ] && rm -f $NFSLOCKFILE

        # Start the backend service
        echo "==============================" >> $LOGFILE
        echo "Starting mythbackend at `date`" >> $LOGFILE
        echo "==============================" >> $LOGFILE
        start-stop-daemon --start --quiet --chuid mythtv --exec $MYTHBE -- $OPTIONS

        eend $? "Failed to start mythbackend"

stop() {
        ebegin "Stopping mythbackend"

        start-stop-daemon --stop --quiet --pidfile $PIDFILE
        echo "==============================" >> $LOGFILE
        echo "Stopped  mythbackend at `date`" >> $LOGFILE
        echo "==============================" >> $LOGFILE
        eend $? "Failed to stop mythbackend"

        # Clean the pidfile
        [ -f $PIDFILE ] && rm -f $PIDFILE

That process was pretty simple to setup. The echo commands just insert markers into the backend log file so that I know when things start and stop.

Setting things up to run automatically at boot is easy:

rc-update add mythbackend default

Automatically Starting Frontend
Starting the frontend is more tricky. It turns out that starting X automatically isn't the most straight-forward task on a Unix system. Because I wanted to have control over it like any other service, I wrote another script for /etc/init.d:



# program to exec
#OPTIONS="--logfile $LOGFILE"
OPTIONS="--verbose playback --logfile $LOGFILE"

# Ensure that MythTV backend has started.  This wouldn't work so
# well on a system that's a remote frontend.  In that case, some sort
# of last nonsense would be best.
depend() {
        need mythbackend

start() {
        ebegin "Starting MythTV frontend process"

        /usr/sbin/alsactl restore 0

        # Need to run xinit /usr/local/bin/mythfrontend as mythtv
        echo "===============================" >> $LOGFILE
        echo "Starting mythfrontend at `date`" >> $LOGFILE
        echo "===============================" >> $LOGFILE
        start-stop-daemon --start --background --quiet --exec $FRONTEND

        eend 0

stop() {
        ebegin "Stopping MythTV frontend process"

        # This doesn't stop the frontend process by pid,
        # rather it goes postal on the xinit process
        # which everything is hanging on.
        start-stop-daemon --stop --quiet --name xinit

        eend $? "Failed to stop MythTV frontend process"

        echo "==============================" >> $LOGFILE
        echo "Stopped mythfrontend at `date`" >> $LOGFILE
        echo "==============================" >> $LOGFILE

Again, the echo commands are just markers in the log files.

As you can see, this script calls


export PATH

# Take a nap for a while to wait for the
# backend process to get started.
sleep 10

sudo -H -u mythtv xinit $XINITRC

This simply runs xinit as user mythtv. The .xinitrc contains the following:


xsetroot -solid black &

while [ 1 ]; do
    /usr/local/bin/mythfrontend  >> $LOGFILE 2>&1

The while loop ensures that if mythfrontend exits, it starts right back up again.

Because of the way this is all setup, I can now simply restart mythfrontend remotely by issuing commands via SSH:

/etc/init.d/mythfrontend restart

Getting this to start automatically at boot is easy too:

rc-update add mythfrontend default

It works for me, and is simple for my poor brain.

This setup also allows me to not have to worry about window managers under X, and logging users in automatically via that. In my opinion, there's no reason to have a window manager, since mythfrontend is the only application running under X. (I've never been able to figure out why anyone actually bothers with a window manager for myth. If there's only one application running, why do you need something that manages multiple windows?)

This is the old method I used for starting myth up properly. It wasn't easy to start/stop this remotely, so I ditched it.
  1. Create an autologin program. This is done as root:


    int main (void) {
       execlp ("login", "login", "-f", "mythtv", 0);
    Build with gcc -o mythtv-autologin autologin.c

  2. Call the resulting program from inittab:

    Excerpt from /etc/inittab (on a Gentoo system):

    c1:12345:respawn:/sbin/agetty 38400 tty1 linux
    c2:12345:respawn:/sbin/agetty 38400 tty2 linux
    c3:12345:respawn:/sbin/agetty 38400 tty3 linux
    c4:12345:respawn:/sbin/agetty 38400 tty4 linux
    c5:12345:respawn:/sbin/agetty -n -l /usr/local/sbin/mythtv-autologin 38400 tty5 linux
    This logs mythtv in automatically on virtual console 5.

  3. Create a .xinitrc to start mythfrontend:


    /usr/local/bin/mythfrontend >> myth.log 2>&1

  4. Make bash call startx if appropriate:


    # /etc/skel/.bash_profile:
    # $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/skel/.bash_profile,v 1.10 200
    2/11/18 19:39:22 azarah Exp $
    #This file is sourced by bash when you log in interactively.
    [ -f ~/.bashrc ] && . ~/.bashrc
    if [ -z "$DISPLAY" ] && [ $(tty) == /dev/vc/5 ]; then

LCDd settings
The Ahanix VFD is actually a HD44780 compatible device. The one I purchased is a parallel port based model, so it works well for LCDd. I've heard that there's USB models that are part of the D.Vine 5 case. I, unfortunately, don't know how those would be setup, but I've seen some notes around the net indicating that creation of an alternate connecting cable may need to happen.

Hooked up via SPDIF output to my reciever. The end result is that when watching TV, sound comes out via the L & R outputs from the PVR-350. This feeds into the analog input of the receiver.

When listening to music, the sound is output by the motherboard's sound card, so this goes out through the SPDIF output to the digital input on the reciever. The receiver is usually able to figure out that the input has changed. It's not that hard to hit a button on the remote, though.

One thing I haven't figured out is how to redirect the line-in input on the mobo's sound card to output on the SPDIF. There's some ALSA voodoo that I can't quite figure out to make that happen. If I could do that, then I would pipe the sound output from the PVR-350 through line-in, and back out through the SPDIF output to the digital input on the receiver.

Mac mini

First Impressions
The mini is amazingly small. It's a wonder that a decent computer can fit in that small space at all.

After a few hours of playing around with the apps on the mini, I'm happy to say that I'm not going to be a "switcher". The system works well, and does everything it needs to, but it just feels like it's missing things. I'm not sure what, though, but it doesn't feel right.

The system is very quiet, but it is still audible when close by. It seems like the hard drive and internal fan are the culprits. The Combo drive makes quite a racket, too. None of these sounds are audible when something is playing back on the mini, so it's not a problem. I am using this system in the bedroom, so I'll be putting it to sleep whenever it's not in use. This will also prevent it from heating up too much if the cabinet it's in is closed.

It's possible to script the sleep action, and the system will wake up for a wake on lan packet, too. The SleepNow tool ( will put it to sleep remotely, if needed.)

Watching DVDs using Apple's DVD Player seems to work well, and it looks like it will integrate nicely with MythFrontend.

MythFrontend Installation
This was the easiest part: I just downloaded the pre-built 0.17 release from I dragged the folder to my mini's Applications folder and that was it.

The first time I ran MythFrontend, I had to tell it where the backend server was, but that was it. I had MythFrontend up and running with access to all my existing shows in about 2 minutes. Not bad for a MythTV installation.

Screen Resolution
Apparently, it turns out that the LT-P 2045U does work at 800 x 600, so all this work to setup the display settings wasn't needed. Harumph!

The details below might be helpful to someone else, though, so I'll leave them around.

The first real issue with the Mac mini wasn't so much an issue with the mini itself, but rather the LCD TV I'm using for output. I have a Samsung LT-P 2045 that's used for output. This TV is limited to a screen resolution of 640x480 @ 60Hz when using the VGA input.

This is a problem for OSX becuase it seems to not want to use resolution less than 800x600. (This is apparently a good idea as some of the OS dialog boxes don't fit on the screen at 640x480 resolutions.) Everytime the system boots or a user logs in or out, the OS redetects the screen resolution and sets itself back to 800x600. This doesn't work well when the output device doesn't support that resolution.

After much wailing and gnashing of teeth, I decided to write a simple AppleScript that would do the following:

  1. Set the display settings to 640x480 @ 60Hz
  2. Start MythFrontend
The following is the script that I use, and have installed as the only LoginItem for my mythtv user. I saved the script as an application to enable it to run automatically without having to push the "Run" button in the script editor. Note: GUI scripting of system events needs to be activated for this to work (


activate application "System Preferences"
tell application "System Events"
  tell process "System Preferences"
    click button "Displays" of scroll area 1 of window "System Preferences"
  end tell
end tell

activate application "System Preferences"
tell application "System Events"
  tell process "System Preferences"
    -- GUI Scripting statements:
    tell window "SAMSUNG"
      tell tab group 1
        tell group 1
          tell scroll area 1
            tell table 1
              select row 1
            end tell
          end tell
        end tell
      end tell
    end tell
  end tell
end tell

activate application "System Preferences"
tell application "System Events"
  tell process "System Preferences"
    -- GUI Scripting statements:
    tell window "SAMSUNG"
      tell sheet 1
        click button "OK"
      end tell
    end tell
  end tell
end tell

tell application "System Preferences"
end tell

activate application "MythFrontend"

Keyspan Express Remote configuration
I chose the Keyspan Express Remote to be the remote control for my mini MythFrontend. This remote seems to have proven itself with OSX already, so it seemed like a safe bet. had the cheapest price on it, too.

The remote works well. For some reason, the driver software doesn't seem to be able to "see" that mythfrontend is running, so defining a key map for that application doesn't help. I think this is because mythfrontend doesn't run as a standard Mac OSX app with menubar, etc. This problem is easily fixed, though, by just defining the proper key combinations in the "Default" map.

The only definite problem is that mythfrontend has keymaps that change from section to section in the UI. This means, that in different parts of the myth interface, you'll want the remote buttons to perhaps send a different key to the system. The way that the Keyspan remote works is that it requires a noticable difference in the application to change keymaps. It isn't a huge problem, though, as simply watching TV and recorded programs essentially use the same set of keys.

Out of the box, the remote comes with some default key maps for most of the applications that come installed on the mini. This includes the built in DVD Player application.

Keyspan Default Key Map
Button Action Parameters
STOP Keystroke esc
PLAY Keystroke return
PREV_TRK Keystroke PageUp
REWIND Keystroke <
FAST_FWD Keystroke >
NEXT_TRK Keystroke PageDn
PAUSE Keystroke p
VOL_UP Media Key Volume Up
VOL_DN Media Key Volume Down
ARROW_UP Keystroke UpArrow
MUTE Media Key Volume Mute
ARROW_LEFT Keystroke LeftArrow
SELECT Keystroke space
ARROW_RIGHT Keystroke RightArrow
ARROW_DN Keystroke DownArrow
CYCLE Keystroke i
MENU Keystroke m

DVD Player Setup
I decided that it was probably easiest to use Apple's DVD Player application to play DVDs on the mini. I wrote a simple little shell script that MythDVD calls when it want's to play a DVD. The script is used to check (poorly) if a DVD is mounted and run DVD Player if it is. Otherwise it does nothing. This was needed because DVD Player would start if no disk was inserted, and that looked goofy.


DISK1=`mount | grep -i disk1`
DISK2=`mount | grep -i disk2`

if [ "" != "$DISK1" ]; then
   /Applications/DVD\\ Player
   echo "No /dev/disk1."

if [ "" != "$DISK2" ]; then
   /Applications/DVD\\ Player
   echo "No /dev/disk2."

On my mini, it seems that the DVD device is /dev/disk1 or sometimes /dev/disk2, so that's why I do the grep for "disk1" and "disk2".

I've got the DVD Player software setup to start in full screen mode, have the controls disappear in 1 second, use the "Mean" de-interlacing setting, and start playing where the disk left off last. This makes it start up nicely with only a couple seconds worth of non-Myth OSX GUI elements showing on screen.

I believe that I need to write a simple AppleScript to make DVD Player exit properly and spit out the DVD. There's not a lot of buttons on the KeySpan remote, so I don't want to dedicate one to "Eject". Basically, I need to map a key in DVD Player such that it will "Eject" then "Quit". Not hard, but I've been lazy.

Time For Bed -- Putting the mini to Sleep
I found a slick little command line program called SleepNow that will put the mini to sleep. It can be downloaded from Snoize here.

With SleepNow, I added a menu item to put the mini to sleep from the main menu. The Keyspan remote is able to wake the mini up when it sees activity on the IR sensor. Overall, a pretty good sleep/wakeup solution.

I created a directory under /Applications for SleepNow and put it in there with the following commands. It seems happy with these, but I'd bet the chowns are unnecessary. I just did those to make the ownership match those on the files already in /Applications.

mkdir -p "/Applications/"
cp SleepNow /Applications/
chmod a+x /Applications/
sudo chown root:admin /Applications/
sudo chown root:admin /Applications/
sudo chown root:admin /Applications/
sudo chown root:admin /Applications/

I added the following menu item to the bottom of /Applications/

     <action>EXEC /Applications/</action>

This is probably the wrong way to go about things, too. I've noticed that when it comes back to life, it sometimes takes a few moments for the mini to realize that the network connections to the server are gone. In those cases, the easy thing to do is just exit and restart mythfrontend, but that's not a good solution long term.