Setting up MythTV on a barebones Shuttle SB83G5

From Nearline Storage
Jump to: navigation, search

I elected to install MythTV under Fedora Core 5 since that seemed to be a mature environment at the time I was doing my install. My installation was guided by Jarod Wilson's outstanding HOWTO on Fedora Myth(TV)ology. My notes here only cover the differences I found and specifics related to the hardware I am using.

One general note, when getting files from Jarod's SVN there's a problem with the SSL certificate he's using. You get an error and a suggestion to use the --no-check-certificate option and that does work. Here's an example:

# wget
           => `lirc.modules'
Connecting to||:443... connected.
ERROR: Certificate verification error for self signed certificate
ERROR: certificate common name `' doesn't match requested host name `'.
To connect to insecurely, use `--no-check-certificate'.
Unable to establish SSL connection.

# wget --no-check-certificate
           => `lirc.modules'
Connecting to||:443... connected.
WARNING: Certificate verification error for self signed certificate
WARNING: certificate common name `' doesn't match requested host name `'.
HTTP request sent, awaiting response... 200 OK
Length: 145 [text/plain]

100%[====================================>] 145           --.--K/s

09:32:14 (3.95 MB/s) - `lirc.modules' saved [145/145]


Getting the right hardware for this project turned into something of a nightmare. I wanted a really quiet system and Shuttle seemed to offer what I was looking for.

My initial purcase was a Shuttle XPC G5 1100h. This is a pre-built package system that looked to have everything I needed in it. Unfortunately, when I received it I saw that it did not have a PCI slot so I wasn't going to be able to install my Hauppage video capture card in it. All it had were two PCI Express slots. Not being an expert on PCI vs PCIe I had missed this distinction when I placed the order. Since that was my mistake, Shuttle charged me a 15% restocking fee plus shipping to return the system to them. They also deducted an additional $30 for the software they had installed on the system. It does say that software is non-refundable in their return policy but I hadn't purchased any software so I was a bit confused. It turns out that they had installed a copy of Microsoft Works on the system and that's what they wouldn't refund. Oh well. I made them send me a CD copy of Microsoft Works and maybe one day when I'm bored I'll see if there's a market for it out there on eBay.

I next went to to order the system that I wanted, in parts. When everything arrived and I tried to put the system together I realized that they’d sent me the wrong system unit. I'd ordered a Shuttle SB83G5 and they shipped an SB56. The CPU socket types are different in those systems and the CPU I'd bought wasn’t going to work. I called them up, got an RMA and sent the system unit back. They told me that they wouldn't ship the replacement until they received the return. I shipped my return via UPS and it got to them in five days. They did not process my return until a week later however, after I called them to ask about the status of the return. Then everything happened all at once. They paid for the return shipping and refunded my full purchase price when it turned out they didn't have a SB83G5 in stock. They told me to use their web site to sign up for an alert when they got more of these in. I did that, and I'm still waiting for an alert here almost two weeks later.

In the meantime, tired of waiting, I went on eBay and bought a “like new” SB83G5 someone had on offer. It has now arrived and all the parts I have are installed in it. Because it looks like nobody has ever installed a CPU chip in this system unit before I believe that it is, in fact, “like new.”

So, after six weeks of screwing around, my system hardware consists of:

  • Shuttle SB83G5 bare-bones system, which gets me:
    • A case and power supply
    • A Shuttle FB83 motherboard with the Intel 915G chipset and 775 CPU socket
  • Intel Pentium 4 Processor 531, which has the following specs:
    • 3GHz
    • 800 MHz FSB
    • 1 MB L2 cache
  • A Western Digital 400 GB SATA disk
  • Two 1 GB Kingston RAM DIMMs
  • A Hauppage PVR-350 video capture card

Is the system quiet? It's pretty quiet. It's sitting three feet from me during this install and except when the fan speeds up to cool the CPU while it's under heavy load or when the harddrive ticks while reading and writing data, I can't heasr anything from it.

Basic Fedora Core Installation

The installation of Fedora Core 5 worked fine. I updated the system with “yum -y update” after the initial install and again after adding the ATrpms and FreshRPMS repositories and everything went very smoothly through those updates.

Automatic Login

Jarod doesn't mention it but you can set KDE to automatically login your MythTV userid by modifying /etc/gdm/custom.conf as follows:

# Automatic login, if true the first local screen will automatically logged
# in as user as set with AutomaticLogin key.

XWindows Configuration

The "lspci" command identified the embedded graphics adapter chipset as an Intel Corporation 82915G/GV/910G Express Graphics Controller (rev 0e). As far as I can tell the i810 driver in the Fedora Core distribution is the latest available driver. The /etc/X11/xorg.conf file was setup properly by default. There is no TV out on this system, I followed the HOWTO directions to enable output via the TV out on the Hauppage PVR-350.

In the HOWTO Jarod says to use the following command to get the frame buffer that the PVR-350 is using:

# cat /var/log/messages |grep "iTVC15 TV out"

That search string doesn't work for me but searching on just "TV out" finds:

Oct  8 06:53:54 mythtv kernel: ivtv0-osd: fb1: cx23415 TV out frame buffer device

In the section of the HOWTO called “Running X on the PVR-350's TV-Out-” Jarod talks about creating a new initial boot image file that includes the ivtv drivers so that the boot process will display on the PVR-350's tv out. This doesn't appear to be necessary for me, the RHGB process displays on my TV without this change, and using the image file produced by the patched mkinitrd hangs my system almost immediately after the boot process starts.

Database Setup

Add this step to the setup that Jarod describes:

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

Audio Setup

The lspci command identifies my audio device as “Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03).” The initial install set up the drivers correctly and sound worked. At some point in the setup process that configuration got corrupted and I started getting errors like this:

mythtv@mythtv ~]$ aplay /usr/share/system-config-soundcard/sound-sample.wav
ALSA lib pcm_direct.c:1629:(snd_pcm_direct_parse_open_conf) Unknown field ipc_sem
aplay: main:547: audio open error: Invalid argument

Following a hint I found via a Google search I deleted the alsa-lib and libasound2 packages, erased the dmix and dsnoop config files out of /etc/alsa/pcm, and re-installed them. This corrected that problem.

Turning on S/PDIF output on this system requires only that I use alsamixer to unmute the IEC958 channel. (You can actually see the red light come on in the S/PDIF jack when you do this.) The IEC958 Playback slider should stay at zero and the IEC958 Playback Source should be set to PCM. A test with mplayer and one of my tuneup DVDs confirms that S/PDIF and surround sound is working just fine.

The PVR-350 encodes the TV signal it receives from its built-in tuner or from its various audio and video inputs into MPEG-2 format and streams that output to MythTV which writes that stream into files. When MythTV plays back those MPEG-2 files, or any other MPG format file for that matter, it simply streams them them back to the PVR-350 and the PVR-350 decodes the audio and video and sends them out of its cables.

To get the audio produced by the PVR-350 many people take its audio outputs and use a cable to pipe them back into their sound card's Line In jack. If you're using the Line Out jack on your sound card to send analog audio to your amplifier, then all you need to do is unmute the Line In control in your audio mixer and set the volume. However, redirecting this output to the S/PDIF output in digital format requires a few more steps.

[Note: The names of the sound cards controls used in the following command examples will vary depending on the audio device installed in your computer and the driver module it uses. The command “amixer” entered without any options will output all of the controls exposed for your audio device and “alsamixer” or your favorite graphical mixer program can also be used to manipulate most of these controls to make these settings.]

Set Line In as a capture source and mute it so that it doesn't go out the Line Out jack. (This can also be done with alsamixer.):

$ amixer set 'Line',0 0%,0% mute cap

Set Capture as a capture source. (On some systems alsamixer does not support this setting so this can only be done from the command line.):

$ amixer set 'Capture',0 0%,0% mute cap

Tell the sound card to turn on the S/PDIF output. (This can also be done with alsamixer.):

$ amixer set 'IEC958',0 unmute

Tell the sound card to route analog input to the S/PDIF port. (This can also be done with alsamixer.):

$ amixer set 'IEC958 Playback Source',0 'Analog In'

This last setting needs to be toggled back and forth when you switch from watching TV, TV recordings and other MPG sources via the PVR-350 card to watching DVDs, videos and listening to music. All of the non-PVR audio is PCM audio, not analog. Switching back to PCM audio can be done from within alsamixer or with:

amixer set 'IEC958 Playback Source',0 'PCM'

You can set a button on your remote to toggle this setting as required.

If your sound card does not allow you to set the "IEC958 Playback Source", or you want to avoid having to toggle this setting back and forth, then you need to find some other way to route the analog audio from the Line In jack to PCM audio. One technique would be to use the “arecord” and “aplay” commands to route the capture sources on the sound card back in as PCM audio:

$ arecord -D hw:0,0 -f dat | aplay -D mixed-digital

[Note: Fedora Core 5 users should leave off the “-D mixed-digital” portion of this command]

If you use this approach then you will probably want to execute this command at startup so that it is always running and available while the MythTV frontend is up. One way to do that would be to add it to a script in ~/.kde/Autostart. If you used Jarod Wilson's Howto as a guide to installing MythTV then you already have a script there called and you could just add this command to that script:

arecord -D hw:0,0 -f dat | aplay -D mixed-digital &

The “&” at the end of the line causes this command to run in background so that the script can continue executing the rest of the commands that it contains.

[Note: Again, Fedora Core 5 users should leave out the “-D mixed-digital” portion of this command]

Note that this approach may not produce the best possible sound quality. Ths sound is going out of the PVR-350, back into the soundcard, being sampled by “arecord” and “aplay” and then sent out the S/PDIF to be converted back to analog by your apmlifier. If you have an optical interconnect between your MythTV frontend and your amplifier it may help reduce ground-loop hum though. On the other hand, this technique may put your TV audio and video out of sync.

Changing Channels

I have a Motorola DCT-2244 cable box with a serial connection. The dct-channel program in the mythtv contrib folder works for me. I had to change the serial device hard coded in it because I'm using a USB/serial adapter to talk to the cable box. I also had to make the mythtv user a member of the uucp group so that it could access the serial port. It worked fine when I ran it from the command line but it refused to work from inside mythbacken. This turned out to be because I put it in /usr/local/bin and that directory was not in the path known to mythbackend when it gets started by the /etc/rc.d/init.d/mythbackend script. I added “export PATH=$PATH:/usr/local/bin” to /etc/sysconfig/mythbackend to fix this.

Remote VNC Terminals

I set up the VNC server to make a remote console available on display :2. In order to prevent the screensaver from locking up that terminal I had to make a slight modification to the /home/mythtv/.kde/Ausostart/mythtv-startup that Jarod suggested:


# Only do this stuff if we're on the main display
# (i.e., don't do this in a vnc session)
if [ `echo $DISPLAY | grep -c ":0"` -ge 1 ]
    # Launch myth frontend
    mythfrontend &
    # Launch Myth Transcoding Daemon
    mtd -d &
    # launch lirc's irexec
    irexec -d &
    # Disable dynamic power management (screen blanking)
    /usr/bin/xset -dpms

# Always do this stuff regardless of the display

# Disable screen saver
/usr/bin/xset s off



# The VNCSERVERS variable is a list of display:user pairs.
# Uncomment the lines below to start a VNC server on display :2
# as my 'myusername' (adjust this to your own).  You will also
# need to set a VNC password; run 'man vncpasswd' to see how
# to do that.
# DO NOT RUN THIS SERVICE if your local area network is
# untrusted!  For a secure way of using VNC, see
# <URL:>.

# Use "-nolisten tcp" to prevent X connections to your VNC server via TCP.

# Use "-nohttpd" to prevent web-based VNC clients connecting.

# Use "-localhost" to prevent remote VNC clients connecting except when
# doing so through a secure tunnel.  See the "-via" option in the
# `man vncviewer' manual page.

VNCSERVERARGS[2]="-geometry 720x480"
# VNCSERVERARGS[2]="-geometry 800x600 -nolisten tcp -nohttpd -localhost"