Install Notes for MythTV and Mythbuntu

These notes describe how to set up a Mythbuntu-based MythTV system for recording of television programs, via both over the air and cable, viewing of movies from a video server, viewing of streams, etc. They also describe setup of various auxilliary processes such as email and UPS monitoring, and system maintenance functions. Installation of various pieces of hardware, such as encoders and IR recievers/blasters, is also covered.

BIOS Configuration

Before you even begin the Mythbuntu installation, there are a few things that you might want to configure on your system through the BIOS setup program. Boot the system into the BIOS setup screen by pressing the proper key on the keyboard (e.g. "Del") at bootup. Here are some option settings to consider:

Usually on the Main screen:

     Legacy Diskettes:             Disabled
     HDD SMART Monitoring:         Enabled

If you are using a motherboard with a built-in display adapter, you can usually find its configuration on the Advanced Configuration screen. Look around -- sometimes its on the Southbridge configuration page:

     Shared or Stolen Memory:      32M (or whatever the lowest number is above
                                   32M)
     Mythbuntu composes frames and loads them into the frame buffer as the
     become available.  As such, the CPU does all the work and there is no need
     to provide the GPU with a large frame buffer.  However, if you are using
     VDPAU, that's a whole 'nother story.

If you have an AMD processor and a motherboard that supports it, you can usually find the AMD-specific options on the Advanced Configuration screen:

     AMD Virtualization:           Disabled
     AMD Live!:                    Enabled
     AMD Cool 'n' Quite Function:  Auto (or Enabled)

Usually on the Power/APM Configuration screen:

     Restore on AC Power Loss:     Enabled

Usually on the Power/APM Configuration or Hardware Monitor screen:

     Q-Fan Controller:             Enabled

On the Boot/Boot Device Priority screen:

     1st Boot Device:              CDROM (this allows you to attach a CDROM as
                                   a diagnostic tool at any time)
     2nd Boot Device:              Hard Disk
     3rd Boot Device:              Disabled
     4th Boot Device:              Disabled

On the Boot/Boot Settings Configuration screen:

     Case Open Warning:            Disabled
     Quick Boot:                   Enabled
     Bootup Num-Lock:              Off
     Full Screen Logo:             Disabled
     Halt On:                      All, But Keyboard

You might want to take a quick look through all of the other BIOS settings to see if there are any that make sense for a TV watching application (e.g. quiet is good, unattended is good, always on is good). Don't forget to save the settings when you're all done.

Running The Mythbuntu Install CD

First of all, don't think because you've got an operating system install disk, in your hot little hands, that was built specifically for MythTV, that your install will be easy. Any way you slice it, installing Mythbuntu and getting MythTV to work is going to be a goat rope. If you don't want to spend days dicking around with hardware, drivers and screwy software, go buy a TiVoHD and pay those lovely people their monthly fee. Get used to the fact that they're logging what you watch plus every click of the remote, all the while forcing you to see advertising from their sponsors.

OK, still want to proceed? The goat roping begins with the install disk. We're going to start by building a combo backend/frontend machine (i.e. one that records TV and lets you view it [what a concept]).

Possibly, you were being clever and got a smallish hard drive for the OS and MythTV software and then one or more mondo huge drives for recording storage. For example, your system might look like this:

     sda - 80G SATA
     sdb - 620G SATA
     sdc - 620G SATA

During setup, you'll have to partition these drives. You could do it manually or you could allow Mythbuntu's automatic partitioning to do it. So far, We've never seen an automatic partitioner that does any kind of a decent job so we're all for manual partitioning. We like to set the partitions up this way:

     sda1    512M    ext3    /boot
     sda2      4G    swap
     sda3     max    ext3    /
     sdb1     max    xfs     /mnt/sdb1
     sdc1     max    xfs     /mnt/sdc1

Or something to that effect. The partitioner may round the sizes up down a bit to make them fit within cylinder boundaries. That's OK, since 512M is way more than you'll ever need for /boot and a 4G swap partition is plenty. All of the other partitions should be set to the maximum size remaining.

Make sure to choose the option to format all of the partitions. And, for any partition that will be storing video data, always choose the "xfs" file system, since it works best with big files.

The alternative is to go for the bleeding edge and purchase one ginormous hard drive to hold everything, a configuration which we've also had success with. For example, your system might look like this:

     sda - 2.0T SATA

Once again, during setup, you'll have to partition the drive, which you could do manually or allow Mythbuntu's automatic partitioning to do it. As we said above, we're no fans of automatic partitioning so we're still all for manual partitioning. Set the partitions up this way:

     sda1    512M    ext3    /boot
     sda2      2G    swap
     sda3     max    xfs     /

After you've partitioned the drives, the remainder of setup is straightforward. Just follow the steps. However, there is one other thing to watch out for when you're setting Mythbuntu up. If you have an Ira IR device (from Home Electronics) plugged into the serial port, do not set this device up during install. Make sure to pick "No Remote" when you do the install. If you do not, the install will hang and any subsequent reboots of the partially-installed Mythbuntu will die with the error message "No resume image".

We don't know if there are other remote controls that have this effect but the Ira is definitely one of them, especially under Mythbuntu 8.04LTS. If your system hangs during install or when it is subsequently rebooted, you should try going back to the beginning of the install and doing it over (we tried 5 times before getting it just right). Make sure to leave off any kind of remote control (you can set it up later) as the install program does not deal well with those that it doesn't understand (the Ira being one of them).

Mr. Wizard

For some reason, the Ubuntu guys decided that the owner of the system should not have root priviledges and that they should be forced to use sudo to do everything. To this end, they set the root password to some randomly generated value and don't tell us about it. Then, they set up the first user created as a sudo user and proceed with the system install. To be able to do anything, you must type sudo in front of every command and enter passwords constantly.

If you're like us and think this is b.s., you can do the following:

     sudo passwd root
       root's new password
       root's new password

Now, you're in business. From here on, you can just do su and enter root's password to get on with your life.

For the MySQL database, the initial installation should set the root password to nothing. If you'd like to change it to something, do this:

     mysql -u root
     set password for 'root'@'localhost' = password('newpwd');
     set password for 'root'@'host_name' = password('newpwd');
     set password for 'root'@'127.0.0.1' = password('newpwd');
     flush privileges;

For older Mythbuntu systems, that don't use upstart, if you forget the MySQL root password or if some clever install software sets it to something you don't know, you can reset it as follows:

     cd /etc/init.d
     sudo ./mythtv-backend stop
     sudo ./mysql stop
     sudo mv mysql mysql.orig
     sudo cp mysql.orig mysql
     sudo emacs mysql &

Change the line in the startup section that reads:

     /usr/bin/mysqld_safe > /dev/null 2>&1 &

To read:

     /usr/bin/mysqld_safe --skip-grant-tables > /dev/null 2>&1 &

Save the file, exit the editor, and restart the mysql server:

     sudo ./mysql start

Run the MySQL client from the command prompt:

     mysql

Issue the following statements in the mysql client. Replace the MyNewPass with the password that you want to use:

     update mysql.user set Password=password('MyNewPass') where User='root';
     flush privileges;
     quit

Stop the mysql server and restore the original startup script:

     sudo ./mysql stop
     sudo rm -f mysql
     sudo mv mysql.orig mysql

Restart the mysql server:

     sudo ./mysql start

You should now be able to login to mysql using the root password:

     mysql -uroot -pMyNewPass

If all is well, restart the MythTV backend:

     ./mythtv-backend start

On the newer systems that use upstart, you can carry out what are essentially the same steps to reset it, if you forget the MySQL root password or if some clever install software sets it to something you don't know:

     cd /etc/init
     sudo stop mythtv-backend
     sudo stop mysql
     sudo mv mysql.conf mysql.conf.orig
     sudo cp mysql.conf.orig mysql.conf
     sudo emacs mysql.conf &

Change the line in the upstart scritp that reads:

     exec /usr/sbin/mysqld

To read:

     exec /usr/bin/mysqld --skip-grant-tables

Save the file, exit the editor, and restart the mysql server:

     sudo start mysql

Run the MySQL client from the command prompt:

     mysql

Issue the following statements in the mysql client. Replace the MyNewPass with the password that you want to use:

     update mysql.user set Password=password('MyNewPass') where User='root';
     flush privileges;
     quit

Stop the mysql server and restore the original startup script:

     sudo stop mysql
     sudo rm -f mysql.conf
     sudo mv mysql.conf.orig mysql.conf

Restart the mysql server:

     sudo start mysql

You should now be able to login to mysql using the root password:

     mysql -uroot -pMyNewPass

If all is well, restart the MythTV backend:

     start mythtv-backend

NIC Drivers

If you happen to be lucky enough to get a motherboard that has an unsupported NIC chip, you will need to build the driver and install it. For example, the Realtek RTL8111C chip is supported by a special Realtek r8168 driver, although Mythbuntu thinks it is supported by the generic r8169 driver. If you do not install the r8168 driver, the NIC will appear to be up and running, when you do ifconfig, but it will not work. Only the special r8168 driver works. Furthermore, the people who build the kernel periodically seem to think they've got this problem licked with their fabulous, new code in the r8169 driver but it never proves to be the case. So, this chipset (which is quite popular, apparently) is bound to be a problem for years to come. Here's how to replace the driver for it specifically, and other NIC drivers in general.

The first problem, of course, is that the install probably won't fly without a working NIC in the system (the classic, "You can't get there from here"). The easiest way around this problem is to plug a working NIC into one of the PCI slots. A board with the r8169 chipset on it should work well. Any of the older 100 Mbps NICs should work too. Now, you can install Mythbuntu and apply all of the recent patches.

You may want to get rid of the Network Manager (its a real piece of scrap) and set the network up by hand (see Networking Your Way, below). In this case, you'll be setting up the temporary NIC first and then setting up the on-board NIC later on.

For Mythbuntu, building and installing a new driver can be problematic, since the build environment is not included in the distro. To build the driver, start by obtaining and installing a duplicate copy of Ubuntu (on another machine -- you can never have too many) to match your copy of Mythbuntu. Since Mythbuntu is built off of the standard Ubuntu distro, this shouldn't be a problem.

Make sure you have the driver build environment (this is not necessarily the full kernel build environment). To verify that you do have the driver build environment, try:

     ls -l /lib/modules/`uname -r`/build

If you have this directory installed, you're good to go (Ubuntu usually provides it in a typical installation). Otherwise, you'll need to first get the build environment, either using the Package Manager or by doing:

     sudo apt-get install build-essential

Then, you should make sure to install the latest headers for your kernel. When you enter the following command, be sure to use back-quotes:

     sudo apt-get install linux-headers-`uname -r`

Finally, if the link doesn't already exist, link the headers to the build folder in the proper place. This should get you compiling:

     sudo ln -s /usr/src/linux-headers-`uname -r` /lib/modules/`uname -r`/build

Download the latest version of the NIC driver from the manufacturer's Web site and place it in a convenient directory (you can build it under your home directory). The download for the latest r8168 driver, for example, is at:

     http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1&PNid=13&;
          PFid=5&Level=5&Conn=4&DownTypeID=3&GetDown=false#2

The r8168-8.012.00.tar.bz2 release seems to work on Mythbuntu 8.10 and 9.04. However, if you are using a version of Mythbuntu that is built on 8.04LTS, you may have to get r8168-8.005.00.tar.bz2 (because the later versions blow up during compile on 8.04LTS). You can get r8168-8.005.00.tar.bz2 and then apply the patch that is found at:

     http://ubuntuforums.org/attachment.php?s=f4cb4535bb95f2d96d4aa4d7530f78b1&;
          attachmentid=66030&d=1208224861

We are getting ahead of ourselves but, to apply the patch after you've unpacked the tar file (below), change to the src directory and do:

     patch ../../r8168-8.005.00.hardy.diff.txt

We unzipped the downloaded file and unpacked it in two steps:

     bunzip2 r8168-8.005.00.tar.bz2
     tar -xvf r8168-8.005.00.tar

However, you should be able to get away with:

     tar -xvjf r8168-8.005.00.tar.bz2

There are probably build instructions for the driver in a readme file. You might want to read them before proceeding with the build.

Apparently, it isn't necessary to place the driver in the system source tree any more, in order to build it (i.e. the way it used to be). Of course, you may opt to do this, if you wish, but we build it in our own directory. To do so, try the following:

     cd r8168-8.005.00
     sudo make clean modules

If this blows up with a message about not knowing how to make Makefile in /src, you should change the following line in the Makefile in the src directory:

     #       $(MAKE) -C $(KDIR) SUBDIRS=$(PWD)/src modules
             $(MAKE) -C $(KDIR) SUBDIRS=$(shell pwd) modules

Apparently, somebody has scrod the PWD command in the 8.04LTS version of Ubuntu.

If you choose the build-it-in-the-source-tree option, you should do the following instead:

     sudo mv r8168-8.004.00 /usr/src
     cd /usr/src/r8168-8.004.00
     sudo make clean modules

Once you've successfully done a clean build of the driver, you'll need to get it from the Ubuntu machine to Mythbuntu. Since it may be the NIC that doesn't work (if you aren't using a second NIC), you quite possibly won't be persuing the copy-the-files-over-the-network option. Rather, the requisite driver files may need to be written to a CD or floppy disc. Here is a list of the files (for a typical driver) that should included on the CD or disc (only the ".ko" module is really important):

     -rw-r--r-- 1 eric eric      0 2008-04-02 22:08 Module.symvers
     -rw-r--r-- 1 eric eric  37828 2008-04-02 22:08 r8168.ko
     -rw-r--r-- 1 eric eric  31024 2008-04-02 22:08 r8168.mod.o
     -rw-r--r-- 1 eric eric 242056 2008-04-02 22:08 r8168_n.o
     -rw-r--r-- 1 eric eric 242083 2008-04-02 22:08 r8168.o

Later versions of the driver may include these files:

     -rw-r--r-- 1 eric eric      0 2009-09-05 15:26 Module.markers
     -rw-r--r-- 1 eric eric     54 2009-09-05 15:26 modules.order
     -rw-r--r-- 1 eric eric      0 2009-09-05 15:26 Module.symvers
     -rw-r--r-- 1 eric eric   6144 2009-09-05 15:26 r8168_asf.o
     -rw-r--r-- 1 eric eric  88040 2009-09-05 15:26 r8168.ko
     -rw-r--r-- 1 eric eric  15452 2009-09-05 15:26 r8168.mod.o
     -rw-r--r-- 1 eric eric  66416 2009-09-05 15:26 r8168_n.o
     -rw-r--r-- 1 eric eric  73329 2009-09-05 15:26 r8168.o
     -rw-r--r-- 1 eric eric   2240 2009-09-05 15:26 rtl_eeprom.o

Now, proceed to the Mythbuntu machine, with your CD or floppy disc (or FTP them from the build machine, if the 2nd NIC is working). Load the appropriate driver modules into the local directory where you usually put all of your system modifications. Once that's done, install them onto the system:

     cd r8168-8.005.00/src
     sudo install -m 744 -c r8168.ko /lib/modules/`uname -r`/kernel/drivers/net

There could be an older version of the module that you are replacing or one that conflicts with the new module (typically the r8169 driver tries to take control of the NIC but does not work). You can check, for example, if the r8169 module is installed as follows:

     lsmod | grep r8169

If r8169 is installed then you should remove it:

     sudo rmmod r8169

Now, complete the install of the new module on the Mythbuntu machine:

     cd ..
     sudo depmod -a
     sudo insmod ./src/r8168.ko

By doing these steps, you are essentially duplicating what the module's makefile would have done. But, since the build tools and source code are not available on the system, you cannot run the makefile so you must do it by hand. You can check whether the install is successful by doing:

     lsmod | grep r8168

Now, we need to get rid of the conflicting module, if its there. If you are just adding a brand new module, you don't need to do this step. Otherwise, build a blacklist file for the old module. In older versions of Mythbuntu, this file should be named "blacklist-network" but in newer versions (e.g. Mythbuntu 9.04) all blacklist files must end in the suffix ".conf". Examine the existing files in /etc/modprobe.d and see how they are named to determine how to proceed. Then, either do:

     cd /etc/modprobe.d
     sudo touch blacklist-network
     sudoedit blacklist-network

or, for later versions do:

     cd /etc/modprobe.d
     sudo touch blacklist-network.conf
     sudoedit blacklist-network.conf

Regardless of whether the blacklist file is new or if it already exists, add the following lines to it:

     # Don't load the r8169 driver. It is replaced by the r8168 driver.
     blacklist r1869

Once you've completed all of the above, you must make the changes permanent. Mythbuntu boots from a RAM image of the kernel which will still have the old driver (if any) installed and the new driver missing. You need to update this image or the conflicting driver will still get loaded and take over the show. To do so, update the RAM image:

     sudo update-initramfs -u

Reboot the machine to see if the changes are permanent and that the NIC now works:

     sudo reboot

You can use ethtool to see if the new driver is assigned:

     ethtool -i eth0

If all is working, you should be able to remove the second NIC, if you went that route, and replace it with the now-working built-in NIC.

Another Ethernet chip that is showing up on a lot of motherboards, and which doesn't have support built in to the kernel (although it does appear to be included in Mythbuntu 12.04), is the Atheros 8151 (and its brethren). By way of a further example of how to build and install a NIC driver, we'll show you how to build this one too.

The first step is to see whether the Atheros drivers are already included among the kernel modules:

     find /lib -name \atl\

If you see a list that includes:

     atl1.ko
     atl1c.ko
     atl1e.ko

You've probably got the latest drivers for this chip. But, if you don't see these kernel drivers, you need to build them. As above, we'll go the second NIC route to allow us to download the needed files and get the Atheros drivers working so see the notes above about how to do that.

Probably the biggest problem you'll face with this chip is to find the correct source needed to build the driver. Originally, the source was offered on the Atheros Web site but they have since been bought out and the Web site has disappeared. Fortunately, the Linux Wireless Web site has accumulated a lot of useful drivers for wireless chips and this includes a number of wired network chips like the Atheros 8151.

All of the network drivers that the Linux Wireless Web site accumulates are rolled up into a single archive file which is updated on a regular basis. You can download the latest version of this archive from the Web page:

     http://linuxwireless.org/download/compat-wireless-2.6/

There are three archives to choose from. The "-pc" version seems to be the one to choose (because it includes all of the new Atheros drivers, specifically the alx driver) so download the one that looks like this:

     compat-wireless-2012-07-03-pc.tar.bz2

Change to the directory where you downloaded the archive file and unpack it like this:

     tar-xjvf compat-wireless-2012-07-03-pc.tar.bz2

As with the r8168 above, make sure you have the driver build environment available on your system. Once you have it installed, you can build and install the Atheros drivers like this:

     cd compat-wireless*
     scripts/driver-select atl1
     make
     sudo make install
     scripts/driver-select atl1c
     make
     sudo make install
     scripts/driver-select atl1e
     make
     sudo make install
     scripts/driver-select alx
     make
     sudo make install

The install steps in the build process update the kernel RAM image so all that you need to do is reboot the machine to see that the changes are permanent and that the NIC now works:

     sudo reboot

You can use ethtool to see if the new driver is assigned:

     ethtool -i eth0

If all is working, you should be able to remove the second NIC, if you went that route, and replace it with the now-working built-in NIC.

One wrinkle though, may be that the incorrect Atheros driver is automatically chosen for the 8151 chip at boot time. There have been reports that the atl1c.ko driver works poorly with some versions of the 8151 chip (e.g. R2.0) and that the new alx.ko driver (which is meant specifically for the 8161 chip) works better. If that's the case, you will probably have to blacklist the atl1c driver.

The notes for the r8168 above describe how to edit the blacklist file so see those notes about how to add the following lines to it:

     # Don't load the atl1c driver. It is replaced by the alx driver.
     blacklist atl1c

When you reboot, the alx driver should automatically come up in place of the atl1c driver.

Finally, be aware that you will need to rebuild any drivers that you build and install manually each time there is a kernel update. This may require you to get all of your ducks in a row before you do the kernel update, because the network is going to stop working again. Unless, of course the new kernel finally has the drivers installed in it, in which case, all your troubles are over.

Networking Your Way

You may not want to bother with all of the b.s. inherent in setting up static IP addresses via the Network Manager. While this gem may be good idea for someone's laptop (where the network address is acquired automagically by DHCP, and/or networking is done via multiple connections), its probably going to be a real pain in the butt if you want your machine to have a single, static IP address (i.e. so the frontend can talk to the master backend, etc.).

Fire up your favorite text editor and take a look at the "/var/log/messages" file (or, for later versions of Mythbuntu, "/var/log/syslog"). Do a forward search for "eth". You should see the place in the boot sequence where the network driver brings up your network interface. This will list the MAC address of the card and the ethernet device name (e.g. "eth0"). Remember these two pieces of information.

If you can't find the MAC address in "/var/log/messages" or "/var/log/syslog", there are several other options available to find it. You can try:

     /sbin/ifconfig -a

This more or less assumes that the interface was configured one way or another, perhaps by the Network Manager and DHCP, (although the "-a" option indicates that it need not be up). If that's not the case, you can try:

     /usr/bin/lshw -C network

This should give you the MAC address and maybe the ethernet device name for all of the configured NICs on your system.

Continue searching forward from the point in "/var/log/messages" or "/var/log/syslog" where you found the MAC address, or from the beginning, if you had to resort to other means to get the MAC address. You may see where udev is remapping your NIC to some other device name (e.g. "udev: renamed network interface eth0 to eth1"). If you don't want this to happen (quite often, the clever little install programs add every NIC they've ever seen, at some time in the past, to udev's rules so that you end up with "eth0", "eth1", "eth2", etc., even though you only have one NIC now), you should find where udev compares the NIC's MAC address in its rules and maps the NIC to something else. For example:

/etc/udev/rules.d/70-persistent-net.rules:

.

       .

# The line will look something like this SUBSYSTEM=="net", ACTION=="add", DRIVERS="?", \ ATTR{address}=="00:19:66:17:ea:ff", ATTR{type}=="1", KERNEL=="eth", \ NAME="eth1"

       .
       .
       .

Comment out all of the lines that map the former NICs and change the line that maps the current NIC, to map it to "eth0" (or whatever name you really want). In this case, we'd change "eth1" to "eth0". Or, take all of the mapping lines out altogether, if you think the network driver will always assign things in the proper order.

Once you know the name of the NIC, edit the "/etc/network/interfaces" file. If you want a static IP address, your file should look something like this:

/etc/network/interfaces:

     auto lo
     iface lo inet loopback
     auto eth0
     iface eth0 inet static
         address 192.168.1.8
         netmask 255.255.255.0
         gateway 192.168.1.1

You can force the issue by including the actual MAC address in the "/etc/network/interfaces" file, in which case you'll get an error in the log, when you try to bring up networking, if the MAC address ever changes. This may be preferrable to udev just remapping your NIC to eth5 (or whatever), when you install a new one, and having DHCP take over. In that case, networking will appear to be working but when you try to reach the system with its supposed static IP address, you'll get a huge surprise. To force the MAC address to be checked, do this:

     auto eth0
     iface eth0 inet static
         hwaddress ether 00:19:66:17:ea:ff
         address 192.168.1.8
         netmask 255.255.255.0
         gateway 192.168.1.1

For earlier versions of Mythbuntu, you can put your DNS servers directly in "/etc/resolv.conf", optionally along with your domain name search string. This should look something like this:

     search mysite.com
     nameserver 151.203.0.84
     nameserver 151.203.0.85
     nameserver 204.122.16.8
     nameserver 216.231.41.2

However, for later versions of Mythbuntu the resolvconf command is used by the networking scripts to set the DNS servers dynamically, as interfaces are brought up/down. This means that any changes made to "/etc/resolv.conf" will be wiped out in short order. For those systems, the proper way to set the list of DNS servers is with the "dns-nameservers" and "dns-search" commands in the "/etc/network/interfaces" file, like this:

     auto eth0
     iface eth0 inet static
         hwaddress ether 00:19:66:17:ea:ff
         address 192.168.1.8
         netmask 255.255.255.0
         gateway 192.168.1.1
         dns-nameservers 151.203.0.84 151.203.0.85 204.122.16.8 216.231.41.2
         dns-search mysite.com

However, if you want a dynamic IP address that is obtained from DHCP, there is no need to put anything in "/etc/resolv.conf" or "/etc/network/interfaces". Merely change "/etc/network/interfaces" to look like this:

     auto lo
     iface lo inet loopback
     auto eth0
     iface eth0 inet dhcp

Now, we can uninstall the Network Manager using the Package Manager (in later versions of Mythbuntu, the Package Manager has been replaced with a video game called Ubuntu Software Center, whose aim in life appears to be to sell you magazine subscriptions. If you hate this application, like we do, see the "Useful Software" section for notes on how to install the Synaptic Package Manager and the "Useless and Annoying Software" section for notes on how to remove the Ubuntu Software Center). Using one of the GUI package managers (or apt-get, for that matter) is by far and away the easiest way to disable the Network Manager. Search for "network-manager". You should see the network-manager package, and possibly the network-manager-gnome package at the head of the list. Uninstall it (them) and any dependencies too.

Once you're done, you can yo-yo the network down/up. On earlier versions of Mythbuntu, this is accomplished like so, from the console:

     sudo /etc/init.d/networking stop
     sudo /etc/init.d/networking start

On later versions of Mythbuntu, that use upstart, this might be accomplished with, from the console:

     sudo stop networking
     sudo start networking

Although, under Mythbuntu 12.04LTS, this method doesn't work and seems to leave networking sort of in limbo (nice work, guys -- that upstart thingy is a real winner). Of course, the ultimate test is to reboot the system, which works even when upstart doesn't. Either way, a ping to another system should prove that everything is working OK. If you'd like to admire your handiwork, you can try:

     /sbin/ifconfig

File System Table

The latest system install processes all seem to want to use that "cool" new feature, the UUID, to mount partitions from the file system table. If you look in /etc/fstab you'll see something like this:

     # /boot was on /dev/sda1 at boot time
     UUID=ABC123...

This is another fabulous idea whose time has not come. You may notice one day that your swap space is missing. Or you may not be able to mount partitions after copying a disk or doing something else to the partitions. Whatever the reason, the good old reliable way of mounting partitions is the best. You should check your fstab to ensure that it looks something like this:

/etc/fstab:

     # /etc/fstab: static file system information.
     #
     # <file system> <mount point>   <type>  <options>       <dump>  <pass>
     proc            /proc           proc    defaults        0       0
     /dev/sda1       /boot           ext3    defaults        0       2
     /dev/sda2       none            swap    sw              0       0
     /dev/sda3       /               ext3    defaults,errors=remount-ro 0       1
     /dev/sdb1       /mnt/sdb1       xfs     defaults        0       2
     /dev/sdc1       /mnt/sdc1       xfs     defaults        0       2
     /dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec 0       0

Use absolute partition names (e.g. "/dev/sda1") and you shouldn't experience any problems with partition mounting.

Incidentally, while we're talking about the partition table, if you are mounting any XFS partitions, you need to make sure that the xfsprogs package is installed on the system, or the XFS partitions will fail to mount upon startup with a disconcerting message about "a serious error". You can choose to skip the error and then mount the drives later on, with no problems, like this:

     mount /mnt/sdb1

So, what's going on? Failing to install the xfsprogs package, omits the fsck.xfs program which is needed to check XFS drives. Since it is missing, when fsck tries to invoke it to check the XFS drives at startup, the check fails and fsck decides that there is a serious error. However, there's nothing really wrong with the drives, which is why you can mount them later on. The solution is to reinstall the xfsprogs package, like this:

     apt-get install xfsprogs

Mythfilldatabase


Many of the steps that follow ask you to run mythfilldatabase after they are completed. Never run it except on the master backend. Also, you may need to recycle the master backend and run mythfilldatabase when you are done with some of the changes, below, for them to take effect.

General Configuration Options

Here are some general configuration options you need to consider when you run the MythTV backend configuration:

     Local Backend
       IP Address: your-ip-addr-here       (This is required)
       Security PIN (Required): 0000       (This is required)
     Master Backend
       IP Address: your-ip-addr-here       (This is required)
     VBI format: NTSC Closed Caption
     Channel frequency table: us-cable
     HD Ringbuffer size (KB): 65800
     Save original files after transcoding (check)
     Maximum Simultaneous Jobs: 2

Note that you can run MythTV on a machine that obtains its IP address dynamically but good luck making it work as a backend. Essentially, all of the frontends need to know what the backend's IP address is and this ain't happenin' if its assigned with DHCP. So, using a static IP is A Good Thing (tm).

Furthermore, if you are running a master backend and one or more a secondary backends, every backend has to know the IP address of the master and the master must know the IP address of the secondary. This means that you must fill in a real IP address for the Local Backend and Master Backend on every machine. If you don't all sorts of stuff will stop working. And, don't even think of using an IP address like 127.0.0.1 for the Local Backend. This address is stored in the database and when any of the other machines reference it, it will confuse the heck out of them.

Also note that, if you do things like define capture cards (below) you may have to have a valid Master Backend address filled in or your capture card will not appear.

Recovering From General Configuration Errors

MythTV being what it is, recovery from configuration errors is not high on its list of things to do. This being the case, it is possible to set some of the General Configuration options so that the frontend and/or backend may not run. Since editing of these parameters is generally done via the frontend, you may find yourself in a "you can't get there from here" situation.

To recover from such a situation, you can edit the General Configuration options directly in the text file where they are stored (these options control access to the database, hence cannot be stored in the database). They are found in the text file /etc/mythtv/mysql.txt. A typical set of options is:

     #
     # Host name or IP address for master backend (where the database
     # lives).
     #
     DBHostName=192.168.1.13
     #
     # By default, Myth tries to ping the DB host to see if it exists.
     # If your DB host or network doesn't accept pings, set this to no:
     #
     DBHostPing=no
     #
     # Used to connect to the MySQL database.
     #
     DBUserName=mythtv
     DBPassword=asecret
     DBName=mythconverg
     DBType=QMYSQL3
     #
     # Set the following if you want to use something other than this
     # machine's real hostname for identifying settings in the database.
     # This is useful if your hostname changes often, as otherwise you
     # will need to reconfigure mythtv (or futz with the DB) every time.
     # TWO HOSTS MUST NOT USE THE SAME VALUE
     #
     #LocalHostName=my-unique-identifier-goes-here
     #
     # If you want your frontend to be able to wake your MySQL server
     # using WakeOnLan, have a look at the following settings:
     #
     # The time the frontend waits (in seconds) between reconnect tries.
     # This should be the rough time your MySQL server needs for startup
     #
     #WOLsqlReconnectWaitTime=0
     #
     # This is the number of retries to wake the MySQL server
     # until the frontend gives up
     #
     #WOLsqlConnectRetry=5
     #
     # This is the command executed to wake your MySQL server.
     #
     #WOLsqlCommand=echo 'WOLsqlServerCommand not set'

Incidentally, if you ever forget the password to the database, it can be found in the /etc/mythtv/mysql.txt on the master backend.

Capture Cards

Set up the capture cards that you have installed in your system through the MythTV backend configuration. We have set up systems using the Hauppauge PVR-150 cards (for analog recording), the pcHDTV 5500 cards (for HDTV recording), the AVerMedia A180 cards (for HDTV recording), the Hauppauge PCTV HD 800i cards (which are really Pinnacle cards, for HDTV recording), and the Hauppauge HVR-2250 dual tuner cards (for HDTV recording only). All of these cards work well and have been, in some cases, running on our systems for 3-4 years.

Each of these cards is detailed in a separate section that follows. Analog TV is pretty much old news, so most of the cards that we use are for HDTV recording only. However, should you need to record analog signals, the PVR-150 cards, with their onboard MPEG encoders, are the best, in our opinion, to use. Many are available on the various auction sites for quite reasonable prices.

Once your capture cards are set up, define your video sources (i.e. channel lineups) as described in the Video Sources section (below) and then associate them with the capture cards, as described in the Input Connections section (also below).

Hauppauge PVR-150 Capture Card

The Hauppauge capture cards such as the PVR-x50 cards (this includes the PVR-150 and PVR-250 cards), which have MPEG2 encoders, should be set up using the "MPEG-2" encoder option, not the Analog V4l capture card option. The setup is pretty simple, since all you have to do is select the "MPEG-2" option from the Capture Card Setup page. Earlier versions of MythTV may have an "IVTV" option but this should be eschewed in favor of the "MPEG-2" option. That's about all there is to it.

However, if you have both a PVR-x50 card and a pcHDTV card (or one of the other HDTV cards like the HD 800i) in the same box (because the analog recording with the pcHDTV card kludge doesn't work worth a darn), you may experience a collision between the two cards. Depending on the order in which they are plugged into the PCI bus, one or the other of the cards may disappear when it comes time to configure them. This can be corrected by changing /etc/modprobe.d/options (outside of backend configuration):

     sudo touch /etc/modprobe.d/options
     sudoedit /etc/modprobe.d/options

Add the following line (or one similar to it):

     # Fix collision between pcHDTV/HD 800i and PVR-150.
     options cx8800 video_nr=2 radio_nr=2

Once you've made all of your changes, you may want to reboot the system a few times to be sure that what you've done is working. One can never be too sure when the clever, little PCI bus is involved.

If you wish to test that the card is working, before you let MythTV have at it, you first need to ensure that the v4l and ivtv utilities are installed:

     su
     apt-get install v4l-utils
     apt-get install ivtv-utils

Once you've done that, you can try the following (assuming that you're debugging the first card in the system, on /dev/video0) from a console on the primary display:

     v4l2-ctl -i0 -d /dev/video0
     ivtv-tune -c3 -d /dev/video0
     mplayer -vf pp=lb /dev/video0

You should see a mplayer window that shows the analog program that is currently playing on channel 3, on tuner 1. If, for example, the card is cabled to the output of a cable company DTA, this should show you whatever is playing on the channel selected on the DTA.

pcHDTV HD-5500 Capture Card

This card is designed specifically to work with Linux and, as such, it works very well with MythTV. The drivers for the card are the DVB drivers, which are built in to all of the later releases of the kernel, that are used for Mythbuntu. Setup is quite simple. You should always set up the capture cards from pcHDTV as DVB cards (although, if you wish, see Recording HDTV And Analog TV Using The pcHDTV Cards, below). The choice, listed on the setup page, should be the one that says "DVB" (it may also specifically mention the pcHDTV card -- since it is so popular, it is often included as an example of a typical DVB card).

For the pcHDTV HD-5500 cards, a couple of options that you will probably want to use are:

     Recording Options
     Max Recordings: 1
     Open DVB Card on demand: (check)

If you are getting your guide data via EIT, you might want to enable it on the pcHDTV encoder. To do so, check the EIT box:

     Use DVB card for active EIT scan: (check)

If you have multiple pcHDTV cards, you could have a problem with the audio on these cards. Each card provides sound through its own Conexant CX8801 audio chip (cx88_alsa module). When multiple tuners are present the order of the sound devices as listed in /proc/asound/cards may change from one boot to the next, causing an apparent loss of sound. This can be corrected by changing (also outside of backend configuration) either /etc/modprobe.d/alsa-base or for later versions of Mythbuntu, /etc/modprobe.d/alsa-base.conf:

     comment out:
       # options cx88_alsa index=-2
     add the following (example for two cards):
       # Force the order of the audio chips in pcHDTV cards.
       options cx88_alsa index=1,2

To edit /etc/modprobe.d/alsa-base, use:

     sudoedit /etc/modprobe.d/alsa-base

While, to edit /etc/modprobe.d/alsa-base.conf, use:

     sudoedit /etc/modprobe.d/alsa-base.conf

And, while we're talking about monkeying with the modules in modprobe.d, you may want to add the following line to /etc/modprobe.d/options:

     options dvb_core dvb_shutdown_timeout=0

You can edit this file as described above. This change will make switching between HDTV and analog TV work much better on the pcHDTV HD-5500 card.

After you've made all of your changes, you may want to reboot the system a few times to be sure that what you've done is working. One can never be too sure when the clever, little PCI bus is involved.

Hauppauge PCTV HD 800i Capture Card

This card is a low-profile card that can readily be used in place of the pcHDTV card (wherever that card is deployed). And, the good news is that its about $40 cheaper.

The drivers for the card are the DVB drivers, which are built in to all later releases of the kernel that are used for Mythbuntu. Setup is quite simple. You should always set up the HD 800i capture cards as DVB cards. The choices listed on the setup page will include one that says "DVB", and that's the one you should choose.

For the HD 800i cards, a couple of options that you will probably want to use are:

     Recording Options
     Max Recordings: 1
     Open DVB Card on demand: (check)

If you are getting your guide data via EIT, you might want to enable it for the HD 800i encoder. To do so, check the EIT box:

     Use DVB card for active EIT scan: (check)

AVerMedia A180 Capture Card

This card is billed as a much better card than the pcHDTV HD-5500 card by those who use it. It is not a low profile card so, if you need that feature, you're out of luck. But, if you have room in your system for a full-height card, you might want to give it a spin (its cheaper too). Unfortunately, as with most things Mythbuntu, plug and play is not going to happen. Let the goat rope begin.

First, under Mythbuntu 8.04LTS, support for the card is not built-in (despite the fact that there is a saa7134 driver included). However, later versions support it (possibly through the saa7133 driver), in which case you'll be able to skip the driver installation step.

Despite which driver is used, in all cases so far, to get support for this card, you do need to download some firmware. Downloading the firmware is accomplished through a simple, little, 500-line script that is included in the kernel documentation. You can download the entire set of kernel documentation, for example:

     sudo apt-get install linux-doc-2.6.24
     cd /usr/share/doc/linux-doc-2.6.24/Documentation/dvb
     sudo gzip -d get_dvb_firmware.gz
     sudo chmod +x get_dvb_firmware

Or, if you simply want to get the script (sure seems easier to us), you can find it at:

     http://www.mjmwired.net/kernel/Documentation/dvb/get_dvb_firmware

Click the link that says "Remove Line Numbers" and then copy the script and paste it into a file. Make sure you include a newline on the last line and remove any <CR>s if you used Windoze to create it. Then:

     chmod ugo+x get_dvb_firmware

Before you run the script, you must have the unzip command installed. You can do this with:

     sudo apt-get install unzip

Create a directory for downloaded firmware and change to it. Then, download the firmware using the script:

     get_dvb_firmware nxt2004

Copy the firmware to your kernel's firmware directory:

     sudo cp dvb-fe-nxt2004.fw /lib/firmware/`uname -r`

For later versions of Mythbuntu, the kernel version is left off of the firmware directory so the copy looks like this:

     sudo cp dvb-fe-nxt2004.fw /lib/firmware

On earlier versions of Mythbuntu, the next step is to blacklist the old saa7134 driver (so that it won't try to screw things up):

     sudoedit /etc/modprobe.d/blacklist

After a certain point in the Mythbuntu version sequence, all blacklist files must end with ".conf". If you see such files in "/etc/modprobe.d", you should instead do:

     sudoedit /etc/modprobe.d/blacklist.conf

Add the following lines to the blacklist file:

     # Get rid of the old saa7134 driver. We have a newer one from AVerMedia.
     blacklist saa7134

Then, we need to load the new, DVB saa7134 driver. To do so, hack "/etc/modules":

     sudoedit /etc/modules

Add the following lines to the modules file:

     # Load the newer saa7134 DVB driver.
     saa7134-dvb

With the later versions of Mythbuntu (e.g. 12.04) that support this card through the saa7133, you simply need to tell the system which driver should be used for the card. To do this, we add a few lines to the "/etc/modprobe.d/options" file (which you may have to create). Using the editor, add the following (for two cards):

     # The AverMedia A180 cards are autodetected as saa7133 cards.  We need
     # to force them to use the saa7134 driver.
     options saa7134 card=75,75

There is no need to blacklist the 7134 driver. In fact, if you do, the cards won't operate properly. Just add the lines above to the "options" file. Confused by all this? You can find further help at:

     http://linuxtv.org/wiki/index.php/AVerMedia_AVerTVHD_MCE_A180

As noted for the other capture cards, above, once you've made all of your changes, you should reboot the system a few times to be sure that what you've done works.

You can now set up the A180 capture cards that you have installed in your system through the MythTV backend configuration. Note that you should always set up the capture cards from AVerMedia as DVB cards. The proper choice is "DVB DTV capture card (v3.x)".

As with the pcHDTV cards, for these cards, a couple of options that you will probably want to use are:

     Recording Options
     Max Recordings: 1
     Open DVB Card on demand: (check)

The HowTo for this card can by found in the MythTV wiki:

     http://www.mythtv.org/wiki/index.php/AVerTV_HD_A180

Also, this card is quite similar to the ATI HDTV Wonder card so these installation instructions might be useful for it too.

Hauppauge HVR-2250 Capture Card

This low profile card has dual tuners in it but, as of now, only supports digital TV. If that's all you need, you might consider using one of these cards. The MythTV wiki has more information here:

     http://www.mythtv.org/wiki/Hauppauge_HVR-2250

The drivers for this card were developed by Stephen Toth and can be found on the Kernel Labs site:

     http://www.kernellabs.com/blog/?page_id=17

Eventually, the drivers should show up in the latest version of Mythbuntu because they were merged into the LinuxTV sources in February of 2010 (e.g. Mythbuntu 11.04 has them included). In the meantime, you can either build the latest V4L-DVB source, available from:

     http://linuxtv.org/repo/

Or, if you want to build the latest stable SAA7164 driver source, you can get the latest version from:

     http://kernellabs.com/hg/saa7164-stable/

Either way, you will first need to get the firmware for the HVR-2250. Make a directory to hold the firmware and download it:

     cd ~/SAA7164/HVR22xx
     lftp
     mget http://steventoth.net/linux/hvr22xx/*
     quit
     chmod ugo+x extract.sh

Before you run the extract script, you must have the unzip command installed. You can do this with:

     sudo apt-get install unzip

Now, extract the firmware:

     ./extract.sh

Copy the extracted firmware (originally meant for Windows but works equally well under Linux) to the firmware directory for your distribution:

     sudo cp *.fw /lib/firmware/`uname -r`

Or, if you'd like the firmware to hang around, even after you install the next distribution, copy it to the top level firmware directory:

     sudo cp *.fw /lib/firmware

Note that, for later versions of the the drivers that are included in the OS (e.g. Mythbuntu 11.04, 11.10, 12.04), you will probably also need to get later versions of the firmware. These can be found at:

     http://www.steventoth.net/linux/hvr22xx/firmwares/

The firmware modules can be downloaded directly (without the benefit of unzip). Mythbuntu 11.04, 11.10 and 12.04 appear to want:

     NXP7164-2010-03-10.1.fw
     v4l-saa7164-1.0.2-3.fw
     v4l-saa7164-1.0.3-3.fw

If you browse around the top level directory you should be able to find the required modules. Hints on what the driver is looking for can be found in /var/log/kern.log. You can copy the firmware to either the /lib/firmware/`uname -r` or /lib/firmware directory, as noted above.

If you aren't running a version of Mythbuntu that has the driver built-in you should continue with these steps to build it. Otherwise, if you're using a version of Mythbuntu that already has the driver in it, installing the firmware is all you need to do.

In order to obtain the driver source code and build it, you'll need to install mercurial and build essential for the next steps:

     sudo apt-get install mercurial build-essential

Assuming that we're going to build using the SAA7164 stable version (the steps to build using the latest DVB drivers are outlined at http://linuxtv.org), fetch the source from the Kernel Labs site:

     cd ~/SAA7164
     hg clone http://kernellabs.com/hg/saa7164-stable/

Build the driver as follows:

     cd saa7164-stable
     make

Once the build is successful, install it with:

     sudo make install

Note that, if you install another kernel version (i.e. as a result of upgrading to a new release), you will have to rebuild the driver again (unless, of course, the driver is now supported by your release [e.g. Mythbuntu 11.04, 11.10 or 12.04]):

     cd ~/SAA7164/saa7164-stable
     make distclean
     make
     sudo make install

Some Internet notes about how to set up the HVR-2250 capture cards say that you need to add the following lines to the /etc/modprobe.d/options file:

     # Make the HVR-2250 work.
     options saa7164 card=4

We have not found this to be the case but your mileage may vary. If you think this option will help you, now is the time to add it, before you reboot your system with the new driver.

You will have to reboot your system for the new driver to take effect:

     sudo /sbin/shutdown -r now

You can now set up the HVR-2250 capture card through the MythTV backend configuration. Note that you should always set up the HVR-2250 capture cards as DVB cards (the card itself will be listed as a Samsung S5H1411). The proper choice is "DVB DTV capture card (v3.x)".

You will be able to set up the first encoder on the card when you add it the first time. Once you've done that, add a second encoder and you will then be able to set up the second encoder.

As with the pcHDTV cards, for the HVR-2250, a couple of options that you will probably want to use are:

     Recording Options
     Max Recordings: 1
     Open DVB Card on demand: (check)

If you are getting your guide data via EIT, you will probably only want to enable it on one of the encoders. Pick either the first or the second encoder and check the EIT box:

     Use DVB card for active EIT scan: (check one only)

We have also found that you may need to change the signal tuning timeout from the default of 500 to a more forgiving 3000. You can try going with the default and see where that gets you but we have noticed that some channels (with perfectly strong signals, by the way) do not tune in the allotted time. Since MythTV just silently gives up on recordings without any word of warning, if anything goes wrong, getting this number right is important.

After all this is done, you should be able to see both HVR-2250 encoders. The acid test is if they show up when you Watch Live TV and switch the source. You should be able to switch to both the encoders. If they are not visible in Live TV, we have found that recycling the mythtv-backend task on the master backend system (if your configuration has multiple systems) may be required for them to show up. Not until they show up in Live TV, will the system begin using them for recordings.

Ceton InfiniTV-4

The Ceton InfiniTV-4 provides four CableCARD tuners on a single PCIe 1x card which can simultaneously tune up to four cable channels using a single M-type CableCARD, obtained from your cable company. Depending on which cable company and service you are subscribed to, the exact channels that Mythbuntu will receive can vary. However, the card is also capable of being used without a CableCARD to tune Clear QAM channels.

For the first part of the installation, install the InfiniTV-4 into your system but do not install the cable card yet. There is a bug (or is it a feature) in the card's code that prevents a clear QAM channel's program number from being selected unless the cable card is not installed, and we will be doing basic tests on clear QAM channels first, as part of the installation verification process.

To set up this card on Mythbuntu, you first need to make sure that your version of MythTV is version 0.25 or greater. If you have installed Mythbuntu 12.04 or greater, you will have the requisite version of MythTV.

Next, obtain the latest InfiniTV-4 Linux driver source from:

     http://cetoncorp.com/infinitv_support/linux_drivers/

We downloaded the following files:

     ceton_infinitv_fw_20120313_1_1_7_2.IMAGE   (latest firmware)
     ceton_infinitv_linux_driver_1_7.tar.gz     (device driver)
     infinitv_client_1_2.tar.gz                 (client program)
     reset_network.py                           (Python program to reset card)

To build the driver, make sure you have the driver build environment (this is not necessarily the full kernel build environment). To verify that you do have the driver build environment, try:

     ls -l /lib/modules/`uname -r`/build

If you have this directory installed, you're good to go (Ubuntu usually provides it in a typical installation). Otherwise, you'll need to first get the build environment, either using the Package Manager or by doing:

     sudo apt-get install build-essential

Then, you should make sure to install the latest headers for your kernel. When you enter the following command, be sure to use back-quotes:

     sudo apt-get install linux-headers-`uname -r`

Finally, if the link doesn't already exist, link the headers to the build folder in the proper place. This should get you compiling:

     sudo ln -s /usr/src/linux-headers-`uname -r` /lib/modules/`uname -r`/build

Extract the InfiniTV-4 source from the tar file, build then install it:

     make
     sudo make install

The install will do a depmod and install a udev config file so that the device driver will start up properly at the next boot up. If you don't want to reboot, you can load the driver manually like this:

     sudo modprobe ctn91xx

You should now see a pseudo network device with an address of ctn0, which can be observed by typing:

     /sbin/ifconfig

In all probability, the ctn0 device will have an IPV6 address but will not be given an IPV4 address. It will usually be given a MAC address that is of the form 00:22:2c:ff:ff:ff. You should make a note of this MAC address.

The interface to the InfiniTV-4 is via the network. The local network, on the machine where the InfiniTV-4 is installed, is kludged to connect to a device with an IP address of 192.168.200.1 which is actually the control interface of the card (if there are multiple InfiniTV-4 cards installed on the machine, the second card will be given an IP address of 192.168.200.3, the third 192.168.200.5, etc.). In order for the system to talk to the InfiniTV-4, there must be a network device configured on the machine itself which is on the same subnet as the InfiniTV-4 (i.e. 192.168.200.x). This is where the ctn0 device comes in.

The ctn0 device must be given an IPV4 address which is on the 192.168.200.x subnet. Usually, the address 192.168.200.2 is chosen. Note that, only a single address must be assigned to the ctn0 device even if there are multiple InfiniTV-4 cards installed. There is never a ctn1, ctn2, etc. device, since the ctn0 device will suffice to talk to all of the cards.

The InfiniTV-4 card runs a DHCP server on the 192.168.200.1 IP address. If you have an installation of Mythbuntu that doesn't use a static IP address (i.e. that uses DHCP), the DHCP client that runs on your system should obtain a 192.168.200.x IP address from the card at boot time and assign it to the ctn0 device. If you are using static IP addresses or DHCP is disabled for any other reason or you just wish to assign the same static address every time, you will have to add the ctn0 device to your network configuration by editing /etc/network/interfaces:

/etc/network/interfaces:

.

       .

auto ctn0
iface ctn0 inet static

      hwaddress ether 00:22:2c:ff:ff:ff
      address 192.168.200.2
      netmask 255.255.255.0
       .
       .
       .

At this point, you should reboot the system. After the reboot, the ctn91xx driver should come up and a 192.168.200.x IP address should be assigned to the ctn0 device. You can check this again with:

     /sbin/ifconfig

You can also check to see that all of the Ceton devices are created properly by listing them like this:

     ls -l /dev/ceton

You should see devices like:

     crw-rw-rw-  1  root root  231,  0  Aug 10  14:50  ctn91xx_ct10
     crw-rw-rw-  1  root root  231,  7  Aug 10  14:50  ctn91xx_filter0_0
     crw-rw-rw-  1  root root  231,  8  Aug 10  14:50  ctn91xx_filter0_1
     crw-rw-rw-  1  root root  231,  9  Aug 10  14:50  ctn91xx_filter0_2
     crw-rw-rw-  1  root root  231, 10  Aug 10  14:50  ctn91xx_filter0_3
     crw-rw-rw-  1  root root  231, 11  Aug 10  14:50  ctn91xx_filter0_4
     crw-rw-rw-  1  root root  231, 12  Aug 10  14:50  ctn91xx_filter0_5
     crw-rw-rw-  1  root root  231,  1  Aug 10  14:50  ctn91xx_mpeg0_0
     crw-rw-rw-  1  root root  231,  2  Aug 10  14:50  ctn91xx_mpeg0_1
     crw-rw-rw-  1  root root  231,  3  Aug 10  14:50  ctn91xx_mpeg0_2
     crw-rw-rw-  1  root root  231,  4  Aug 10  14:50  ctn91xx_mpeg0_3
     crw-rw-rw-  1  root root  231,  5  Aug 10  14:50  ctn91xx_mpeg0_4
     crw-rw-rw-  1  root root  231,  6  Aug 10  14:50  ctn91xx_mpeg0_5

Another good test is to try pinging the 192.168.200.1 device:

     ping 192.168.200.1

If you get a response, you are in business. Using the Web browser on the machine where the InfiniTV-4 is installed (you must be on the machine where the card is installed because the 192.168.200.x subnet is not visible anywhere else on your local network), you can view the device Web page at http://192.168.200.1. The best way to view this page is to exit out of MythTV and launch the browser from the desktop.

Note that, if you can't get a response or see the InfiniTV-4 at the 192.168.200.1 IP address (or 192.168.200.3, or 192.168.200.5, etc., if you have multiple cards installed), you may need to adjust your firewall settings. If you have a firewall that is local to the system where the device is installed (and only if it is local to that system), you need to permit all traffic on the 192.168.200.* subnet. Since this subnet exists only on the local machine, there is no harm in not firewalling this traffic. Otherwise, if you have a normal network where the firewall is external to the system where the InfiniTV-4 is installed, there's no need to do anything.

Also note that, if you still can't get a response or see the InfiniTV-4, you might want to try the "reset the IP address program", reset_network.py. Download this file and run the code using the Python interpreter. Hopefully, it will reset the card to the proper IP address but you may have to hack the code to get it to do the right thing when multiple cards are installed.

The latest firmware should be loaded into the InfiniTV-4 card before you proceed much further. One of the cards that we received in 2012 had two-year old firmware. Because newer is always better, we got the latest firmware revision from the Ceton Web site (noted above). Loading new firmware into the card is very easy. From the "System" tab of the device Web page, the new firmware file can be browsed for from the "Browse" button at the bottom of the page. Once you find the file, it is uploaded to the device by clicking the "Upload" button. The process takes about 5 minutes. When the upload is done, you should reboot the machine. That's all there is to upgrading the new firmware.

Once again, surf over to the device Web page at http://192.168.200.1. This time, pick the first tuner and then select the "Tuner" tab. You will see a spot where you can enter a frequency. If you know the frequency and program number of any of the clear QAM channels that your cable provider is "required" to broadcast, you can enter the frequency in the "Frequency" box and click the "Tune" button (leave the "Modulation" box set to QAM256). Note that the frequency is in KHz so don't enter something like 525000000. Instead, for example for channel 74, enter 525000. If you don't know what the clear QAM channel frequencies are for your cable provider, you may be able to find them here:

     http://www.silicondust.com/support/channels/

As an example, to use this Web page to find a test channel that one could tune to, one could look up KTLA-DT under Time Warner Cable for the zip code 90210 where one would find:

     89-543   (channel 89, program 543)

Channel 89 has a center frequency of 615000 KHz so one would enter that number before hitting the "Tune" button. At that point, you should see the number 543 listed among the programs carried on that channel, whereupon you can pick that program from the dropdown list and then click the "Set Program" button. Again, as we noted above, setting the program will not work if the cable card is installed so we hope you heeded our advice about leaving it out for now.

Another way to find out what programs are broadcast in the clear by your cable provider, if you have a regular HDTV encoder installed in your system, is to look at the list of channels that were scanned by MythTV when you set that encoder up. You can do a select from the database, like this:

     select callsign, channum, channel.mplexid, channel.serviceid,
         dtv_multiplex.frequency
       from channel join dtv_multiplex on channel.mplexid = dtv_multiplex.mplexid
       where callsign like 'KTLA%';

A third way is to look at the channel map that is created by your television set, if it provides such a map.

Once you have picked a channel frequency and program number for a clear QAM channel that is broadcast by your cable provider, from the device Web page, you can check that the card has tuned to that channel correctly and that you can view the selected program. The device driver creates special devices for each of the four tuners on the card and one of them (named like ctn91xx_mpeg0_0, as shown in the listing above) carries the stream for the selected channel/program on the first tuner. You can view it with this command, entered into a command window that is open on the desktop:

     cat /dev/ceton/ctn91xx_mpeg0_0 | mplayer -cache 8192 -

If you see the correct TV program for the selected channel/program, you have installed the card correctly.

It is now time to proceed to pairing the cable card with the InfiniTV-4. Shut down the system and insert the cable card into the InfiniTV-4. Once that is done, start the system back up.

To pair the cable card with the InfiniTV-4, you will need to surf over to the device Web page again and pick the "CableCARD" tab. Under this tab, you will will see a link that says something like "CableCARD(tm) Pairing". When you click this link, a new page will appear that shows a phone number to call and the following information:

     CableCARD ID: nnn-nnn-nnn-nnn-n
     Host ID: nnn-nnn-nnn-nnn-n
     Data: nnn-nnn-nnn-nn
     UnitAddress: nnn-nnnnn-nnnnn-nn
     Card S/N: ccnnnnccnnnn
     eCM MAC: Unknown
     Host MAC: hh:hh:hh:hh:hh:hh
     Host Type: One-way

You'll need some or all of this information to pair the cable card with the InfiniTV-4.

If you are lucky enough to be a Verizon FIOS customer, you can pair them by surfing over to this link:

     http://www.verizon.com/fiostv/selfinstall

You will need the activation code that came on the Customer Receipt that was shipped with the cable card. Follow the instructions on the Web site to pair the cable card. For us, it took about two minutes after we completed entering the pairing information for Verizon to send the activation message to the cable card and activate it. After that, the channel map showed up in about 10 or 15 minutes.

Otherwise, you should call the phone number that was shown on the "CableCARD(tm) Pairing" page. Good luck with the cable company. You may find yourself, unable to speak to a human, in a IVR menu loop that doesn't do you any good. If that's the case, you can try saying the word "operator" to get to a real human. This works, for example, on the Verizon activation line.

Once the CableCARD is paired with the InfiniTV-4, you should be able to verify this fact by going to the "CableCARD" tab of the device's Web page. There you will see a message that says something like, "Activated, activation message received, authenticated ...". If you see that, there is a good chance that the pairing has been successful. If you don't see it, the pairing was unquestionably unsuccessful.

After the channel map arrives, you can view it from the same "CableCARD" tab of the device's Web page. Further down the page, you'll see the "Number of Channels" field. Intuitively, if you click on the "Number of Channels" field tag (i.e. click on the string "Number of Channels" itself), you will be shown the channel map. This will give you an idea of the channel numbers that you can use to tune the InfiniTV-4's tuners.

Pick a channel number that is obviously an encrypted channel (e.g. USA, TNT, A&E). Go to the "One" tab of the device's Web page and then click the "Tuner" therein. You will see a "Channel" where you can enter your chosen channel's number. Click the "Set Channel". This will cause the channel map to be used to look up the actual channel frequency and program number, for the virtual channel that you entered, and tune the first tuner to them. You should now be able to view the chosen channel with this command, entered into a command window that is open on the desktop:

     cat /dev/ceton/ctn91xx_mpeg0_0 | mplayer -cache 8192 -

If you see the correct TV program for the selected virtual channel, you have paired the CableCARD correctly and it is initialized with the correct rights, etc. If not, you've got some troubleshooting to do.

Go to the "Log" tab of the device's Web page and scroll down to bottom of the log. If you see something that looks like this:

     [0] Sending ca_pmt to CableCARD for program number 108 index 0
     WARNING: [0] Timed out waiting for CCI (recvd 0)

That is to say, the CableCARD timed out and didn't send a CCI. If you see such a log entry, your CableCARD has not been set up properly, regardless of whether it is paired properly and what it says on the CableCARD tab.

You need to get on the phone with your cable provider's Tech Support. If you can't get your point across to the Tier 1 support people and convince them to do what you ask (i.e. reset the CableCARD), try to get them to connect you to the Tier 2 support people.

What you need to do is convince Tech Support to send your CableCARD a master reset, which is sometimes called a grandslam hit, or a cold hit, or a DAC Init hit. This will cause it to be reinitialized with the correct rights (i.e. the ability to decrypt the content you've paid for). Despite the fact that the card is paired and authorized correctly, channel decryption may not work correctly until you do this.

On the other hand, if you see a log entry that says something like this:

     [0] CCI 01 arrived for program 108

You are never going to see this channel (or at least the current content on this channel) because DRM will not permit it. Choose another channel. If they all have the same problem, you are probably out of luck, but its a good bet that you will only experience this problem on the premium channels that your cable provider broadcasts (e.g. even if you are subscribed to HBO, you are probably not going to be able to see it).

Incidentally, just for reference sake, here's a list of the CCIs and what they mean:

     0x00 - Copy Freely.
     0x01 - Copy No More.
     0x02 - Copy Once (the content can be recorded).
     0x03 - Copy Never (the content can be recorded but only viewed in the
              next 90 minutes, whereupon it is deleted).

By the way, if you are still experiencing problems with encrypted channels, you may be tempted to try the Python client program that is provided by Ceton. Our advice is to eschew this turkey. We extracted it, fixed the bugs in it so that it would run, and then tried it out. It did let us set the channel number on a tuner but then it just sat there looking stupid. When we cancelled it, it left a process hanging around that locked the tuner. Even as root, we couldn't kill the process. Thus, after using it a few times, we had to reboot the sytem to get the tuners back. Swell behavior for a program that does essentially nothing (you can tune to any channel from the Web UI as many times as you like).

Anyway, until you can see at least one encrypted channel with mplayer, using the device's Web page to tune to the channel, there's no point in proceeding to set up MythTV (unless all you want is unencrypted channels -- in which case, why did you get the CableCARD in the first place).

When you are ready to set up your InfiniTV-4 under MythTV (remember you need Myth 0.25 or greater), you may find that some preparatory work is beneficial. Certainly, you can use a listings source such as Schedules Direct, along with mythfilldatabase, to get a channel lineup, and then select it when you connect the card to the input source.

To do this, you should create a video source normally, from the Backend Setup screens. If you are using a listings source (such as Schedules Direct), select it from the dropdown list. When you set up the four tuners on the InfiniTV-4, you will connect the video source to the input of each recorder. There is no need to do a channel scan if you are using a CableCARD. Simply click the "Fetch channels from listings source" button when making the the input connection. If, on the other hand, you aren't using a CableCARD with the InfiniTV-4, then you will need to click "Scan for channels" just as if it were a conventional Clear QAM card.

We, however, prefer to build our channel lineups ourselves, manually. To do this, we begin with the virtual channel map that is sent by the cable provider to the InfiniTV-4. If your cable provider is like ours, you'll see about 700 channels in the virtual channel map. Probably 40 or 50 of them are all that you really care about. If there are only a few of them, you can write them down by hand by proceeding to the "CableCARD" tab of the device's Web page. Near the bottom of the page, you'll see the "Number of Channels" field. As we said above, intuitively, if you click on the "Number of Channels" field tag (i.e. click on the string "Number of Channels" itself), you will be shown the channel map.

If there are a lot of channels that you are interested in, you can try to download the channel map to a file. Unfortunately, the channel map is displayed by a routine on the Web page that uses Ajax (i.e. there is nothing to save, if you save the page itself). To figure out where the channel map is being loaded from, you need to look at the page source. The last time we did this, the channel map's pages were being loaded from:

     http://192.168.200.1/view_channel_map.cgi?page=1

You can view subsequent channel map pages by using page numbers 2, 3, etc. The pages will be shipped to your Web browser as basic HTML pages, which can be saved, one at a time, to flat files. You can then combine and edit them to get a complete channel list. For us, the channel list looks something like this:

.

       .

550 USA Network HD
551 TNT HD
552 TBS HD
553 FX HD

       .
       .
       .

We prefer to manually check all of the channels in the channel map, that we want to include in our MythTV lineup, before we build the lineup. That way, we know what will work beforehand, without needing to account for any MythTV strangeness. However, this process is quite laborious and you may wish to skip it. It is certainly not required.

To create a lineup by hand, we construct an SQL file that cleans out any pre-existing lineup, from the channel table, and then builds a new lineup from the SQL statements that we supply.

The first step is to determine which source ID to use. This can be extrapolated from the existing source IDs, which can be listed from the database like this:

     select sourceid from channel group by sourceid;

Pick a source ID that isn't already in the channel table and start by adding it (you only need to do this once) to the database like this (here we're assuming a source ID of 5):

     insert into videosource values(5, 'Fiber-CC', '/bin/true', '', 'us-cable',
       NULL, NULL, 0, NULL, -1);

You can also add the new video source from the backend setup GUI but we find that this approach involves too much screwing around. A simple SQL insert command is so much easier. Your mileage may vary.

The next step is to begin constructing the SQL file that will create the lineup by starting with a line that deletes any preexisting lineup:

FIOS-Mytown_CCardLineup.sql:

     -- WARNING: The following line clears out the Fiber-CableCard channels in
     --          the channel table
     delete from channel where sourceid=5;
          .
          .
          .

Now, we add an entry for each channel that we care about, that is found in the virtual channel table sent by the cable provider. These entries should include the channel number and frequency to tune to (the same number), the chosen source ID, the call sign, the name and an XMLTV ID. You can also set the visible attribute to either show the channel in the channel list or not. All the rest of the fields can probably take the defaults. A typical entry will look like:

FIOS-Mytown_CCardLineup.sql:

.

       .

-- Add the HD virtual channels supported by the CableCARD insert into channel set chanid=5550, channum='550', freqid=550, sourceid=5, callsign='USA-CCFi', name='USA Network HD', icon='', finetune=NULL, videofilters='', xmltvid='5550', recpriority=0, contrast=32768, brightness=32768, colour=32768, hue=32768, tvformat='Default', visible=1, outputfilters='', useonairguide=0, mplexid=NULL, serviceid=NULL, tmoffset=0, atsc_major_chan=0, atsc_minor_chan=0, last_record='0000-00-00 00:00:00', default_authority='', commmethod=-1;

       .
       .
       .

Proceed through all of the virtual channels that you wish to see, from the channel table that was obtained by the InfiniTV-4.

Pay particular attention, if you will be loading your own guide data (see Making Up Guide Data) or using one of the XMLTV grabbers to obtain guide data. Ensure that you set the xmltvid field to the channel identifier that matches the second display-name that the XMLTV data uses for each channel. Typically, this is the channel number or call sign but you may want to inspect the XMLTV data first to determine what to use.

A complete set of updates should look something like this:

FIOS-Mytown_CCardLineup.sql:

     -- WARNING: The following line clears out the Fiber-CableCard channels in
     --          the channel table
     delete from channel where sourceid=5;
     -- Add the HD virtual channels supported by the CableCARD
     insert into channel set chanid=5550, channum='550', freqid=550, sourceid=5,
       callsign='USA-CCFi', name='USA Network HD',
       icon='', finetune=NULL, videofilters='', xmltvid='5550', recpriority=0,
       contrast=32768, brightness=32768, colour=32768, hue=32768,
       tvformat='Default', visible=1, outputfilters='', useonairguide=0,
       mplexid=NULL, serviceid=NULL, tmoffset=0,
       atsc_major_chan=0, atsc_minor_chan=0, last_record='0000-00-00 00:00:00',
       default_authority='', commmethod=-1;
     insert into channel set chanid=5551, channum='551', freqid=551, sourceid=5,
       callsign='TNT-CCFi', name='TNT HD',
       icon='', finetune=NULL, videofilters='', xmltvid='5551', recpriority=0,
       contrast=32768, brightness=32768, colour=32768, hue=32768,
       tvformat='Default', visible=1, outputfilters='', useonairguide=0,
       mplexid=NULL, serviceid=NULL, tmoffset=0,
       atsc_major_chan=0, atsc_minor_chan=0, last_record='0000-00-00 00:00:00',
       default_authority='', commmethod=-1;
          .
          .
          .

Be aware that you can have two channels with the same number (especially if one is analog and one is digital) but you probably won't be happy with the consequences. For example, despite the fact that you're viewing TV using a digitial encoder, and you've defined a digital channel 12, entering 12 on your remote, to change to that digital channel, may result in MythTV switching to an analog encoder and showing you analog channel 12 instead. Worse yet, recordings may end up on the wrong encoder (see How MythTV Chooses Which Input To Record).

Consequently, for virtual channels that mirror analog channels, it is much better to move them to a higher range (such as 5nn), thereby keeping them unique. The channel number given by "channum" is the displayed channel number. The virtual channel that is tuned by the InfiniTV-4 is the number given by "freqid". The two numbers are usually kept the same but they need not be. Note that you can use anything you like for "channum" but, if you don't use numerics and you don't use the proper separator character, MythTV will sort your channels in odd order.

Once you've built your channel definitions file, you can feed it in to MySQL with this command:

     source /path/to/file/FIOS-Mytown_CCardLineup.sql

Setting up the four tuners on the InfiniTV-4 is anticlimatic. Once you've completed all of the above steps, you know that the device is working and you have what should be a good lineup already built. All that is left is to run the MythTV Backend Setup program from the System menu on the desktop. Before it comes up, you'll be asked to shut down the backend, for which your password is required.

From the first menu, pick "Capture Cards". The screen that comes up lists all of the currently defined cards (if any) and has a selection for adding new cards. Pick "New capture card."

On the first capture card page, you need to pick "Ceton Cablecard Tuner" from the dropdown list under "Card type:". You will then fill in the IP address that you assigned to the first (or only) InfiniTV-4 under the "IP Address:" field. Despite the fact that the help text says the default is 192.168.200.1, you must actually fill this IP address in. If you have more than one InfiniTV-4, the next IP address will probably be 192.168.200.3, and so on.

For some reason, you must fill in the card number under the "Card Number:" field, although the IP address should be sufficient to actually identify the device. For the purposes of this field, the first card is numbered 0, the second is numbered 1, and so on.

The last field to be filled in is the "Tuner:" field, which identifies the tuner on the device that is being set up. Note that, in the case of the InfiniTV-4, the device has four tuners. You must define each one individually, repeating all of these steps as each is set up. The first tuner is numbered 0, the second is numbered 1, and so on up to 3.

When you have correctly entered all of the information, a device ID will be made up that looks like "192.168.200.1-0.0". This device ID will be used to refer to the tuner from henceforth. You can click the "Finish" button and the new capture card will be defined.

After you've set up all of the InfiniTV-4 tuners/capture cards, you should exit the "Capture Cards" screen and select "Input Connections" from the main menu. It is here that you will associate the new tuners/capture cards with your previously created lineup. Select each new tuner/capture card from the list and set it up on the ensuing two pages.

On the first page, pick a unique display name that can be used to reference the card and fill it in under the "Display Name:" field. Under the "Video Source:" field, pick your newly-created lineup. The "Use quick tuning:" field should be set to "Never".

As discussed above, there is no need to click either the "Scan for channels" or "Fetch channels from listings source" buttons. Hopefully, you have already built a channel lineup.

The "Starting Channel:" field's value should default to the first channel number defined in your lineup. If you'd rather start on a different channel, you can enter it here but this number is changed every time someone watches Live TV on this tuner so there's no need to stress out over it. It does need to be a valid channel number, though, or the tuner may hang when someone tries to watch Live TV.

When you click the "Next" button, you'll see the second capture card setup page. All of the default values there are acceptable so you just need to click "Finish" to set up the new tuner/capture card. Don't forget to set up all four tuners/capture cards.

When you've set up all four tuners, you can exit the Backend Setup program and restart the backend. You'll need to reenter your secret password for this. We never bother to run mythfilldatabase. You should now be able to record or watch Live TV on all four (or 8, or 12) tuners at once.

A Personal CableCARD Story

If your cable provider is Verizon, you might enjoy this personal CableCARD activation story.

Verizon makes obtaining a CableCARD pretty easy, compared to some of the stories that we've heard about the other cable providers. You can either order one off the Web site or phone customer service and order it that way. When we did it, the card showed up a couple of days later.

The instructions say to just pop the cable card into your STB or DVR and follow the activation steps on the printed sheet that they send you. You have two options. Call the activation hotline or use the activation Web page.

We opted to try the Web site. You need to obtain the Host ID and Data strings from your STB or DVR, or in our case, your PCIe or USB device. We got this information from our adapter card's Web UI and filled it in on the Web site.

Within two minutes, the CableCARD was paired and activated. The activation message had been received, etc., etc. Within 10 minutes, the channel map had shown up. Things were looking good. But, there was no decryption. Only the unencrypted channels were available.

Parenthetically, the people at the adapter card's Tech Support were absolutely no help. They tried to tell us that it was a DRM issue and that only Windoze would work. Apparently, they, like the rest of the world, see the word Linux and can only respond with the W word. The fact that the problem had nothing to do with the OS, in any way, shape or form, was irrelevent. So, bear this in mind when you think about contacting your hardware vendor first. You'll probably be wasting your time. More likely than not, you're on your own in that respect.

Fortunately, the guys who wrote the firmware for the card we were using included some pretty good logging capabilities so we were able to figure out what was really going on. Reading the logs also lead us to find the vendor's position on Linux more than a little bit comical since, unless we miss our guess, the adapter card runs a version of Linux itself. Not sure the guys in Tech Support see that irony, though.

But, we digress. While it is true that Verizon is no longer the Wild West (as of July 31, 2012 their CableCARDs will no longer work with any device, without pairing), and the premium content channels are no longer sent with no CCI set, there is still a lot of content which is available on Linux, without DRM. Typically, depending on your subscription plan, this includes all of the standard cable channels like USA, TBS and A&E, in both SD and HD. So, the fact that there were no encrypted channels available implied that something else was wrong, not DRM.

Thinking that the Web site might not have set the card up the same way that the activation hotline would (there was precedence on the Internet to this effect), we called the phone number.

After taking the initial steps and waiting 20 minutes, we called back (since there was no STB/DVR setup menu that we could use to complete activation). At this point, we got the IVR menu loop: "We see that you have partially completed activation. Go to your STB/DVR and follow the instructions. Call back if you experience problems. Press 8 to rehear these instructions; 9 to end this call; or just hang up."

Since Verizon is doing voice recognition, at this point we spoke the word "operator" (not one of the listed options, by the way). The system said it would transfer us to an agent. We spent 25 or 30 minutes on hold (reading Brucie's blog and listening to the same 32 bars of mindless hold music in an endless loop), waiting for the agent.

When we got the Tech Support person on the line, they had no idea what to do. They asked us where the cable card was installed, and, when we said it was a computer, they asked us if it could connect to the Internet. Eventually, after explaining things a few times (Verizon, by the way, does not care what your cable card is plugged into but you sort of have to get them to accept the fact that it ain't a STB/DVR), we convinced them to do a grandslam hit/cold hit/DAC Init hit/master reset (or whatever it is called). The tech had to have two conversations with the supe befoe they got him the right proceedure to do the reset. The reset worked right away.

Total time for the call about 1 hour.

Incidentally, the problem apparently was caused by the fact that we ordered the CableCARD before July 31, 2012 and it shipped with the wrong rights enabled. By doing the reset, it reloaded the card with the correct rights. Had we ordered the card now, it might have worked right away.

The moral of this story is that, even if your CableCARD says it is paired and activated, it may not work properly. If that's the case, convincing your cable provider to reset it may get things moving along smartly.

Figuring Out Which Card Is Which

Let's say that you have a Mythbuntu system that has a Hauppauge PVR-150, a HD 800i and a HVR-2250 installed in it (All Hauppauge, All The Way). Now, it comes time to configure each one and all you see is:

     Probed Info: Probe failed

Which card is which? You need to know because you have several different inputs attached to each one (e.g. cable company DTA on the PVR-150; the cable as a direct input on the HVR-2250; and a terrestrial antenna on the HD 800i). Without setting them up correctly, MythTV will be trying to record the wrong programs on each encoder.

You can start with a listing of all of the devices on the PCI bus:

     sudo lspci -v

This should give you a (partial) listing that looks something like this:

     01:08.0 Multimedia video controller: Internext Compression Inc iTVC16
         (CX23416) Video Decoder (rev 01)
       Subsystem: Hauppauge computer works Inc. WinTV PVR 150
       Flags: bus master, medium devsel, latency 64, IRQ 17
       Memory at f0000000 (32-bit, prefetchable) [size=64M]
       Capabilities: [44] Power Management version 2
       Kernel driver in use: ivtv
       Kernel modules: ivtv
     01:0a.0 Multimedia video controller: Conexant Systems, Inc.
         CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
       Subsystem: Pinnacle Systems Inc. Device 0051
       Flags: bus master, medium devsel, latency 32, IRQ 18
       Memory at fc000000 (32-bit, non-prefetchable) [size=16M]
       Capabilities: [44] Vital Product Data
       Capabilities: [4c] Power Management version 2
       Kernel driver in use: cx8800
       Kernel modules: cx8800
     01:0a.1 Multimedia controller: Conexant Systems, Inc.
         CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] (rev 05)
       Subsystem: Pinnacle Systems Inc. Device 0051
       Flags: bus master, medium devsel, latency 32, IRQ 18
       Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
       Capabilities: [4c] Power Management version 2
       Kernel driver in use: cx88_audio
       Kernel modules: cx88-alsa
     01:0a.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
         PCI Video and Audio Decoder [MPEG Port] (rev 05)
       Subsystem: Pinnacle Systems Inc. Device 0051
       Flags: bus master, medium devsel, latency 32, IRQ 18
       Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
       Capabilities: [4c] Power Management version 2
       Kernel driver in use: cx88-mpeg driver manager
       Kernel modules: cx8802
     02:00.0 Multimedia controller: Philips Semiconductors SAA7164 (rev 81)
       Subsystem: Hauppauge computer works Inc. WinTV HVR-2250
       Flags: bus master, fast devsel, latency 0, IRQ 19
       Memory at fd400000 (64-bit, non-prefetchable) [size=4M]
       Memory at fd000000 (64-bit, non-prefetchable) [size=4M]
       Capabilities: [40] MSI: Enable- Count=1/16 Maskable- 64bit+
       Capabilities: [50] Express Endpoint, MSI 00
       Capabilities: [74] Power Management version 3
       Capabilities: [7c] Vendor Specific Information: Len=84 <?>
       Capabilities: [100] Vendor Specific Information: ID=0000 Rev=0 Len=060 <?>
       Capabilities: [160] Virtual Channel
       Kernel driver in use: saa7164
       Kernel modules: saa7164

The first entry is for the PVR-150. From it we can see that the decoder is the Conexant CX23416. The next three entries are for the HD 800i. The first of those three entries shows that the decoder is the Conexant CX23880 (the second and third entries are probably for the FM receiver and the S-video input). The last entry is for the HVR-2250. From it we can see that the decoder is the Philips SAA7164.

In another instance, the Mythbuntu system may have a earlier Hauppauge PVR-150 card, a pcHDTV HD-5500 card, and an AverMedia A180 card installed. Its (partial) PCI bus listing might look like this:

     01:06.0 Multimedia video controller: Conexant Systems, Inc.
         CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
       Subsystem: pcHDTV Device 5500
       Flags: bus master, medium devsel, latency 64, IRQ 18
       Memory at df000000 (32-bit, non-prefetchable) [size=16M]
       Capabilities: [44] Vital Product Data <?>
       Capabilities: [4c] Power Management version 2
       Kernel driver in use: cx8800
       Kernel modules: cx8800
     01:06.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
         PCI Video and Audio Decoder [Audio Port] (rev 05)
       Subsystem: pcHDTV Device 5500
       Flags: bus master, medium devsel, latency 64, IRQ 18
       Memory at de000000 (32-bit, non-prefetchable) [size=16M]
       Capabilities: [4c] Power Management version 2
       Kernel driver in use: cx88_audio
       Kernel modules: cx88-alsa
     01:06.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
         PCI Video and Audio Decoder [MPEG Port] (rev 05)
       Subsystem: pcHDTV Device 5500
       Flags: bus master, medium devsel, latency 64, IRQ 18
       Memory at dd000000 (32-bit, non-prefetchable) [size=16M]
       Capabilities: [4c] Power Management version 2
       Kernel driver in use: cx88-mpeg driver manager
       Kernel modules: cx8802
     01:06.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
         PCI Video and Audio Decoder [IR Port] (rev 05)
       Subsystem: pcHDTV Device 5500
       Flags: bus master, medium devsel, latency 64, IRQ 10
       Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
       Capabilities: [4c] Power Management version 2
     01:07.0 Multimedia video controller: Internext Compression Inc iTVC16
         (CX23416) MPEG-2 Encoder (rev 01)
       Subsystem: Hauppauge computer works Inc. Device c801
       Flags: bus master, medium devsel, latency 64, IRQ 19
       Memory at d4000000 (32-bit, prefetchable) [size=64M]
       Capabilities: [44] Power Management version 2
       Kernel driver in use: ivtv
       Kernel modules: ivtv
     01:08.0 Multimedia controller: Philips Semiconductors
         SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
       Subsystem: Avermedia Technologies Inc Device 1044
       Flags: bus master, medium devsel, latency 32, IRQ 19
       Memory at e4101000 (32-bit, non-prefetchable) [size=2K]
       Capabilities: [40] Power Management version 2
       Kernel driver in use: saa7134
       Kernel modules: saa7134

The first four entries are for the pcHDTV HD-5500. From it we can see that the decoder is the Conexant CX23880. The next entry is for the PVR-150 but, in this case, the kernel does not recognize its device number. From it we can see that the decoder is the Conexant CX23416. The next entry is for the Avermedia A180, although its device number is unknown too. Its entry shows that the decoder is the Philips SAA7134.

Now that we're armed with this information, we can try setting up the multiple capture cards from the Mythbuntu Capture Card Setup page. Even if the probe fails to return any information about the card, you can still use the decoder information to figure out which card is which.

Capture Card Database Entries

If you need to add or move capture cards, in order to set them up using a rational organization scheme (instead of the last added scheme that MythTV uses), these database entries may come in useful. Here we list the results of a database dump for various types of capture cards:

                           AverMedia A180           pcHDTV 5500
  cardid                   <x>                      <x>
  videodevice              /dev/dvb/adapter0/frontend0 (adapter1 for 2nd dev,
                             frontend1 for 2nd encoder, etc.)
  audiodevice              NULL                     NULL
  vbidevice                NULL                     NULL
  cardtype                 DVB                      DVB
  defaultinput             DVBInput                 DVBInput
  audioratelimit           NULL                     NULL
  hostname                 <hostname>               <hostname>
  dvb_swfilter             0                        0
  dvb_sat_type             0                        0
  dvb_wait_for_seqstart    1                        1
  skipbtaudio              0                        0
  dvb_on_demand            1                        1
  dvb_diseqc_type          NULL                     NULL
  firewire_speed           0                        0
  firewire_model           NULL                     NULL
  firewire_connection      0                        0
  signal_timeout           3000                     3000
  channel_timeout          5500                     5500
  dvb_tuning_delay         0                        0
  contrast                 0                        0
  brightness               0                        0
  colour                   0                        0
  hue                      0                        0
  diseqcid                 0                        0
  dvb_eitscan              <1|0> (set to 1 for EIT scan wanted on this dev)
                           HVR-2250
  cardid                   <x>
  videodevice              /dev/dvb/adapter0/frontend0 (adapter1 for 2nd
                             dev -- card appears as two devices)
  audiodevice              NULL
  vbidevice                NULL
  cardtype                 DVB
  defaultinput             DVBInput
  audioratelimit           NULL
  hostname                 <hostname>
  dvb_swfilter             0
  dvb_sat_type             0
  dvb_wait_for_seqstart    1
  skipbtaudio              0
  dvb_on_demand            1
  dvb_diseqc_type          NULL
  firewire_speed           0
  firewire_model           NULL
  firewire_connection      0
  signal_timeout           3000
  channel_timeout          3000
  dvb_tuning_delay         0
  contrast                 0
  brightness               0
  colour                   0
  hue                      0
  diseqcid                 0
  dvb_eitscan              <1|0> (set to 1 for EIT scan wanted on this dev;
                             we usually only do the scan on the 2nd adapter)
                           PVR-150
  cardid                   <x>
  videodevice              /dev/video0 (video1 for 2nd dev, etc.)
  audiodevice              NULL
  vbidevice                NULL
  cardtype                 MPEG
  defaultinput             Tuner 1
  audioratelimit           NULL
  hostname                 <hostname>
  dvb_swfilter             0
  dvb_sat_type             0
  dvb_wait_for_seqstart    1
  skipbtaudio              0
  dvb_on_demand            0
  dvb_diseqc_type          NULL
  firewire_speed           0
  firewire_model           NULL
  firewire_connection      0
  signal_timeout           1000
  channel_timeout          3000
  dvb_tuning_delay         0
  contrast                 0
  brightness               0
  colour                   0
  hue                      0
  diseqcid                 0
  dvb_eitscan              1 (don't ask why, it just is)
                           InfiniTV-4
  cardid                   <x>
  videodevice              192.168.200.1-0.0 (-0.1, -0.2, -0.3)
  audiodevice              NULL
  vbidevice                NULL
  cardtype                 CETON
  defaultinput             Television
  audioratelimit           NULL
  hostname                 <hostname>
  dvb_swfilter             0
  dvb_sat_type             0
  dvb_wait_for_seqstart    1
  skipbtaudio              0
  dvb_on_demand            0
  dvb_diseqc_type          NULL
  firewire_speed           0
  firewire_model           NULL
  firewire_connection      0
  signal_timeout           1000
  channel_timeout          3000
  dvb_tuning_delay         0
  contrast                 0
  brightness               0
  colour                   0
  hue                      0
  diseqcid                 0
  dvb_eitscan              1 (don't ask why, it just is)

Recording HDTV And Analog TV Using The pcHDTV Cards

The pcHDTV series cards, especially the HD-5500, can be used to record both HDTV (ATSC, QAM-256, etc.) as well as NTSC, analog TV. Mind you, all of the work of converting the analog signal into an MP2 stream suitable for recording is done by your system's processor, not on the card (there's no MPEG encoder on the card), so it will use quite a few processor cycles while you're recording an analog program. And, there's a good chance that the picture will look bad and the sound will be messed up. But, if you're still game to try it, here's how to set a pcHDTV card up.

Begin in MythTV backend setup, Capture Cards, by selecting "New capture card" to add a new capture card and then define the pcHDTV card as a DVB card, not as a pcHDTV card (now, that's intuitive). Also, unless you're into crazy, experimental stuff, pick Recording Options and then on the page that pops up, set Max Recordings to 1. After you're finished, save the card's definition.

Next, select "New Capture Card" again and define a second capture card, this time as an "Analog V4L capture card". Set the device parameters like this (example shows 'x' for the device number):

     Video device:  /dev/videox
     VBI device:    /dev/vbix
     Audio device:  /dev/dspx+1

Note that the correct DSP device for sound input is the device number plus 1. Then, in the device options fields, be sure to set the Audio sampling Rate Limit to 48000. When you're done, save the card's definition.

If you have more than one capture card, you should perform the same two steps over for each additional card. You'll end up with something that looks like this:

     DVB: 0
     V4L: /dev/video0
     DVB: 1
     V4L: /dev/video1

We prefer to define two video sources, one for the HDTV recordings and one for the Analog recordings. That way, we can have channel numbers that overlap and we can easily switch between analog/HDTV recording, simply by selecting the source. We suppose, if you wished, you could just define one source and use it for both types of recording. However, another consideration is that the pcHDTV cards don't seem to switch between ATSC/QAM-256 and NTSC very well and having two sources allows you to break things out better.

Let's proceed as if we were going to define two sources. From the Video Source page, select "New Video Source". Let's say it is a cable source. Call it "Cable-HD". If you're using Schedule's Direct or XMLTV, set that part up. Otherwise, you can select "Transmitted guide only" or nothing for Listings Grabber.

Now, define a second video source by selecting "New Video Source" again. Call it "Cable-An". Again, set up the schedule puller or nothing, as appropriate.

Its time to associate the video sources with the capture cards so that MythTV knows which cards to use to record programs from each of the sources. Do this from the Input Connections page. Begin by selecting "[DVB:x]".

Set the display name to "Card x". Select the Video Source (in this case, "Cable-HD"). If this is the first card that you're associating with the video source, you can click Scan For Channels to fill in the list of channels available from that source. Scanning will take quite a while so be patient. Then, if you have a listings grabber defined, you can click Fetch Channels From Listings Source to fill in the channel information (if it hasn't already been filled in from the HDTV channel definitions).

On the second page, set the recording grouping to a unique value, instead of "Generic". The input groups for the DVB card or cards are usually predefined by MythTV when you add them so its simply a matter of choosing the obvious one. If that's not the case, click on Create A New Input Group and define one. For the DVB cards, this should be something like "DVB0". Then, set Input Group 1 to new group. You can leave Input Group 2 as "Generic".

After saving the DVB input source's options, select: "[V4L: /dev/videox](Television)"; "[V4L: /dev/videox](Composite1)"; or "[V4L: /dev/videox](S-Video)", depending on which input is connected on the pcHDTV card.

Set the display name to "Card x - Analog". Select the Video Source (in this case, "Cable-An"). Again, if this is the first card that you're associating with the video source, you can click Scan For Channels to fill in the list of channels available from that source. Scanning will, again, take quite a while so be patient. Then, if you have a listings grabber defined, you can click Fetch Channels From Listings Source to fill in the channel information.

On the second page, set the recording grouping to the same unique value, instead of "Generic", that you chose for the DVB card (e.g. "DVBx"). The reason for doing this here (and above) is so that MythTV doesn't try to do HDTV and analog recording on the same pcHDTV card at the same time (since it sees it as two devices). By grouping the devices this way, it will only try to start a single recording on the card at any time. To do this, set Input Group 1 to appropriate group. You can leave Input Group 2 as "Generic".

The channel scan may not identify all of the channels that it finds. The analog channels are especially unlikely to have any identifying information associated with them. If you do not have a listings source and don't fetch the channels from said source, you'll have to edit the channel information by hand using the Channel Editor.

Identify the channels from your cable TV lineup or by watching each one for a few minutes (if you live in beautiful, sunny Norwood, see Unnamed Analog Channels Mapped To HDTV, below). Using the channel editor, fill in each unidentified channel with its channel number, call sign and description. Note that channel numbers must be unique within each of the video sources (e.g. there can only be one channel 2 in Cable-HD and Cable-An). However, you can have an analog channel and digital channel in the same video source with the same channel number, if you use the underscore notation for the HD channels (e.g. channel 2 and channel 2_1).

Actually, the channel numbers don't have to be unique within the same video source. But, the capture card will only tune to the first one that it finds with the non-unique channel number so you may never be able to get to the second one.

Incidentally, you should set the "Use on air guide" flag in each of the HDTV channel's entries so that they will attempt to use the on-air guide for late schedule updates. While you're tweaking this flag in channel entries, you can set the flag to not display the channel in the guide and when channel surfing in LiveTV.

If you wish to avoid confusion while you're editing the channels, you can choose either Cable-HD or Cable-An in the channel editor's Video Source selection field and it will only show those channels, instead of all the channels. Then, keep the channel numbers unique within the viewed channels.

Capture Card Numbering

If you are monkeying around with the capture cards on you system, you will soon discover that the numbering of the cards is not to your liking. When cards are added, the table that contains their information (capturecard) uses an autoincrement column to number each card.

Normally, this would be irrelevant except that the card number is shown in certain user displays (e.g. the upcoming recordings display shows which encoder will record each program). If you would like to know which encoder is doing each recording but have no clue which one is 11, or 4, or 7, you can reset the auto increment value in the capturecard table so that the encoders are numbered sequentially from 1.

Begin by deleting all of the capture cards, using the MythTV Backend Setup program and selecting the Capture Cards section. The Delete All Capture Cards choice will get rid of all the capture cards. Then, do the following from the command prompt:

     mysql -umrwizard -psecretpassword mythconverg
     alter table capturecard auto_increment=1;
     quit

This will reset the auto increment value to 1. You can then re-add all of the capture cards in the order that you like (note that you must do this on each individual machine in the system), making sure to choose the correct options for each one. The cards will be numbered sequentially, from 1, in the order that they are added. Incidentally, if you are going to be using MythWeb, you can also give them more meaningful names (e.g. "HDTV 1" or "Analog 1") for it to use.

Incidentally, if you have any recording rules that are set to use a preferred input, they may not work after you move any of the capture cards around. You can check which recording specified a preferred input. From the database command prompt (see above), you can use this command:

     select * from record where prefinput != 0;

You should be able to figure out which recording rules need to be reset to a different preferred input.

Video Sources

It is here that you define your video signal sources. Typical sources might be Antenna (for an over-the-air signal captured by an antenna), Cable (for regular cable), or Cable-HD (for a high-definition cable signal).

Essentially, the sources defined herein describe all of the channels received on this source and the listings associated with them. If you are using a listings grabber (e.g. Schedules Direct or XMLTV), you can fill its information in here and pull the first block of listings from it. This will also set up the channels.

Otherwise, if you're not using a listings grabber or have other plans, you can just give your input source a name (e.g. Cable-HD). The channels can be set up in several other ways (see below).

Regardless of how you define your video sources, once you've done them once, you're pretty much set for life and can use the same sources over and over again for each video capture card that you define.

Input Connections

The Input Connections section allow you to associate a Video Source with a Capture Card. Essentially, this is where you tell Mythbuntu to look for a particular show on a certain channel on a given card.

For example, if Mythbuntu is going to record a Buffy The Vampire Slayer rerun (or you could just watch whatever episode you like from the video server) and it knows Buffy is on Cable, channel 38, it will look to see which capture cards are connected to the Cable Video Source and then pick one. It will tune the card to channel 38 and its in business.

You can only associate one Video Source with each Capture Card, although some Capture Cards can have multiple tuners and/or can record multiple video streams at one time.

     Display Name: (must supply a name - used to name source when viewing)
     Video source: (Cable, Cable-HD, Antenna, Satellite, etc.)
     Starting channel: (pick one that makes sense)

The second page of this section can be left pretty much at the defaults unless you are setting up a connection that can record multiple sources (see Recording HDTV And Analog TV Using The pcHDTV Cards, below, for example).

If this is your first time through and you haven't set up channels on the Video Source (e.g. you didn't pick a listings source), you can have setup scan the associated capture card to see what's out there. This works for both NTSC and HDTV inputs but the amount of information filled in for NTSC inputs is minimal. You'll probably want to use the Channel Editor (see below) to fill in additional info, disallow bogus channels, etc., once you've done this scan. This option is invoked by clicking "Scan for channels".

Channel Editor

What can I say. This editor lists all of the channels defined for a Video Source, lets you add more, hack the ones that are there and delete those that you don't like. You can also disable channels without deleting them. There are more notes below about how to use it in specific cases. If you are using a bonafide listings source (e.g. Schedules Direct or XMLTV) you probably won't need this feature.

Storage Groups

If you are using one or more separate drives for video recordings storage, you will need to adjust the storage groups to reflect this fact (for later versions of MythTV, you will simply need to add the drives to one or more storage groups, since the pre-defined storage directory is no longer set up).

First, make sure the drives are mounted somewhere (e.g. /mnt/sdb1). If you do not set them up at install time or wish to add them later on, you can hack /etc/fstab to mount them. For example:

.

       .

/dev/sdb1 /mnt/sdb1 xfs defaults 0 2
/dev/sdc1 /mnt/sdc1 xfs defaults 0 2

       .
       .
       .

Or, if you wish to mount the drives by volume identifier, do something along these lines:

.

       .

# /dev/sdb1
UUID=1113935f-a8b6-4f25-a57d-a6e73c69a136 /mnt/sdb1 xfs defaults 0 2 # /dev/sdc1
UUID=adf4297c-75d8-470e-9eda-802986c0d70d /mnt/sdc1 xfs defaults 0 2

       .
       .
       .

After rebooting, For each of the mount points that mount a drive partition you should do the following:

     sudo chown mythtv:mythtv /mnt/sdb1
     sudo chmod g+ws /mnt/sdb1

This will allow MythTV to use the mounted drive partitions as storage space for recordings.

Optionally, if you wish to store several types of media on the new partitions, you should do this instead:

     sudo mkdir /mnt/sdb1/music
     sudo mkdir /mnt/sdb1/recordings
     sudo mkdir /mnt/sdb1/videos
     sudo chown mythtv:mythtv -R /mnt/sdb1
     sudo chmod g+ws -R /mnt/sdb1

On the other hand, if you have a single, integrated drive that holds the OS, the /boot partition, the swap space and all of the recordings, you should define a new subdirectory in the root where MythTV can store recordings. For example:

     sudo mkdir /MythTV
     sudo chown mythtv:mythtv /MythTV
     sudo chmod g+ws /MythTV

Or, once again, if you wish to store several types of media on the new partitions, you should do this instead:

     sudo mkdir /MythTV
     sudo mkdir /MythTV/music
     sudo mkdir /MythTV/recordings
     sudo mkdir /MythTV/videos
     sudo chown mythtv:mythtv -R /MythTV
     sudo chmod g+ws -R /MythTV

Now, you need to run mythtv-setup and add the additional storage to the storage groups so that MythTV can record to them. Probably the smartest way to go about it is to add the new paths to the Default storage group. That way, MythTV will use the new space by default. If you are using an older version of MythTV and want to prevent it from using any of the space on the system partition (or just the inaptly-named directory on the system partition), overwrite the predefined path, /var/lib/mythtv, with the first partition's mount point or the new MythTV subdirectory off the root. If you have more than one additional partition, add another path to the storage group.

Note that MythTV allows you to create new, named storage groups but then, if you do, you'll have to specify which storage group to use when you make a recording. The Default group, on the other hand, is chosen by default so it is probably the best place to attach your recordings storage.

If you wish to weight the different partitions or directories in a storage group for purposes of giving preference to certain ones over the others (to, for example, include the system disk in a backend's storage group but only use it as a last resort when all of the other space in the storage group is used up), there is limited ability to do this via some undocumented settings, but there is no GUI to set them up.

Myth uses weights to determine which filesystem/directory to record to. The following default values are used:

     SGweightPerRecording  = 10
     SGweightPerPlayback   =  5
     SGweightPerCommFlag   =  5
     SGweightPerTranscode  =  5
     SGweightLocalStarting = -1.99 * SGweightPerRecording
     SGmaxRecOverlapMins   =  3

The physical drive with the lowest weight is used first. In a tie, the physical drive with the highest amount of free disk space is used first.

Each Storage Group directory has its own weight, but Myth is smart enough to know if several directories are on the same shared filesystem. When a weight is applied to a directory that is in use, it is applied to all directories on that filesystem because Myth is trying to spread the load out across filesystems, not directories on the same filesystem.

The starting weight of all physical drives is 0. Local filesystems/directories are then offset by SGweightLocalStarting, so by default they begin at -19 (SGweightPerRecording defaults to 10). This implies that local drives are preferred over remote drives. A local drive has to have an effective weight of 20 before a remote drive will be used to store a new recording. If you do not have any playback going on, this would mean that you'd have to have 2 recordings going to a local drive before a remote drive would get used. If you have 2 local drives and 1 remote drive, you'd have to have 4 recordings going on locally before a remote drive would get used.

If you wish to alter the way Myth decides to use a drive (and, hence, the directory or directories on it), you can do so using the undocumented SGweightPerDir setting. In order to make Myth not use a filesystem/directory, we need to artificially inflate the starting weight for that directory. We can do so by inserting a specific SGweightPerDir setting in the database.

The database key used for the specific SGweightPerDir setting is:

     SGweightPerDir:hostname:directory

The value for hostname is the actual hostname that mounts the directory. So if the directory is actually on server1 but is mounted via NFS on server2 (which is the server running mythbackend), we'd use server2 for hostname. The value for directory is the local path on hostname, so we'd use the mounted directory name (e.g. /mnt/video). For example:

     SGweightPerDir:server2:/mnt/video

The value assigned to this setting will be applied as an offset to the initial weight for this directory. You can play it safe by setting the value to something large like 99 or 100 or even higher. To set a value of 99 for the directory shown in the example above, you would run the following SQL to insert this setting into the settings table:

     insert settings
       (value, data, hostname)
       values("SGweightPerDir:server2:/mnt/video", 99, "server2");

This would pretty much guarantee that the directory would only get used as a directory of last resort, when all other directories filled up.

However, if you'd like to order the way the directories are used up but still have the local directory of last resort be used for recordings before any remote directories, you should pick a number that will result in a calculated weight that is greater than -19 but less than 0. If, for example you chose 15 (assuming that the directory is mounted on a local drive), when the Storage Groups scheduling code runs, /mnt/video will start out with a weight of 0, whereupon it will have an initial offset of -19 added to the 15, specified in the settings table via SGweightPerDir, to arrive at a weight of -4. Other, normal local directories start out at -19 while any remote directories start out at 0. So unless you have a two recordings, or four playbacks, or a recording and two playbacks going on each of your other local drives, the directory or last resort will never be used unless the locals fill up.

Finally, be aware that there is no way to delete a storage group from the GUI, once it is added, nor is they any way to delete a path from any storage group. You can change the name of an existing path but, if you set it to blank, the path will be set to "/" (when the crappy MythTV code adds a "/" to the end of the path). So, it is best to choose your storage groups carefully and add new path names carefully.

However, if you must delete a storage group or path from a storage group, you can connect to the MySQL database and delete it by hand from the storage groups table:

     mysql -uroot -pSecret
     use mythconverg;
     select * from storagegroup;
     delete from storagegroup where groupname='MyGroup';

or

     delete from storagegroup where dirname='/my/store/path';

Secret, Hidden Options

Some of the options that affect the way the Mythbuntu frontend does things are not settable from the User Interface. If you'd like to change its behavior and you can't find out where to do so from the UI, there's always the direct-database-hacking approach. All of the configuration settings for each frontend are stored in the database in the "settings" table. This table has a key for the frontend's hostname. You can see all of the settings for a particular host, in alphabetical order, by doing this (on the master backend):

     mysql -uroot -psecretpassword mythconverg
     select * from settings where hostname='yourhost' order by value asc;

If you want to see all of the settings for a particular setting on all of the frontends (so that you can compare the working ones against the broken ones), you can do this:

     select * from settings where value='ValueName' order by hostname asc;

Settings can be altered by:

     update settings set data='datavalue' where hostname='yourhost'
       and value='ValueName';

Settings can be deleted by:

     delete from settings where hostname='yourhost' and value='ValueName';

When you're done, exit mysql via the "quit" command.

Some settings of particular interest are:

     DisplayGroupDefaultViewMask   n       A bitmask that defines which groups are
                                           to be included in the "Default" group.
                                           Doesn't seem to be any way to get rid
                                           of it from the UI so, if you don't want
                                           the "Default" group to show up in the
                                           recorded list, delete this value.

Adding HDTV Channels Not Detected By MythTV

MythTV is supposed to be able to automagically create a lineup by scanning all of the HDTV channels that are present on your capture card's input but some people have reported that it doesn't do so well with cable lineups (especially from my favorite cable company, Comcast).

If you really think your cable or broadcast lineup should include HDTV channels that MythTV is not detecting, you should see the Wiki entry at:

     http://www.mythtv.org/wiki/Adding_QAM_Channels_For_HDTV_Tuner_Cards

However, running scan (as described in the Wiki) and dealing with its output is not a whole lot of fun and the MythTV auto detect feature has improved considerably since the old days. This being the case, you should probably give it the old college try first, before resorting to using scan. If you still think channels are missing (especially channels that are supposed to be present but are not), you can use scan to find all of the channels present on the capture card's input (note that atscscan, mentioned in a lot of Web posts, is no longer with us so don't bother looking for it) and add them to those found by MythTV.

To begin looking for the missing HDTV channels, you will need to install the utilities in the DVBApps package (if they aren't already there). On Mythbuntu, you can install the package with:

     sudo apt-get install dvb-utils

Make sure that the MythTV backend is not running before you run any of the programs in the DVBApps suite:

     sudo /etc/init.d/mythtv-backend stop

For later versions of Mythbuntu that use upstart, you should use:

     sudo stop mythtv-backend
     sudo ps x -A | grep mythtv

Check the output of the ps/grep to ensure that the backend has indeed stopped running (the stop command doesn't always work). If it has, you're good to go. Otherwise, you may need to cancel a few PIDs by hand.

The install (in DVBApps, above) puts the programs and files in different directories than noted in the Wiki. Run scan as follows:

     /usr/bin/scan /usr/share/dvb/atsc/\
       us-Cable-Standard-center-frequencies-QAM256 >us-Cable-MA-Norwood

If this fails because the scan cannot find the frequency table (on earlier versions of Mythbuntu), you can try looking for it in:

     /usr/share/doc/dvb-utils/examples/scan/atsc/\
       us-Cable-Standard-center-frequencies-QAM256

The scan will take a long time (since it must tune to every frequency that is in the list of standard frequencies) and will produce a list of frequencies that looks something like this:

     [0001]:153000000:QAM_256:2048:2049:1
     [0002]:153000000:QAM_256:1985:1986:2
     [0037]:219000000:QAM_256:1984:1985:55
     [0039]:219000000:QAM_256:2048:2049:57
     [0038]:219000000:QAM_256:2112:2113:56
     [000a]:243012500:QAM_256:0:1985:10
     [000c]:243012500:QAM_256:0:2049:12
     [000b]:243012500:QAM_256:0:2113:11
     [0001]:351012500:QAM_256:0:1985:1
     [0002]:351012500:QAM_256:0:2050:2
     [0002]:369012500:QAM_256:0:1985:2
     [0001]:369012500:QAM_256:0:2049:1
     [0003]:369012500:QAM_256:0:2113:3
     [0004]:369012500:QAM_256:0:2177:4
          .
          .
          .

You now are faced with the task of connecting up the stuff returned by scan to the channel numbers that we know and love. If you are a Comcast customer (you have my sympathies) or you are just interested in the HDTV channels (i.e. not the SD channels that your cable company broadcasts as a replacement for the analog channels that used to be), you should take a look at the scte65scan program:

     http://www.mythtv.org/wiki/Comcast_Users_And_scte65scan

This program can use the PSIP tables, sent over the true HDTV channels, as well as the DTA channel maps (VCTs), sent by Comcast for their el-cheapo digital-to-analog set top boxes (called DTAs), to decode the results produced by running the scan, above. Download the latest copy of this program, unzip it and install it (we put it in /usr/local/bin):

     tar -xvzf scte65scan-0.2.1.tgz
     cd scte65scan-0.2.1
     make
     sudo cp scte65scan /usr/local/bin
     sudo chmod ugo+x /usr/local/bin/scte65scan

Run it as follows:

     /usr/local/bin/scte65scan -p /usr/share/dvb/atsc/\
       us-Cable-Standard-center-frequencies-QAM256 >us-Cable-MA-Norwood.scte

Note that, if you see a message that says something like:

     /dev/dvb/adapter0/frontend0: Device or resource busy

It is probably because the Myth backend is running and it has allocated the DVB adapters. You must also end the backend before you can run this program, which may cramp your style but that's the way it is.

The results should look something like this:

     VCT_ID 3020 (0x0bcc) at 525000000hz, version 10
       VC CD.PROG M# NAME
     ====================
        2   82.1   4 WGBH2
        3   79.9   4 HSN
        4   82.2   4 CBS4
          .
          .
          .
     VCT_ID 3010 (0x0bc2) at 525000000hz, version 10
       VC CD.PROG M# NAME
     ====================
        2   82.1   4 WGBH2
        3   84.1   4 LOCAL01
        4   82.2   4 CBS4
        5   82.3   4 WCVB5
          .
          .
          .
     PSIP channels
        VC    NAME    FREQUENCY   MODULATION PROG
     ============================================
       2.1   WGBH HD  585000000hz QAM_256      1
       2.101 WGBH UP  585000000hz QAM_256      6
       2.102 WGBH UP  585000000hz QAM_256      7
       4.1   WBZ HD   603000000hz QAM_256      2
       5.1   WCVB HD  597000000hz QAM_256      1
       7.1   WHDH HD  597000000hz QAM_256      2
       7.2   WHDH TH  597000000hz QAM_256      3
          .
          .
          .

If you follow the instructions on the wiki, for determining which VCT is your's, you should be able to figure out what all of the virtual analog channels (that Comcast broadcasts as SD channels) are.

The "-p" option will also scan for all PSIP VCTs broadcast by the true HDTV channels. This will help you map the HDTV channels to their appropriate scan frequencies. When you are all done, you should have an annotated frequency map that shows all of the channels that you can receive. We build something that looks like this:

.

       .
  # Freq 79 ->
  [000a]:555000000:QAM_256:0:1985:10      71, QVC SD (Shopping)
  [0009]:555000000:QAM_256:0:2049:9       3, HSN SD (Shopping)
  [0002]:555000000:QAM_256:0:2113:2
  [0007]:555000000:QAM_256:0:2177:7       42, CNN SD
  [000c]:555000000:QAM_256:0:2241:12      43, CNN Headline News (HLN) SD
  [0001]:555000000:QAM_256:0:2305:1       44, CSPAN1 SD
  [0005]:555000000:QAM_256:0:2369:5       55, Spike TV SD
  [0003]:555000000:QAM_256:0:2433:3       63, Animal Planet SD
  [0006]:555000000:QAM_256:0:2497:6       64, TV Land SD
  [0008]:555000000:QAM_256:0:2625:8       65, Golf SD
  [0004]:555000000:QAM_256:0:2561:4       53, Travel SD

# Freq 82 ->
[0001]:573000000:QAM_256:1984:1985:1 202-1, WGBH 2 SD
[0002]:573000000:QAM_256:2048:2049:2 204-1, WBZ 4 SD
[0003]:573000000:QAM_256:2112:2113:3 205-1, WCVB 5 SD
[0004]:573000000:QAM_256:2176:2177:4 207-1, WHDH 7 SD
[0007]:573000000:QAM_256:2240:2241:7 225-1, WFXT 25 SD
[0008]:573000000:QAM_256:2304:2305:8 27-1, WUNI HD
[0009]:573000000:QAM_256:2368:2369:9 238-1, WSBK 38 SD [000a]:573000000:QAM_256:2432:2433:10 44-1, WGBX HD [000b]:573000000:QAM_256:2496:2497:11 50-1, WZMY HD [000c]:573000000:QAM_256:2560:2561:12 256-1, WLVI 56 SD

  [007e]:573000000:QAM_256:2624:0:126     3001, DTA_CDL

# Freq 83 ->
[0001]:579000000:QAM_256:1984:1985:1 268-1, WBPX 68 SD
[0003]:579000000:QAM_256:2048:2049:3 10-1, WJAR HD
[0005]:579000000:QAM_256:2112:2113:5 62-1, WMFP HD [000a]:579000000:QAM_256:2176:2177:10 66-1, WUTF HD [000b]:579000000:QAM_256:2240:2241:11 48-1, WYDN HD [0006]:579000000:QAM_256:2304:2305:6 236-1, WSBE 36 SD
[0004]:579000000:QAM_256:2368:2369:4
[000c]:579000000:QAM_256:2432:2433:12 46-1, WWDP HD [0008]:579000000:QAM_256:2496:2497:8 60-1, WNEU HD [0002]:579000000:QAM_256:2560:2562:2 47, Weather SD [0007]:579000000:QAM_256:2624:2625:7 83, Inspiration SD (Religious)

       .
       .
       .

Note that, if you have a regular HDTV television set that is capable of scanning and adding available channels to its internal lineup, you can scan all of the channels being broadcast by your cable provider or over the air and get a good feel for what is "out there". Most television channels display their logo on the screen at all times, now days, so you can just surf through the channels that your TV set finds and see what they are. This may be especially useful for the SD channels that don't use the PSIP VCTs. Doing this can help you decide which DTA VCT is applicable in your area. In most cases, the TV set will simply use the real channel and program number for the displayed channel number, if there is no PSIP VCT (e.g. 84-12). Thus, the displayed channel number can be used to look up the actual frequency, and from thence the actual program within that frequency, directly.

Using all of this information, you can build a set of updates that can be fed into MythTV. If you are able to use scte65scan, the following command will get you started (use the actual VCT ID in place of "nnnn"):

     /usr/local/bin/scte65scan -p -V nnnn -f 3 /usr/share/dvb/atsc/
       us-Cable-Standard-center-frequencies-QAM256 >Update-Cable-MA-Norwood.sql

You can feed the SQL file that is produced by scte65scan directly into MythTV but we prefer to manually inspect and adjust them before letting MySQL rip on them. There are too many ways this step can go wrong so checking to make sure that everything is on the up and up is wise.

Verify that the deletes are deleting the correct lines from the dtv_multiplex and channel tables. The deletes are by sourceid but you can use a range of mplexids (for the dtv_multiplex table) or chanids (for the channel table). To see what's there, try:

     select * from dtv_multiplex where sourceid=1 order by mplexid asc;
     select * from channel where sourceid=1 order by chanid asc;

You can replace "1" with 2 or 3 or 4, depending on which input source you are working with.

If you used scte65scan as a starting point, inspect the portion of the channel table insert lines that look like this, very carefully:

     mplexid=(SELECT mplexid from dtv_multiplex where frequency=585000000)

It is possible that the frequency that scte65scan uses in the dtv_multiplex table will be different than the frequency that it detects later on when it does the actual scan and proceeds to build the channel table. This will result in the insert failing to find the proper mplexid and the channel table being borked. We prefer to supply the actual mplexid by hand, like this:

     insert into channel set chanid=1021, channum='2_1', freqid=115, sourceid=1,
       callsign='WGBH-HD', name='WGBH HD', serviceid=1, mplexid=115, ...

And, note that scte65scan fails to set the atsc_major_chan and atsc_minor_chan fields when it updates the channel section. This is a mixed blessing (see the Fixing Formerly Working/Now Broken HDTV Channels section) but, suffice to say, if you want to receive the on-air-guide via the transmitted EIT data, you need to set them manually. You also need to set the useonairguide flag.

Alternately, if you will be loading your own guide data (see Making Up Guide Data) or using one of the XMLTV grabbers to obtain guide data, you will need to set the xmltvid field to the channel identifier that matches the second display-name that the XMLTV data uses for each channel. Typically, this is the channel number or call sign but you may want to inspect the XMLTV data first to determine what to use.

Finally, you can mark those channels that you don't want to see with the visible flag (it is set on, by default). But, bear in mind that the useonairguide flag should still be set for invisible channels, if you plan to use the transmitted EIT data (see Getting EIT To Work) for any of the channels included in the ones broadcast under the chosen mplexid.

Your updates should look something like this:

     -- WARNING: The following line clears out the us-cable frequencies in the
     --          dtv_multiplex table
     delete from dtv_multiplex where sourceid=1;
     -- Add the frequency table from SCTE-65 CDS
     insert into dtv_multiplex set sistandard='atsc', mplexid=1,
       frequency=75250000, modulation='qam_256', sourceid=1;
     insert into dtv_multiplex set sistandard='atsc', mplexid=2,
       frequency=57000000, modulation='qam_256', sourceid=1;
     insert into dtv_multiplex set sistandard='atsc', mplexid=3,
       frequency=63000000, modulation='qam_256', sourceid=1;
          .
          .
          .
     insert into dtv_multiplex set sistandard='atsc', mplexid=118,
       frequency=759000000, modulation='qam_64', sourceid=1;
          .
          .
          .
     -- WARNING: The following line clears out the HD and SD channels in the
     --          channel table
     delete from channel where sourceid=1;
     -- Add the HD channels from the PSIP section
     insert into channel set chanid=1021, channum='2_1', freqid=115, sourceid=1,
       callsign='WGBH-HD', name='WGBH HD (PBS, Boston)', serviceid=1, mplexid=115,
       useonairguide=1, atsc_major_chan=2, atsc_minor_chan=1;
     insert into channel set chanid=1041, channum='4_1', freqid=114, sourceid=1,
       callsign='WBZ-HD', name='WBZ HD (CBS)', serviceid=2, mplexid=114,
       useonairguide=1, atsc_major_chan=4, atsc_minor_chan=1;
     insert into channel set chanid=1051, channum='5_1', freqid=113, sourceid=1,
       callsign='WCVB-HD', name='WCVB HD (ABC)', serviceid=1, mplexid=113,
       useonairguide=1, atsc_major_chan=5, atsc_minor_chan=1;
          .
          .
          .
     insert into channel set chanid=1661, channum='66_1', freqid=83, sourceid=1,
       callsign='WUTF-HD', name='WUTF HD (Telefutura)', serviceid=10, mplexid=83,
       visible=0, useonairguide=1, atsc_major_chan=66, atsc_minor_chan=1;
          .
          .
          .
     -- Add the SD channels from VCT_ID 3020 (0x0bcc) at 525000000hz, version 28
     insert into channel set mplexid=87, serviceid=9, freqid=3, chanid=2003,
       sourceid=1, channum='3_9', callsign='HSN-SD', name='HSN SD (Shopping)',
       visible=0;
     insert into channel set mplexid=89, serviceid=6, freqid=6, chanid=2006,
       sourceid=1, channum='6_9', callsign='NECN-SD', name='NECN SD (News)';
          .
          .
          .
     -- WARNING: The following line clears out the us-bcast frequencies in the
     --          dtv_multiplex table
     delete from dtv_multiplex where sourceid=2;
     -- Add the frequency table for US Broadcast
     insert into dtv_multiplex set mplexid=159, sourceid=2, transportid=\N,
       networkid=\N, frequency=195000000, inversion='0', symbolrate=0,
       fec='auto', polarity='v', modulation='8vsb', bandwidth='a',
       lp_code_rate='auto', transmission_mode='a', guard_interval='auto',
       visible=0, constellation='8vsb', hierarchy='a', hp_code_rate='auto',
       sistandard='atsc', serviceversion=33,
       updatetimestamp='2010-03-15 16:13:59';
     insert into dtv_multiplex set mplexid=160, sourceid=2, transportid=\N,
       networkid=\N, frequency=207000000, inversion='a', symbolrate=0,
       fec='auto', polarity='v', modulation='8vsb', bandwidth='a',
       lp_code_rate='auto', transmission_mode='a', guard_interval='auto',
       visible=0, constellation='8vsb', hierarchy='a', hp_code_rate='auto',
       sistandard='atsc', serviceversion=33,
       updatetimestamp='2010-03-15 16:13:59';
          .
          .
          .
     -- WARNING: The following line clears out the HD Over The Air channels in the
     --          channel table
     delete from channel where sourceid=2;
     -- Add the HD OTA channels broadcast locally
     insert into channel set chanid=9021, channum='902_1', freqid=19, sourceid=2,
       callsign='WGBH-DT', name='WGBH HD (PBS, Boston)', icon='', finetune=\N,
       videofilters='', xmltvid='', recpriority=0, contrast=32768,
       brightness=32768, colour=32768, hue=32768, tvformat='ATSC',
       commfree=0, visible=1, outputfilters='', useonairguide=1,
       mplexid=163, serviceid=3, atscsrcid=\N, tmoffset=0,
       atsc_major_chan=2, atsc_minor_chan=1, last_record='0000-00-00 00:00:00',
       default_authority='', commmethod=-1;
     insert into channel set chanid=9041, channum='904_1', freqid=30, sourceid=2,
       callsign='WBZ-DT', name='WBZ HD (CBS)', icon='', finetune=\N,
       videofilters='', xmltvid='', recpriority=0, contrast=32768,
       brightness=32768, colour=32768, hue=32768, tvformat='ATSC',
       commfree=0, visible=1, outputfilters='', useonairguide=1,
       mplexid=166, serviceid=1, atscsrcid=\N, tmoffset=0,
       atsc_major_chan=4, atsc_minor_chan=1, last_record='0000-00-00 00:00:00',
       default_authority='', commmethod=-1;
          .
          .
          .
     -- WARNING: The following line clears out the analog channels in the
     --          channel table
     delete from channel where sourceid=3;
     -- Add the only real analog channels from the PSIP section
     insert into channel set chanid=3002, channum='2', freqid=2, sourceid=3,
       xmltvid='', callsign='WGBH', name='WGBH-2 (PBS, Boston)';
     insert into channel set chanid=3003, channum='3', freqid=3, sourceid=3,
       xmltvid='', callsign='HSN', name='HSN (Shopping)', visible=0;
          .
          .
          .
     -- Add the analog virtual channels from the PSIP section
     insert into channel set chanid=3023, channum='23', freqid=23, sourceid=3,
       xmltvid='', callsign='DAYSTAR', name='Daystar (Religious)', visible=0;
     insert into channel set chanid=3024, channum='24', freqid=24, sourceid=3,
       xmltvid='', callsign='DISNEY', name='Disney';
          .
          .
          .

Again, to reiterate some of the previously made points and note a few more tips, in the dtv_multiplex section, make sure that the source ID is correct for the source that you've defined for digital reception. Dumping the existing dtv_multiplex table ahead of time (as shown above) and inspecting it can help you with this choice.

Check all of the frequencies, in the dtv_multiplex section, against the actual values in your annotated frequency map or the file output by scan. Be careful that the frequency that you set is correct, since this is the number that will be used to actually tune the encoder. At the same time, pay attention to the modulation setting. Most cable multiplex frequencies will use QAM-256 but occasionally one will use QAM-64 or something else. Over the air broadcasts will be 8VSB.

In the channel section, don't delete existing channel IDs, if possible, just update them with the correct info. This will keep all of the existing recordings and upcoming recordings copacetic. You can change the serviceid and mplexid of existing channels with impunity, since this information is only used to record the next recording. Changing the callsign of any channel should be done carefully (see How MythTV Chooses Which Input To Record), only after considering the repurcussions on the upcoming recordings.

Again, in the channel section, watch out for the wording that says "mplexid=(select mplexid from dtv_multiplex where frequency=nnnnnnnnn)". If the frequency used in the select doesn't match the one in the dtv_multiplex, you will end up with a bogus mplexid and the encoder won't be able to tune to the channel.

For digital channels that have channel numbers like "n_n", always use the same separator as the other defined channels and be sure that it is the one that MythTV is using. Myth actually separates channel numbers using this separator and sorts them into two columns. If you don't stick with the convention, your channels will be sorted in incorrect order.

Be aware that you can have two channels with the same number (especially if one is analog and one is digital) but you probably won't be happy with the consequences. For example, despite the fact that you're viewing TV using a digitial encoder, and you've defined a digital channel 12, entering 12 on your remote, to change to that digital channel, may result in MythTV switching to an analog encoder and showing you analog channel 12 instead. Worse yet, recordings may end up on the wrong encoder (see How MythTV Chooses Which Input To Record).

Consequently, for digital channels that mirror virtual analog channels, it is much better to append a second component to the channel number (or move them to a higher range, such as 2nn), thereby keeping them unique. We like to append "_9" to preserve the sort order with the regular channels. Note that you can use anything you like but, if you don't use numerics and you don't use the proper separator, MythTV will sort your channels in odd order.

Once you've built your channel definitions file, you can feed it in to MySQL with this command:

     source /path/to/file/MyLineup.sql

After you'd done so, always check the upcoming recordings list. Despite the fact that your channel lineup should be fine, after you update it, MythTV can get confused and show upcoming recordings as "not listed". Usually, you can fix this problem by modifying the recording (you don't actually have to modify anything) and re-saving it. However, you may have to delete and re-add any truly broken ones.

Fixing Formerly Working/Now Broken HDTV Channels

This section could be subtitled, "Keeping Up With Those Butt-Heads at Comcast".

HDTV channels can have a whole bunch of sub-channels (called programs), all under the one multiplex frequency. This allows the broadcaster or, in the case of your favorite bunch of clowns at the cable company, the marketing guys, to assign content to whatever sub-channel they like. If they're being nice, they'll keep the lineup the same and everything will work fine. If they're being butt-heads, they'll periodically move things around and stuff will break.

Luckily, the MythTV guys thought of all this. Ha, ha, ha, haaaa! Fooled you. You actually believed that? What a schmuck. Here's what really happens.

The idiots at the broadcaster/cable company change something in the channel lineup (e.g. the ATSC major channel and minor channel numbers change for one of the channels that you normally record in slot 1 of channel 84 -- channel 2_2 moves to 2_1, as it recently did on Comcast). MythTV keeps recording shows on the channel with nary a wimper. However! The recording file that the database points to never actually gets created and there's no actual recording. Nice, huh? If you look in /var/log/mythtv/mythbackend.log for the date/time of the recording, you'll see thousands of entries saying:

     Could not find channel 2_2 in CVCT

What this really means is that MythTV went and looked up the channel information in the dtv_multiplex table and tuned to the channel/sub-channel specified. Since it got a lock, it was all set to start recording. Then, just as a precaution, MythTV decided to check that the ATSC major/minor channel numbers, as specified in the Cable Virtual Channel Table [ATSC Syntax] (CVCT) (see www.etherguidesystems.com/Help/SDOs/ATSC/Syntax/TableSections/CVCT.aspx) matched what was set in the channel table. They didn't so it simply dumped the recording in the bit-bucket, with no warning to the user.

The clue as to how to fix this problem is found right in the log at the same place as the first error message. You will see a listing of the channels that are described in the CVCT immediately following. They look like:

     VCT Cable: channels(4) tsid(0x807c) seclength(259)
     Channel #0 name(WLVI HD) 56-1 mod(SCTE mode 2) cTSID(0x807c)
      pnum(2) ETM_loc(0) access_ctrl(0) hidden(0)
     path_select(0) out_of_band(0) hide_guide(0) service_type(2) source_id(1)
      descriptors length(27) count(1)
       ExtendedChannelNameDescriptor: 'WLVI HD (PRIMARY)'
     Channel #1 name(WGBH HD) 2-1 mod(SCTE mode 2) cTSID(0x807c)
      pnum(1) ETM_loc(0) access_ctrl(0) hidden(0)
     path_select(0) out_of_band(0) hide_guide(0) service_type(2) source_id(6)
      descriptors length(27) count(1)
       ExtendedChannelNameDescriptor: 'WGBH HD (PRIMARY)'
     Channel #2 name(WGBH UP) 2-101 mod(SCTE mode 2) cTSID(0x807c)
      pnum(6) ETM_loc(0) access_ctrl(0) hidden(0)
     path_select(0) out_of_band(0) hide_guide(0) service_type(4) source_id(7)
      descriptors length(32) count(1)
       ExtendedChannelNameDescriptor: 'WGBH UPDATE0 (PRIMARY)'
     Channel #3 name(WGBH UP) 2-102 mod(SCTE mode 2) cTSID(0x807c)
      pnum(7) ETM_loc(0) access_ctrl(0) hidden(0)
     path_select(0) out_of_band(0) hide_guide(0) service_type(4) source_id(8)
      descriptors length(32) count(1)
       ExtendedChannelNameDescriptor: 'WGBH UPDATE1 (PRIMARY)'

In this case, what was channel 2_2 has been updated to 2_1, as can be seen from "name(WGBH HD) 2-1". The entry for channel 2_2 in the channel table must be updated to match the ATSC major number (2, in this case) and ATSC minor number (1, in this case). You can do this with the following SQL command:

     update channel set atsc_major_chan=2, atsc_minor_chan=1 where chanid=1022;

Another fix that appears to work is to set both the ATSC major and ATSC minor numbers to zero, thereby telling MythTV not to check the channel when it tunes to it. This can be done with:

     update channel set atsc_major_chan=0, atsc_minor_chan=0 where chanid=1022;

Its your call, whether you want MythTV to record nothing at all or whether you just want it to record the wrong content (or maybe its the right content, just the wrong name). But, to throw another variable into the mix, if you set the ATSC major and ATSC minor numbers to zero, you won't be able to use the on air guide that is sent in the EIT (see Getting EIT To Work). So, probably the best bet is to set ATSC major and ATSC minor numbers to the proper values and keep your eye out for recordings that disappear in the night.

You will, of course, need to figure out what the correct chanid is in order to do this update. This SQL query should help:

     select * from channel where freqid=84;

Replace 84 with the frequency ID you are trying to fix and then inspect the resultant listing to find the broken channel. The chanid column is the unique key that you can use for the update. Incidentally, this assumes that whoever or whatever built the channel table put the correct frequency number into each entry. If this isn't the case, you may have to work backwards from first principals. First, begin by selecting the correct dtv_multiplex entry:

     select * from dtv_multiplex where sourceid=1 and frequency=585000000;

Replace "1" with the actual sourceid for the input source in question and "585000000" with the center frequency of the channel that is broken. Using the resultant mplexid, select the channel information:

     select * from channel where mplexid=184;

Note that other possibilities for "broken" include the wrong slot number being chosen in the channel as well as the wrong frequency being used to tune the channel (this is Scenario 2 in the Comcast playbook, where they change the entire lineup, unannounced, the premise being that everybody is watching via a settop box anyway so it makes no nevermind where we move things and when).

Using /usr/bin/scan, as described in the "Adding HDTV Channels Not Detected By MythTV" section, will give you a listing of all the frequencies that can be tuned on your input connections. The mplexid field of the channel entry should point to the proper frequency in the dtv_multiplex table. If it doesn't change it to match the mplexid from that table that has the correct frequency:

     update channel set mplexid=7 where chanid=1022;

Update the serviceid field to choose the correct slot, as given by the path number value (e.g. "pnum(1)") in the /var/log/mythtv/mythbackend.log file:

     update channel set serviceid=1 where chanid=1022;

Once you have the channel recording properly again, you may want to change its actual name (e.g. "2_2" changes to "2_1"). You can do this from the channel editor in the MythTV Backend setup program, which is accessed from the System portion of the Gnome Main Menu or you can use this SQL command:

     update channel set channum='2_1' where chanid=1022;

One word of caution. Do NOT, I repeat, DO NOT leave any encoder on any system connected to the master backend, whose database you're updating, tuned to the old channel name. If you do, when you change the channel name, everything will hang, including recordings, watching live TV and the master backend itself. The only way out of this fiasco is to go to the machine that actually has the encoder installed in it, run the MythTV Backend setup program, choose Input setup, pick the encoder in question and set its default channel to something else, although, sometimes, you can put the channel number back the way it was, then cycle thru all of the encoders and set them to something else, then re-set the channel number to what you wanted it to be. But, its much easier to not get in this bind in the first place, by setting each encoder to a legit channel before you make the changes.

How MythTV Chooses Which Input To Record

The subtitle of this section could be "Setting Up A Backup Input Source". If you are like us, happy customers of Comcast, you might want to set up a backup input source to record from, when your service provider arbitrarily porks your lineup or otherwise drops the signal on the ground, during the middle of your favorite program.

For example, a spare encoder hooked up to that Radio Shack flying saucer up in the atic can provide an alternate source of program material. Since all terrestrial broadcasts (in the US, at least) are HDTV, there's no compromise in picture quality, providing the signal is acceptable. No reason not to record from such a source, especially as a back-em-up.

Making backup recordings requires that you understand how MythTV schedules recordings. Essentially, the scheduler is interested in recording a call sign, not a channel from a particular source. Normally, this works in your favor, since the scheduler will decide which input source to record from, based on what call signs it has available. If you ask for a recording of Ken Burn's latest magnum opus and there are three encoders that provide WGBH, the scheduler will pick whichever one it finds free at the time. It makes no difference that one is a HD encoder tuned to channel 2_1, the second is an analog encoder tuned to channel 2 via a settop box and the third is another HD encoder tuned to the SD rebroadcast of the HD channel used by your service provider to feed their el-cheapo settop boxes.

However, if you'd actually like to tell the scheduler which input to use, you need to think differently. Let's say that you'd like to make one recording of a program using channel 6 (which is an analog channel that is fed from a settop box that converts a SD channel) and another recording of the same program using channel 6_9 (which is the actual SD channel). Why would you want to do this, you ask? Well, the recording of the program using channel 6 is probably guaranteed to work, even if your friends at the cable company change the lineup on the fly, since the settop box will be reprogramed by them, at the same time, thereby handling the lineup change automatically. However, the SD broadcast is probably a better candidate for recording, since its quality will be better and the resultant file may be smaller (the compression used by the broadcaster is usually more efficient than the compression that the encoder card's MPEG encoder makes up, on the fly). You'd like to make two recordings so that you can view the best one but be assured that you'll at least have something to watch.

Alternately, if your plan is to back up your cable feed with recordings from a terrestrial antenna, you'll once again need to convince the scheduler to make one recording from Encoder A and a second recording from Encoder B. Normally, it is not inclinded to make two recordings of the same program from two different sources.

The clue to making the scheduler do what you want is to convince it that it is dealing with different call signs. If every channel on every input has a unique call sign, you can do this. So, for example, you might define the following lineup:

     WGBH      2       Analog channel on settop box
     WGBH-HD   2_1     HDTV channel in the clear from cable feed
     WGBH-SD   2_9     SD rebroadcast of HDTV channel for el-cheapo settop boxes
     WGBH-DT   902_1   HDTV channel from terrestrial antenna

Note that, not only are all the channel numbers unique (note that you can use any channel numbers you like but, if you don't use numerics and you don't use the proper separator, MythTV will sort your channels in odd order) but the call signs are unique too.

This means that you can now ask the scheduler to schedule one recording of Program X from WGBH-HD and a second, backup from WGBH-DT. The first recording will be made using an encoder that is attached to the cable feed and the second will be made using an encoder that is attached to the terrestrial antenna.

The flip side is that you can force the scheduler to choose from any of the available inputs, regardless of what kind they are, by giving the channels on their sources the same, identical call signs. You may elect to go this route if you're using legacy equipment and haven't upgraded all of your encoders to the top of the line (i.e. HDTV), etc. But, be advised that the scheduler may pick what you'd consider to be the wrong input, all things being equal, so you may want to weight the encoders with different priorities so that it uses them in your preferred order.

Also, be warned that, should you give identical call signs to the channels on a given input as those used on another input, and then later change your mind and assign different call signs, your upcoming recordings list may well be royally screwed. Because the scheduler will have assigned the work to do based on the call sign (which is now different), you may have to delete an reschedule recordings to get them assigned to the correct call sign/channel/input. It is best to ponder everything carefully ahead of time and do it right the first time.

Getting EIT To Work

There is quite a bit of mythology in the various wikis and blogs about what it takes to get over-the-air guide data working, using the EIT information. Most of them state that the only way is to allow MythTV to scan for channels on the input source and let it build the dtv_multiplex and channel tables. For example:

     http://ubuntuforums.org/showthread.php?t=1410407

We can categorically state that this isn't true. We've built channel lineups entirely from scratch, including setting up the dtv_multiplex table and the channel table with information made up from a scan by a television set. Follow these notes and you can do it too.

In North America, the most important information, from the EIT scan point of view, is the ATSC major and minor channel numbers. The atsc_major_chan and atsc_minor_chan fields must be set in the channel table or EIT scan will not work. This is because the data in the EIT must be matched back up to the channel it belongs to, so that it can be incorporated into the guide data, and this is where these two fields come in. That's swell because the tables we've seen generated by scte65scan don't have those fields set. And, apparently, importing a channels.conf file from scan fails to set these fields. So, EIT no workee.

Meanwhile, in Europe, the above statement about needing some way to convert the information in the EIT into a channel ID that MythTV can use to store the data is still relevant. Only, for Europe, the channel ID is looked up using serviceid, networkid and transportid. So, if those fields are not set in your database you're going nowhere fast.

Another thing to consider is that EIT scan only scans the first sub-channel (called a program or service) that is mapped to the multiplex frequency. For true over-the-air channels, this isn't usually a problem, since each multiplex frequency contains only the programs from a single broadcaster and the lowest sub-channel is almost always a real channel that you're interested in. But, for HDTV channels, transmitted by your favorite cable provider, you may find more than one real channel under a single multiplex frequency. For example, in our neck of the woods, Comcast is currently broadcasting the following on one multiplex frequency:

     WCVB HD   5_1     serviceid=1
     WHDH HD   7_1     serviceid=2
     This TV   7_2     serviceid=3

This means that, if we want to see EIT data from channel 7_1, we have to turn it on for channel 5_1 (hey, that's intuitive). Even more intuitive is the fact that EIT may need to be turned on for all of the sub-channels in the multiplex frequency for it to be used by any of them. But, knowing this, we can now construct a set of channel entries for our example:

     insert into channel set chanid=1051, channum='5_1', freqid=113, sourceid=1,
       callsign='WCVB-HD', name='WCVB HD (ABC)', serviceid=1, mplexid=113,
       useonairguide=1, atsc_major_chan=5, atsc_minor_chan=1;
     insert into channel set chanid=1071, channum='7_1', freqid=113, sourceid=1,
       callsign='WHDH-HD', name='WHDH HD (NBC, Boston)', serviceid=2, mplexid=113,
       useonairguide=1, atsc_major_chan=7, atsc_minor_chan=1;
     insert into channel set chanid=1072, channum='7_2', freqid=113, sourceid=1,
       callsign='This', name='WHDH This TV', serviceid=3, mplexid=113,
       useonairguide=1, atsc_major_chan=7, atsc_minor_chan=2;

Pay attention to the fact that the atsc_major_chan and atsc_minor_chan fields (or, in Europe, that the, serviceid, networkid and transportid fields), along with the useonairguide field are set. Even if the visible field is set to zero, the useonairguide field should be set on.

There is nothing unusual that needs to be done for the dtv_multiplex table except that the multiplex ID must be set in the mplexid field. Mind you, without this field being set, you won't be looking at any picture or hearing any sound so this is a no-brainer.

The next thing to do is make sure that active EIT scan is turned on for each of the DVB cards that you want to use for active EIT scanning (you could just allow passive scanning but this means that you actually have to view each of the channels before its guide data will show up). You'll want to have at least one card that is mapped to each input source but you can have more since the scan knows how to effectively use multiple cards. You can do this from the Capture Card section of the Myth Backend configuration application or you could try something like this:

     update capturecard set dvb_eitscan=1 where cardtype='DVB';

Finally, you need to turn on EIT scanning for the input source in question. You can do this from the Input Sources section of the Myth Backend configuration application, at the same time you turn on active EIT scan, or you could try something like this:

     update videosource set xmltvgrabber='eitonly', useeit=1 where sourceid=1;

You may need to recycle the backend on each of the machines that actually have the capture cards that will do the EIT scanning installed, although launching the Myth Backend configuration application takes care of this for you.

Note that, if over-the-air guide data via EIT still doesn't work, once you've done all this, you should enter the following SQL command:

     select channum, min(chanid), mplexid
       from channel, cardinput, capturecard, videosource
       where cardinput.sourceid=channel.sourceid
         and videosource.sourceid=channel.sourceid
         and capturecard.cardid=cardinput.cardid
         and channel.mplexid is not null and useonairguide=1 and useeit=1
         and channum!='' and cardinput.cardid=1
       group by mplexid
       order by cardinput.sourceid, mplexid, atsc_major_chan, atsc_minor_chan;

Change the cardid value from "1" to the actual card number of the capture card that's to do the EIT scanning. You should see a table that looks something like this:

     +---------+-------------+---------+
     | channum | min(chanid) | mplexid |
     +---------+-------------+---------+
     | 27_1    |        1271 |      82 |
     | 10_1    |        1101 |      83 |
     | 68_1    |        1361 |      99 |
     | 7_2     |        1051 |     113 |
     | 25_1    |        1041 |     114 |
     | 2_1     |        1021 |     115 |
     | 38_1    |        1381 |     116 |
     +---------+-------------+---------+

If you don't you've messed something up. Keep checking things until such a listing appears. Then, check the channel table entries for each of the channel IDs shown. They, at least, must have their ATSC major and minor numbers set (or, in Europe, their service ID, network ID and transport ID values set). But, it wouldn't hurt to set the ATSC major and minor numbers for all of the channels that have the same multiplex ID as those listed.

If you're still having problems and you can figure out what channels you want ATSC EIT data for, the returned EIT data must match this select:

     select chanid, useonairguide from channel
       where atsc_major_chan=xx and atsc_minor_chan=yy
         and sourceid=1;

Where xx and yy are the ATSC major and minor numbers and 1 is the source number (typically 1). If the select doesn't find anything, your EIT data won't get stored.

Alternately, if you're in Europe and you're still having trouble with DVB-T, for instance, the returned EIT data must match this select:

     select chanid, useonairguide from channel, dtv_multiplex
       where serviceid=xx and networkid=yy and transportid=zz
         and channel.mplexid=dtv_multiplex.mplexid;

Where xx, yy and zz are the service ID, network ID and transport ID. Again, if the select doesn't find anything, no EIT data for you.

Also note that the scan optionally adds this to the where clause, if the sourceid is set:

     and channel.sourceid=1

Where 1 is the source number (typically 1).

Either way, Europe or North America, there doesn't seem to be much magic involved. You can take a look at the applicable code in eitscanner.cpp and eithelper.cpp (both in libs/libmythtv) if you still can't get it to work but it looks fairly straightforward. There is some special case stuff, supposedly for special EIT data from the German provider Premiere for the optional channels Premiere Sport and Premiere Direkt, but other than that, it looks like: read the EIT data; resolve the channel number; parse the data; stuff the data in the database.

One final note. Your friends at your favorite cable company may strip the over-the-air guide data from your local HDTV channels. This is definitely the case with Comcast in our area, for example. Whereas the EIT data from a terrestrial broadcast of WCVB includes program names, episode titles and extensive episode descriptions for the next 18-20 hours, the EIT data from WCVB on Comcast cable only includes the program names, and only for the next 8-10 hours. Not that it matters from the scheduler's point of view, mind you, since guide data changes due to EIT scanning are reflected immediately but you will be missing the extended program information such as episode titles and descriptions.

Making Up Guide Data

Guide data is loaded into the MythTV database by a program called mythfilldatabase. This program expects that the guide data will be in a format specified by the XMLTV standard, a description of which is found here:

     http://xmltv.cvs.sourceforge.net/checkout/xmltv/xmltv/xmltv.dtd

Additional descriptive information can be found in the XMLTV wiki here:

     http://wiki.xmltv.org/index.php/XMLTVFormat

The program that obtains guide data (from whichever source is appropriate) is called a grabber in XMLTV parlance. For many countries, a grabber has already been written and is included in the XMLTV package. Check the MythTV wiki for a list of what's available:

     http://www.mythtv.org/wiki/XMLTV

If there is no grabber available for your country or your goal is simply to create your own guide data (for whatever reasons), from some source of your own, you'll need to generate XMLTV files containing the data, probably on a daily basis. You can use a support module from the Perl XMLTV package, if you're inclined to write your code in Perl, to generate guide data files in the correct format, which can be fed into mythfilldatabase.

Begin by downloading the latest version of the complete XMLTV package from sourceforge:

     http://sourceforge.net/projects/xmltv/files/

Unzip the distribution file:

     tar -xvjf xmltv-0.5.56.tar.bz2

Now, generate the package's makefile, like so:

     cd xmltv-0.5.56
     perl Makefile.PL

This will ask you a lot of questions about which optional components and grabbers you want. Answer no to all of them. All we really want is the XMLTV.pm module itself, so that we can use it to write XMLTV files.

If need be, install any missing prerequisites (but not any of the optional modules). For example, install Slurp and the XML writer like this:

     perl -MCPAN -e shell
     install File::Slurp
     install XML::Writer

Once you've installed any missing prerequisites, you can build XMLTV:

     make

Then, find the XMLTV.pm module in the lib directory and copy it somewhere that Perl programs can find it. For example:

     su
     cp lib/XMLTV.pm /usr/lib/perl5/site_perl/5.8.8

When you build your guide data, make sure to generate channel data that looks like this:

     <channel id="nn">
       <display-name>CALLSIGN</display-name>
       <display-name>nn</display-name>
     </channel>

The "CALLSIGN" value is whatever call sign is used for that channel (e.g. "WGBH"). This is typically not the name used to display the channel by MythTV but, rather, the official call letters for an over-the-air broadcaster or short name for a cable broadcaster. The important thing is that "nn", the actual channel number that is used by MythTV in the channel's xmltvid field of the channel table (see below), is the second display name. It is imperative that every channel that is described in the XMLTV data has a second display name that matches the xmltvid field of some channel in the channel table or mythfilldatabase will make a channel up, which could have quite unpleasant results.

This Perl code should work to generate the correct XML:

     @ChanList = ();
     push(@ChanList, [$CallSign]);
     push @ChanList, [$Channel];
     $XMLTVHand->write_channel({
       id => $Channel,
       "display-name" => \@ChanList });

Program detail slots are generated for each channel. Each slot gives the start and stop time for the program, as well as the channel it is broadcast on:

     <programme start="yyyymmddhhmmss" stop="yyyymmddhhmmss" channel="nn">
       <title lang="en">The National Parks: America's Best Idea</title>
       <sub-title lang="en">The Scripture of Nature (1851-1890)</sub-title>
       <episode-num system="xmltv_ns">.1.</episode-num>
     </programme>

When you generate your program data, forget about the timezone offset on the start and stop stamps and the story about GMT in the XMLTV DTD. Its local time all the way, no matter what you do. Also, be aware that "nn" must match the previously-written channel entry. Here is some sample Perl that should do the trick:

     %Program = ();
     $Program{channel} = $Channel;
     ($Sec, $Min, $Hour, $MDay, $Mon, $Year) = localtime($StartTime);
     $Program{start} = sprintf("%04d%02d%02d%02d%02d%02d",
       1900+$Year, 1+$Mon, $MDay, $Hour, $Min, $Sec);
     ($Sec, $Min, $Hour, $MDay, $Mon, $Year) = localtime($SlotStamp+1);
       $Program{stop} = sprintf("%04d%02d%02d%02d%02d%02d",
     1900+$Year, 1+$Mon, $MDay, $Hour, $Min, $Sec);
     $Program{"episode-num"} = [[sprintf(".%d.", $EpisodeNum), "xmltv_ns"]];
     $Program->{title} = [["en", "The National Parks: America's Best Idea"]];
     $Program->{"sub-title"} = [["en", "The Scripture of Nature (1851-1890)"]];

You'll probably want to set episode numbers with code like this:

     $Program{"episode-num"} = [[sprintf(".%d.", $EpiNum), "xmltv_ns"]];

You can read the story about the episode numbering scheme employed by XMLTV in the DTD but, essentially, you just want to set the middle component of the episode number to the actual, sequential episode number, which you do by generating a number like ".11.".

If you have them available, run times for programs or movies need to be converted into seconds. Normally, run times are the actual time of the program, without commercials (e.g. for a movie, it would be the running time in the movie theatre or on the DVD). You can add them with code like this:

     $Program{length} = $RunTime * 60;

The genre groups that MythTV uses are the common ones such as "news", "sports", "comedy" and "drama". If you had, for example, a set of simple genre tags you might use some code like this, inside of a loop, to convert them to genres that MythTV can use, in the XMLTV file:

     @GenreGroups = ();
     foreach $ProgType (@ProgTypes)
         {
         if ($ProgType eq "com") { push(@GenreGroups, ["comedy", "en"]); }
         elsif ($ProgType eq "dra") { push(@GenreGroups, ["drama", "en"]); }
         elsif ($ProgType eq "kid") { push(@GenreGroups, ["children", "en"]); }
         elsif ($ProgType eq "mov") { push(@GenreGroups, ["movie", "en"]); }
         elsif ($ProgType eq "new") { push(@GenreGroups, ["news", "en"]); }
         elsif ($ProgType eq "sci")
             { push(@GenreGroups, ["science fiction", "en"]); }
         elsif ($ProgType eq "sop") { push(@GenreGroups, ["daytime", "en"]); }
         elsif ($ProgType eq "spo") { push(@GenreGroups, ["sports", "en"]); }
         }
     if (scalar(@GenreGroups) > 0) { $Program{category} = [@GenreGroups]; }

For data that repeats, such as crew members, you can push the items onto an array and then generate the XMLTV data from the arrays like this:

     @Actors = split(/,\s/, $ActorNames);
     @Directors = split(/,\s/, $DirectorNames);
     @Producers = split(/,\s/, $ProducerNames);
     @Writers = split(/,\s/, $WriterNames);
     if (scalar(@Actors) > 0) { $Program{credits}{actor} = \@Actors; }
     if (scalar(@Directors) > 0)
         { $Program{credits}{director} = \@Directors; }
     if (scalar(@Producers) > 0)
         { $Program{credits}{producer} = \@Producers; }
     if (scalar(@Writers) > 0) { $Program{credits}{writer} = \@Writers; }

For any data that has no special requirements, you can use a table that looks something like this to indicate how it is processed:

     my %ProgramTags = (                     # Tags for program data
         "DE", "desc|en",                    # Description
         "DT", "date",                       # Release date (year)
         "ET", "sub-title|en",               # Episode title
         "MP", "rating|MPAA",                # MPAA rating
         "TI", "title|en",                   # Program title
         "ZZ", "Junk");                      # Placeholder
     if (exists($ProgramTags{$FieldKey}))
         {
         if ($ProgramTags{$FieldKey} =~ /\|/)
             {
             @XtraTags = split(/\|/, $ProgramTags{$FieldKey});
             $FieldTag = shift(@XtraTags); unshift(@XtraTags, $InfoItem);
             $Program{$FieldTag} = [[@XtraTags]];
             }
         else { $Program{$ProgramTags{$FieldKey}} = $InfoItem; }
         }

When all is said and done, the program data should be written to the XMLTV file:

     $XMLTVHand->write_programme(\%Program);

Before you attempt to load any guide data into MythTV, be sure that you set the xmltvid field of each channel in the channel table to the same value as was set for the second display-name in your generated data. You can update the field like this:

     update channel set xmltvid='nn' where chanid=mmmm;

Or, you can go back and reload your channel table with the original data that you used to populate it, setting the xmltvid in that data, like so:

     -- Add the only real analog channels from the PSIP section
     insert into channel set chanid=3002, channum='2', freqid=2, sourceid=3,
       xmltvid='2', callsign='WGBH', name='WGBH-2 (PBS, Boston)';
     insert into channel set chanid=3003, channum='3', freqid=3, sourceid=3,
       xmltvid='3', callsign='HSN', name='HSN (Shopping)', visible=0;
          .
          .
          .
     -- Add the analog virtual channels from the PSIP section
     insert into channel set chanid=3023, channum='23', freqid=23, sourceid=3,
       xmltvid='23', callsign='DAYSTAR', name='Daystar (Religious)', visible=0;
     insert into channel set chanid=3024, channum='24', freqid=24, sourceid=3,
       xmltvid='24', callsign='DISNEY', name='Disney';
          .
          .
          .

Once you've generated your XMLTV guide data files and made them available to the MythTV master backend, you can load the generated data with:

     mythfilldatabase --file n /path/to/my/guidedata.xml

Where "n" is the source number (e.g. cable, antenna) that is to be updated.

We suggest that you try this on your test system first, in case you muck it up (its easy to do). To begin with, you can trim your generated data to only include one channel and a day's worth of listings. Once you get the listings to show up as the right channel, at the right times, you can switch to your production system.

A good way to check the listings is with MythWeb. The TV/Program Listing page will show you pretty quickly whether the data is good or not. If you do muck it up and want to retry, these deletes will clear the database:

     delete from channel where chanid=bogus;
     delete from program where chanid=bogus;
     delete from programrating where chanid=bogus;

or, for a range of guide data:

     delete from channel where chanid>=bogus-low and chanid<=bogus-hi;
     delete from program where chanid>=bogus-low and chanid<=bogus-hi;
     delete from programrating where chanid>=bogus-low and chanid<=bogus-hi;

Note that the oldprogram table may hold borked program descriptions but its probably best not to delete things from it, since it is used by recorded programs, etc. Besides, who cares if SpongeBob mistakenly investigates a murder in a hotel in New York, anyway?

After you've got your code working and you are successfully generating XMLTV guidedata files, you'll need to load them into MythTV. We use a script that is run by cron at regular intervals. Here it is:

guidedata-update:

     #!/bin/sh
     #
     # Script to update MythTV guide data using XMLTV files that were built
     # elsewhere, on a remote server.
     #
     # This script will mirror the remote server's XMLTV directory for the chosen
     # zipcode, using lftp, and then load any files, using mythfilldatabase, that
     # are newer than the time of the last load.  Note that the mirror directory
     # on the local host and the remote server's XMLTV directory must have the
     # same path name.
     #
     #
     # Should be run at regular intervals from cron, any time after the XMLTV
     # files are built on the remote server.  Use the following:
     #
     #      guidedata-update zipcode source
     #
     # zipcode -   The zipcode or Canadian postal code to update data for.
     #
     # source -    The source number (from the mythconverg database) whose guide
     #             data is to be updated.  More than one source can be updated at
     #             once by specifying a comma-separated list.  The default, if
     #             omitted, is 1.
     #
     #
     # Where things are found.
     #
     RemoteHost=192.168.1.1
     RemoteUser=guidedata
     RemotePass=asecretpass
     XMLTVDir=/var/guidedata/XMLTVData
     Owner=root
     Group=mythtvuser
     #
     # Stupidity checking and parameter processing.
     #
     if test x"$1" = x; then
         echo "Zipcode omitted, defaulting to 12345"
         ZipCode="12345"
     else
         ZipCode=$1
     fi
     XMLTVPath="${XMLTVDir}/${ZipCode}"
     if test x"$2" = x; then
         echo "Source omitted, defaulting to 1"
         Source="1"
     else
         Source=$2
     fi
     Source=${Source},
     #
     # Mirror the remote server's XMLTV directory here.
     #
     # Note that we must include the path to echo in the mirror command, otherwise
     # it fails under cron.
     #
     /bin/echo -e "mirror -e ${XMLTVPath}/ ${XMLTVPath}" \
         | /usr/bin/lftp -u ${RemoteUser},${RemotePass} ${RemoteHost}
     chown ${Owner}:${Group} ${XMLTVPath}/
     chmod ug=rw,o=r ${XMLTVPath}/
     #
     # For each source that we were asked to update, troll through the mirrored
     # directory looking for any guide data files that are newer than the time of
     # the last update.
     #
     while echo $Source | grep \, 2>&1 >/dev/null; do
         #
         # Grab the next source out of the list.  Then, remove it from the list.
         
         ProgSrc=${Source%%\,}
         Source=${Source\,}
         #
         # Process all of the files that we haven't done yet.
         #
         if [ ! -f ${XMLTVDir}/${ZipCode}_${ProgSrc}previousupdate ]; then
             touch -t 197001010500 \
                   -f ${XMLTVDir}/${ZipCode}_${ProgSrc}previousupdate
         fi
      /usr/bin/find ${XMLTVPath} -name *.xml -type f \
          -newer ${XMLTVDir}/${ZipCode}_${ProgSrc}previousupdate \
          -exec /usr/bin/mythfilldatabase --file ${ProgSrc} \{\} \; \
                >/dev/null 2>&1
      #    -exec echo "/usr/bin/mythfilldatabase --file ${ProgSrc} {}" \;
      #    -exec /usr/bin/mythfilldatabase --file ${ProgSrc} \{\} \;
      touch -f ${XMLTVDir}/${ZipCode}_${ProgSrc}previousupdate

done

Updating The DVB Capture Card Drivers

If after you have everything set up properly, you find that your pcHDTV card will not capture Analog NTSC signals properly, you may need to rebuild the card's drivers from newer source. As of 2008 Feb 14, Mythbuntu's 7.10 kernel still contains code which will give you problems switching back and forth between NTSC and ATSC. Mythbuntu 8.04LTS, on the other hand, does contain the newest code and, furthermore, compiling and installing the fixes shown herein will break the DVB drivers. So, if you have 8.04LTS and it still does not work, you have the s.o.l. blues. Basically, this card is a piece of crap when it comes to Analog NTSC (many people in the pcHDTV/Ubuntu forums complain of it not working). If you still want Analog NTSC (now that the rest of us have moved on to HDTV), maybe you should try the Haupaugge WinTV-PVR-150 cards.

Anyway, under the earlier releases of Mythbuntu, to fix the DVB drivers, you need to compile the v4l-dvb tree yourself and install it over your current kernel modules. Follow these steps:

     sudo apt-get install gcc linux-headers-`uname -r` mercurial
     cd your/build/directory
     hg clone http://linuxtv.org/hg/v4l-dvb
     cd v4l-dvb
     make
     sudo make install
     sudo reboot

The second step should change to your local build directory (whatever that is), where the third step will clone a copy of the v4l-dvb build directory. If you want to put this in your home directory or some other inncuous spot, the build can be done without root priviledges. You only need root priviledges to install the resultant build.

Once the build/install is done, you need to reboot for the new drivers to be loaded. It should fix problems with the pcHDTV card. It is known to work on Mythbuntu 7.10, for example.

One more thing. Should you apply these changes to your system and they hose the DVB drivers, you can recover by firing up the package manager and reinstalling these packages:

     linux-image-ver-generic
     linux-ubuntu-modules-ver

Note that, despite what the comments tell you about using linux-image-generic instead, reinstalling it won't cut it because it does not force the dependant packages to be reinstalled (droppage). You must pick the two packages mentioned above, with the highest version numbers, and reinstall them individually.

Video Cards

If you are using one of the NVidia Geforce 440MX or newer video cards, the built-in XvMC support is supposed to offload a lot of work from the CPU when viewing HDTV streams. On the other hand, many users have reported that instead of improving the video, it makes it worse. This has certainly been my experience.

The stock setup will pick a video replay configuration that uses XvMC, if it is available, for certain frame sizes. If you experience problems when viewing video with one of the NVidia cards, this could be the cause. You will need to override the stock configuration.

Another problem is that many of the newer CPUs are dual processors but the video transcoding operation is forced by the stock configuration to use only one CPU. Thus, when you turn off XvMC, your processor will not be fast enough to transcode the video using only the one processor. The solution is to allow the use of two processors in your new configuration.

From the MythTV frontend, choose Utilities/Setup from the main menu, then Setup, TV Settings, and Playback from the menu tree. Navigate to the third page (Playback Profiles (3/9)) and select the "Add New" choice near the top of the page. Give your new entry a name (I called mine "Dual Core").

Once you've added the new playback group and named it, pick the "Add New Entry" choice near the bottom of the page. On the first screen, for the first Match Criteria, choose ">=" and 1280, 720. Leave the second Match Criteria blank. For the Decoder pick "Standard" and set Max CPUs to 2. For Video Renderer, select "xv-blit" and for OSD Renderer pick "softblend". On the second page, Primary Deinterlacer should be set to "Linear blend", as should Fallback Deinterlacer. Complete this playback entry.

Pick "Add New Entry" a second time. On the first screen, for the first Match Criteria, choose ">" and 0, 0. Leave the second Match Criteria blank. For the Decoder pick "Standard" and set Max CPUs to 2. For Video Renderer, select "xv-blit" and for OSD Renderer pick "softblend". On the second page, Primary Deinterlacer should be set to "Greedy HighMotion (2x)". Fallback Deinterlacer should be set to "Kernel". Complete this playback entry.

Navigate through the remaining screens to cause the configuration to be stored and selected.

Newest NVidia Driver

If you are using an NVidia graphics card and are unfortunate enough to be trying to connect to a display that is not recognized by the NVidia driver, you will undoubtedly have problems configuring that display, since the shipping NVidia driver in many releases of Mythbuntu (e.g. 8.04LTS) does not recognize Modelines in the xorg.conf file. Before you can configure your display, using the information outlined below, you may have to install the newest NVidia driver (let the goat roping continue).

Firstly, since you are going to be messing with the X-Windows configuration and the display adapter, you must shutdown X. This pretty much means that you must first ensure that you have a working SSH connection to the machine in question, since shutting down X on the Mythbuntu distributions renders the machine useless (no, it does not revert to a console that you can enter commands into -- it just sits there in dumb-ass mode). So, get a copy of your favorite telnet, turn on SSH on the box and make sure you can talk to it that way. When you're happy that SSH works, shut down the X-Server:

     sudo /etc/init.d/gdm stop

From the telnet session, make sure you have the driver build environment (this is not necessarily the full kernel build environment). To verify that you do, try:

     ls -l /lib/modules/`uname -r`/build

If you have this directory installed, skip down to the libc step below (Ubuntu usually provides them in a typical installation or if you if you already did these steps in conjunction with compiling a NIC driver, above). Otherwise, you'll need to first get the build environment:

     sudo apt-get install build-essential

Then, you should make sure to install the latest headers for your kernel. When you enter the following command, be sure to use back-quotes:

     sudo apt-get install linux-headers-`uname -r`

Next, link the headers to the build folder in the proper place.

     sudo ln -s /usr/src/linux-headers-`uname -r` /lib/modules/`uname -r`/build

In addition to the driver build environment, you'll need the libc development package, the package configuration module, and the XOrg development package installed. Use the following command to get and install them:

     sudo apt-get install libc6-dev pkg-config xorg-dev

This should allow you to build the NVidia driver.

Create a new directory and download the latest NVidia driver for Linux from http://www.nvidia.com/object/unix.html:

     mkdir NVidia
     cd NVidia
     use your favorite browser to navigate through the NVidia pages and download
       the driver

Purge the NVidia restricted package, if installed, by doing:

     sudo dpkg --purge nvidia-glx-new

Run the NVidia installer:

     sudo sh NVIDIA-Linux-x86-173.14.05-pkg1.run

You can let the installer have a crack at finding a pre-compiled version on the NVidia Web site (but this didn't work for Mythbuntu 8.04LTS). If it doesn't find one, or you just want to compile it locally, skip that step. Allow the installer to build the driver locally. Then, allow it to update your xorg.conf file.

Note that the installer may whine about the compiler version not matching the one used to build the kernel. You've just got to love the guys who thought it would be a smooth idea to use compiled in kernel interfaces for all of the device drivers. Nothing like having to compile your device drivers every time you change kernels. So, if we're going that route, might as well build structures that depend on the compiler version for the interface to work. Why not? What a crock of shit....

Anyway, the warning is probably bogs, since different point releases of the compiler don't usually change the way structures are aligned. You can probably ignore it. But, if you're worried, you can try the following (it worked for me):

     sudo sh NVIDIA-Linux-x86-173.14.05-pkg1.run --add-this-kernel
     sudo sh NVIDIA-Linux-x86-173.14.05-pkg1-custom.run

This will build a custom install script especially for the currently-running kernel. You can then execute that script to build the NVidia driver especially for it. There shouldn't be any whining about the compiler version but, if you still have problems, here is the full story:

     If you know what you are doing and want to override this check, you can do
     so by setting the environment variable IGNORE_CC_MISMATCH, before doing the
     build.
     Otherwise, set the CC environment variable to the name of the compiler that
     was used to compile the kernel.
     The reason for compiling the NVIDIA kernel module with the same compiler
     version that was used to compile your kernel (as was noted above) is that
     some Linux kernel data structures are dependent on the version of gcc used
     to compile them; for example, in include/linux/spinlock.h:
     ...
     * Most gcc versions have a nasty bug with empty initializers.
     */
     #if (__GNUC__ > 2)
       typedef struct { } rwlock_t;
       #define RW_LOCK_UNLOCKED (rwlock_t) { }
     #else
       typedef struct { int gcc_is_buggy; } rwlock_t;
       #define RW_LOCK_UNLOCKED (rwlock_t) { 0 }
     #endif
     If the kernel is compiled with gcc 2.x, but gcc 3.x is used when the kernel
     interface is compiled (or vice versa), the size of rwlock_t will vary, and
     things like ioremap will fail.  To check what version of gcc was used to
     compile your kernel, you can examine the output of:
     cat /proc/version
     To check what version of gcc is currently in your $PATH, you can examine the
     output of:
     gcc -v

Oh, and one other little wrinkle. On some later versions of the OS (e.g. Mythbuntu 9.04), the geniuses at XOrg decided to add an irrelevant windge to the X command when "-showDefaultLibPath" is used. So, when the following command is run:

     /usr/bin/X -showDefaultLibPath

You see:

     X: warning; process set to priority -2 instead of requested priority 0
     /usr/lib

First of all, who gives a rat's butt what priority X runs at? And, certainly, who gives a rat's butt what priority it runs at when its echoing the default library path? Are these guys on some planet where stupidity is the norm? But, ranting aside, the windge comes as a huge surprise to the NVidia install script which is expecting the path name of a directory, not some meaningless bleating. The script gets all confused and complains about the fact that the directory "X: warning ... /usr/lib" doesn't exist. Duh! Fortunately, it picks /usr/lib by default and all is well, despite what could have been another blow for lack of upward compatibility.

Here are the instructions for the installer, just in case you need them. The complete instructions can be found in the README file on the NVidia Web site at: http://www.nvidia.com/object/unix.html.

     The .run file is a self-extracting archive. When executed, it extracts the
     contents of the archive and runs the contained nvidia-installer utility,
     which provides an interactive interface to walk you through the installation.
     nvidia-installer will also install itself to /usr/bin/nvidia-installer, which
     may be used at some later time to uninstall drivers, auto-download updated
     drivers, etc. The use of this utility is detailed later in this chapter.
     You may also supply command line options to the .run file. Some of the more
     common options are listed below.
     --info              Print embedded info about the .run file and exit.
     --check             Check integrity of the archive and exit.
     --extract-only      Extract the contents of NVIDIA-Linux-x86-173.14.05.run,
                         but do not run nvidia-installer.
     --help              Print usage information for the common commandline
                         options and exit.
     --advanced-options  Print usage information for common command line options
                         as well as the advanced options, and then exit.
     --uninstall         During installation, the installer will make backups of
                         any conflicting files and record the installation of
                         new files. The uninstall option undoes an install,
                         restoring the system to its pre-install state.
     --latest            Connect to NVIDIA's FTP site, and report the latest
                         driver version and the url to the latest driver file.
     --update            Connect to NVIDIA's FTP site, download the most recent
                         driver file, and install it.
     --ui=none           The installer uses an ncurses-based user interface if
                         it is able to locate the correct ncurses library.
                         Otherwise, it will fall back to a simple commandline
                         user interface. This option disables the use of the
                         ncurses library.

Black list the nv driver in the /etc/default/linux-restricted-modules-common file. Do so by editing the file with your favorite editor and changing the DISABLED_MODULES line to include "nv". For example:

     DISABLED_MODULES="nv"

Check that no prior installations of any versions of the NVidia driver have left crap-oh-la lying about to mess things up. In /etc/modprobe.d, you may find a module named "nvidia-kernel-nkc.conf". In it you may see something like:

     alias char-major-195* nvidia
     options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=44
                    NVreg_DeviceFileMode=0660

This will cause no end of grief by loading a copy of the NVidia kernel driver that is left over from the prior installation. When the newly-installed driver attempts to run, it will complain about the kernel driver API being wrong and quit, thereby causing XOrg not to start (you'll see this in /var/log/Xorg.0.log upon reboot). A sure test is to do "rmmod nvidia" and then restart gdm. If this causes gdm to start OK, you've got a conflicting module loaded.

Also, someone or something may have mistakenly tried to fix this situation by adding a blacklist for the nvidia driver to one of the blacklist files in /etc/modprobe.d. The most likely place is "blacklist-local.conf" but it may be somewhere else too. Look for any file containing:

     blacklist nvidia

Remove this line from the file. If it is the only line in the file, you may delete it too, if you wish.

Incidentally, some of the blogs or mail archives on the Internet suggest adding "rmmod nvidia" to /etc/init.d/gdm, right before gdm is started. If you fix the problem correctly, this should be completely unnecessary.

Start the gdm server back up:

     sudo /etc/init.d/gdm start

If you wish to use the NVidia-supplied configurator for the xorg.conf file, you can find the man page under:

     man nvidia-xconfig

Video Displays

Normally, Mythbuntu does a pretty good job of detecting the display connected to it and configuring it automagically. However, if your video display does not play well with Mythbuntu (i.e. it cannot be probed and set up automagically), you may have to configure it yourself.

This section describes what to do about this situation but first, a note about how to get out of a bind, if for some reason your display does not work properly and you cannot recover from this state because the picture is too garbled to run the usual configuration tools.

Using SSH on another system, connect to the system that is in trouble and go to the /etc/X11 directory. There, you should find files named xorg.conf*. You should rename xorg.conf to something like xorg.conf.brokey and then symlink xorg.conf to the xorg.conf.failsafe file:

     cd /etc/X11
     sudo mv xorg.conf xorg.conf.brokey
     sudo ln -s xorg.conf.failsafe xorg.conf

This should get you up and running, at which point you can begin monkeying around with the display configuration to arrive at one that works for your display.

Also, before you start playing around with any of the display settings, be aware that some of the NVidia drivers don't handle modelines properly so you may want to check into that first, before you waste a whole lot of time (like we did) trying to set something that's going to have no effect.

If the display you are trying to work with is a TV, you may find some useful notes about setting it up at this URL:

     http://www.linuxis.us/linux/media/howto/linux-htpc/
       video_card_configuration.html

Basically, you are trying to figure out one or more modelines that can be used to set the various screen resolutions supported by your display. There should be a chart in the back of your display's manual that lists all of the supported modes (beware that some of the charts we've seen have the vertical and horizontal frequencies exchanged - a good clue is that the vertical frequency is usually the one that matches the number in the VESA name). First off, you should try to pick one of the standard modes from the list below. Also, it is best to try and pick the highest vertical refresh rate (in Hz) supported by your display:

     # 640x400 @ 85Hz (VGA VESA 85) hsync: 37.9kHz
     ModeLine "640x400"    31.5    640  672  736  832  400  401  404  445 \
       -hsync +vsync
     # 640x480 @ 60Hz (Industry standard) hsync: 31.5kHz
     ModeLine "640x480"    25.2    640  656  752  800  480  490  492  525 \
       -hsync -vsync
     # 640x480 @ 72Hz (VGA VESA 72) hsync: 37.9kHz
     ModeLine "640x480"    31.5    640  664  704  832  480  489  491  520 \
       -hsync -vsync
     # 640x480 @ 75Hz (VGA VESA 75) hsync: 37.5kHz
     ModeLine "640x480"    31.5    640  656  720  840  480  481  484  500 \
       -hsync -vsync
     # 640x480 @ 85Hz (VGA VESA 85) hsync: 43.3kHz
     ModeLine "640x480"    36.0    640  696  752  832  480  481  484  509 \
       -hsync -vsync
     # 720x400 @ 85Hz (VESA 85) hsync: 37.9kHz
     ModeLine "720x400"    35.5    720  756  828  936  400  401  404  446 \
       -hsync +vsync
     # 800x600 @ 56Hz (SVGA VESA 56) hsync: 35.2kHz
     ModeLine "800x600"    36.0    800  824  896 1024  600  601  603  625 \
       +hsync +vsync
     # 800x600 @ 60Hz (SVGA VESA 60) hsync: 37.9kHz
     ModeLine "800x600"    40.0    800  840  968 1056  600  601  605  628 \
       +hsync +vsync
     # 800x600 @ 72Hz (SVGA VESA 72) hsync: 48.1kHz
     ModeLine "800x600"    50.0    800  856  976 1040  600  637  643  666 \
       +hsync +vsync
     # 800x600 @ 75Hz (SVGA VESA 75) hsync: 46.9kHz
     ModeLine "800x600"    49.5    800  816  896 1056  600  601  604  625 \
       +hsync +vsync
     # 800x600 @ 85Hz (SVGA VESA 85) hsync: 53.7kHz
     ModeLine "800x600"    56.3    800  832  896 1048  600  601  604  631 \
       +hsync +vsync
     # 1024x768 @ 43Hz (industry standard) hsync: 35.5kHz
     ModeLine "1024x768"   44.9   1024 1032 1208 1264  768  768  776  817 \
       +hsync +vsync Interlace
     # 1024x768 @ 60Hz (XGA VESA 60) hsync: 48.4kHz
     ModeLine "1024x768"   65.0   1024 1048 1184 1344  768  771  777  806 \
       -hsync -vsync
     # 1024x768 @ 70Hz (VESA 70, HP1070) hsync: 56.5kHz
     ModeLine "1024x768"   75.0   1024 1048 1184 1328  768  771  777  806 \
       -hsync -vsync
     # 1024x768 @ 75Hz (XGA VESA 75) hsync: 60.0kHz
     ModeLine "1024x768"   78.8   1024 1040 1136 1312  768  769  772  800 \
       +hsync +vsync
     # 1024x768 @ 85Hz (XGA VESA 85) hsync: 68.7kHz
     ModeLine "1024x768"   94.5   1024 1072 1168 1376  768  769  772  808 \
       +hsync +vsync
     # 1152x864 @ 75Hz (SXGA VESA 75) hsync: 67.5kHz
     ModeLine "1152x864" 108.0    1152 1216 1344 1600  864  865  868  900 \
       +hsync +vsync
     # 1280x960 @ 60Hz (SXGA VESA 60) hsync: 60.0kHz
     ModeLine "1280x960"  108.0   1280 1376 1488 1800  960  961  964 1000 \
       +hsync +vsync
     # 1280x960 @ 85Hz (SXGA VESA 85) hsync: 85.9kHz
     ModeLine "1280x960"  148.5   1280 1344 1504 1728  960  961  964 1011 \
       +hsync +vsync

If you didn't find your display's resolution in this list, there are more standard modes listed at:

     http://m.domaindlx.com/LinuxHelp/resources/modelines.htm

Another way to obtain a modeline for your display is to use videogen. If it is not installed on your Mythbuntu system, you can obtain it with:

     sudo apt-get install videogen

To use it, you select the maximum dot or pixel clock frequency from your display's specifications, along with the maximum vertical and horizontal refresh rates. Feed the desired screen resolution plus these values into videogen:

     videogen -m640x480 -mdc=108 -mhf=87 -mvf=72

This will generate a modeline with the highest refresh rate that can be supported by your monitor for the resolution selected. In the above example, we determined that the maximum dot clock was 108 (from perusing all of the resolutions listed for the monitor) and the maximum horizontal frequency was 87 KHz, while the maximum vertical frequency was 72Hz.

This would yield a modeline for a dot clock of 30MHz, a horizontal refresh rate of 36.4 kHz and a vertical refresh rate of 72Hz.

Yet another alternative is to use the modeline calculator at:

     http://xtiming.sourceforge.net/cgi-bin/xtiming.pl

Instead of determining the maximum refresh rate for your display, this will let you put in the refresh rate and calculate the modeline from that. If you are trying to match your display's refresh rate with that of a video broadcast so as not to see jitter from interpolated frames, you might find this method more to your liking.

Now, make a copy of your working xorg.conf file in /etc/X11 and begin hacking the Monitor section. Set the device identification fields to something useful:

     Identifier   "Syntax LT27HV LCD Display"
     VendorName   "Syntax"
     ModelName    "Olevia LT27HV"

Next, you should probably set the minimum and maximum horizontal and vertical sync frequencies from the chart of your display's capabilities:

     HorizSync    56-87
     VertRefresh  24-72

These values are not used to calculate any actual display settings but the values in the modelines are checked against these limits to ensure that you do not exceed your display's capabilities (and possibly destroy it).

Then, add the modelines to this section:

     # 640x480 @ 85Hz (VGA VESA 85) hsync: 43.3kHz
     ModeLine "640x480-85"  36.0  640 696 752 832  480 481 484 509  -hsync -vsync
     # 800x600 @ 85Hz (SVGA VESA 85) hsync: 53.7kHz
     ModeLine "800x600-85"  56.3  800 832 896 1048  600 601 604 631  +hsync +vsync
     # 1024x768 @ 85Hz (XGA VESA 85) hsync: 68.7kHz
     ModeLine "1024x768-85"  94.5  1024 1072 1168 1376  768 769 772 808 \
       +hsync +vsync
     # 1280x720 @ 60Hz (1280x720-60) vsync: 60.39Hz, hsync: 45.72kHz, clk: 74.25
     # This is the only true native mode for the LT27HV display.
     Modeline "1280x720-60" 74.25 1280 1312 1592 1624 720 735 742 757 \
       +hsync +vsync

For the Syntax Olevia models, you may want to add the following, as well:

     # Power saving mode
     Option       "DPMS"
     # We know everything about this display
     Option       "UseEDID" "false"
     # We know what the dot pitch is
     Option       "DPI" "96×96"
     # Make sure the video card always picks the CRT.  Or, if you have the
     # display plugged in on the DVI connection, use "DFP" instead of "CRT-0".
     Option       "UseDisplayDevice" "CRT-0"

Next, hack the Screen section to use the display that you just defined by setting the Display SubSection to point to it:

     # The color depth
     Depth        24
     # All of the supported modes that we defined in modelines.  The first is
     # the default mode chosen at startup.
     Modes        "1280x720-60"  "1024x768-85"  "800x600-85"  "640x480-85"

Now, you can either copy this file over the top of xorg.conf or symlink it:

     sudo rm -f xorg.conf
     sudo ln -s xorg.conf.failsafe xorg.conf

If you have any more questions about the configuration of display devices under Xorg, you can look at the man page:

     man xorg.conf

Getting Rid of Overscan and Centering the Image

If the image displayed on your display device is not properly centered or has overscan, you may be able to correct it by following these procedures. The important thing to understand is that the visible part of the image is only a portion of the overall image you send to the screen. Since HDTVs can be very, very finicky about accepting a signal, it's best to get a modeline they can accept (see above) and then tweak it to get the image you want.

Let's say, in my case, my Olevia LT27HV would sync to a 1280x720 signal, but with the image centered too far to the right and to far up the screen, leaving a black bar on the left and at the bottom.

The orignal modeline that the TV was syncing to:

     # 1280x720 @ 60Hz (1280x720-60) vsync: 60.39Hz, hsync: 45.72kHz, clk: 74.25
     # This is the only true native mode for the LT27HV display.
     Modeline "1280x720-60" 74.25 1280 1312 1592 1624 720 735 742 757 \
       +hsync +vsync

This, however, left me with a black strip of about 1" on the right and on the bottom.

So, to move the image to the left, all we do is move the horizontal sync bar to the right. The horizontal sync bar is given by the 4th and 5th parameters in the modeline (1312 and 1592 above). That bar always stays fixed, so if we 'move' the bar to the left the picture moves to the right. Let's try adding 10 pixels to it:

     Modeline "1280x720-60" 74.25 1280 1322 1602 1624 720 735 742 757 \
       +hsync +vsync

The vertical sync bar is given by the 8th and 9th numbers (735 and 742 above), and works the same way: increase the numbers and the image moves up, decrease the numbers and the image moves down.

Now that the top left is positioned correctly, let's say we needed to fix some overscan. To do that, we'd tell the video card to put the image into a smaller portion of the overall frame it sends to the TV. We'd do that by reducing the numbers in the 3rd and 7th columns (1280 and 720 above). Now they read 1280x720 but if that's too big for the TV to display correctly, a bit of trial and error might produce a modeline where the image is centered correctly, and has no overscan:

     Modeline "1280x720-60" 74.25 1274 1322 1602 1624 716 730 737 757 \
       +hsync +vsync

For an excellent graphical and technical explanation, see:

     http://www.epanorama.net/documents/vga2rgb/timings.html

Desktop Problems

The most common problem that occurs, with the Mythbuntu desktop, is the disappearance of the xfce-panel. What is it, you ask? Why, its simply the application that shows the taskbar at the top/bottom of the desktop. If this application is turned off or if it fails to launch, you won't see the taskbar.

To cure the problem, it is best to reset your xfce-panel settings to their original values. The easiest way to do this (you can monkey with the panel settings application through the display manager for a couple or six hours but this usually proves to be fruitless, not to mention frustrating) is to shut down the display manager and then fix up the config files, like so:

     sudo /etc/init.d/gdm stop   (earlier systems like Mythbuntu 9.04)

or

     sudo stop lightdm   (later systems like Mythbuntu 12.04)

Once the display manager stops, edit its settings config file for the local user that is being logged on (e.g. "mythtv"). Make sure that the SaveOnExit line looks like this:

/home/mythtv/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml:

.

       .
  <property name="SaveOnExit" type="empty"/>
       .
       .
       .

Then, get rid of any saved xfce save sessions in the user's cache. For the "mythtv" user, you'd do something like this:

     sudo rm -f /home/mythtv/.cache/sessions/xfce4-session*

Once that is done, you can start up the display manager and you should see the panel the way it used to be (i.e. with the task bar):

     sudo /etc/init.d/gdm start   (earlier systems like Mythbuntu 9.04)

or

     sudo start lightdm   (later systems like Mythbuntu 12.04)

Sound Problems

If you have problems with sound volume, from prior experience with other sound cards it is usually due to the master volume being muted (a number of sound drivers are installed with the master volume muted), the master volume being set too low, the PCM volume being set too low or the switches, such as the number of channels available, being set incorrectly. For example, selecting 2-channel sound when 4-, or 6-channel sound has to be selected, even though only two speakers are actually used.

You can often overcome problems with the master volume being set too low or the PCM volume being set too low, directly through the setup pages of the Mythbuntu frontend. Enter through the "Utils/Setup" menu choice and then navigate through the menus via the "Setup" and "General" choices or directly via "Setup" and then "Audio", on later versions. Then, page forward until you reach the "Audio/Mixer" page. Set these settings as follows:

     Mixer Controls: PCM
     Master Mixer Volume: 100
     PCM Mixer Volume: 100

If changing these settings in the Mythbuntu frontend still doesn't work, try experimenting with the settings in alsamixer:

     alsamixer

Typically, the master volume, PCM volume and particularly the front speaker volume (the front speaker volume is not settable from the Mythbuntu frontend) should all be set to 100 and the three controls not muted. The up/down arrows raise/lower the volume and the 'M' toggles mute. If "MM" is shown for the control, it is muted.

Or, if you prefer a nicer GUI, for earlier versions of Mythbuntu (up to 9.04) you can try aumix, if the aumix-gtk package is installed like so:

     sudo apt-get install aumix-gtk

The mixer can be run from the Multimedia menu or by typing:

     aumix &

For later versions of Mythbuntu (9.10 and beyond), you can run the "GNOME ALSA Mixer" from the Multimedia menu, if the gnome-alsamixer package is installed thusly:

     sudo apt-get install gnome-alsamixer

Once you set the volume levels in the aforementioned manner, they should stick each time the system is rebooted (i.e. you only have to set them once). If they don't, you could use the command line program "amixer" in the "rc.local" startup script to set the mixer volume each time the system reboots but, so far, we haven't had to resort to this.

A couple of commands that may be useful to test the sound are:

     speaker-test
     aplay -D plughw:0,0 /usr/share/sounds/alsa/Front_Center.wav

If there isn't any sound, you can try running the following script to see what sound cards are installed and activated, and how they named. You should pick one of the names enumerated as the output device of MythTV.

RecognizeAudio

     #!/bin/sh
     #
     # Script to find the sound cards installed in the system and give some
     # useful information about them.
     #
     # This script can be useful in debugging ALSA sound problems.  It will find
     # all of the sound cards installed in the system by querying the PCI bus and
     # looking for sound card models.  It will then scan the ALSA modules loaded
     # into the kernel and see which sound cards are recognized by ALSA.  Of the
     # recognized modules, it checks which ones are activated (i.e. capable of
     # playing sound).  Finally, a list of the sound playback devices (according
     # to ALSA) are enumerated, followed by the names used to select these
     # devices.
     #
     # If you run this script and you don't see all of the following headings,
     # there is probably something wrong with your ALSA setup:
     #
     #      Sound cards recognized by the system:
     #      Sound cards recognized by ALSA:
     #      Sound cards recognized by ALSA, and activated:
     #      ALSA playback devices:
     #      Names used to reference ALSA playback devices:
     #
     # Find all of the sound cards on the PCI bus.
     echo "Sound cards recognized by the system:"
     lspci -nn | grep --color=none '\[04[80][13]\]'
     # For each of the sound cards on the PCI bus, see which ones have an ALSA
     # kernel module loaded.
     Module=`lspci -nnk | grep -A 3 '\[04[80][13]\]' | while read Line; do
         if ( echo $Line | grep -q '\[04[80][13]\]' ); then
             Card=$Line
         else
             if ( echo $Line | grep -q 'Kernel module' ); then
                 echo $Card
             fi
         fi
     done`
     if [ "$Module"x != x ]; then
         echo
         echo "Sound cards recognized by ALSA:"
         echo $Module
     fi
     # Now, for each of the sound cards on the PCI bus, see which ones have an
     # ALSA device driver.
     Driver=`lspci -nnk | grep -A 3 '\[04[80][13]\]' | while read Line; do
         if ( echo $Line | grep -q '\[04[80][13]\]' ); then
             Card=$Line
         else
             if ( echo $Line | grep -q 'Kernel driver' ); then
                 echo $Card
             fi
         fi
     done`
     if [ "$Driver"x != x ]; then
         echo
         echo "Sound cards recognized by ALSA, and activated:"
         echo $Driver
     fi
     # Give a list of all of the ALSA playback devices and a list of their names.
     if [ "$Driver"x != x ]; then
         echo
         echo "ALSA playback devices:"
         aplay -l | tail -n +2
      echo
      echo "Names used to reference ALSA playback devices:"
      aplay -L

fi

One solution for fixing missing or misconfigured ALSA devices is to reinstall the ALSA package as follows:

     sudo apt-get remove --purge alsa-base
     sudo apt-get install alsa-base
     sudo alsa force-reload

If you still experience problems, the Comprehensive Sound Problem Solutions Thread, which can be found at this URL, may prove helpful with a solution:

     http://ubuntuforums.org/showthread.php?t=1885240
     https://docs.google.com/document/d/
       1iTlJ8BfqXUjaHO__TEdlkvuqB1WLOkGaudngc5SFLMI/edit

However, before you start out on any sound debugging procedure, make sure that your system's BIOS settings are set so that sound is enabled. On some motherboards with built-in sound, the sound can be disabled or set to high-definition audio in the BIOS. This may preclude the sound from working and no end of monkeying with the ALSA/mixer settings will have any effect. So, check out the BIOS settings first.

Also, there are known problems with the dreaded ALC887 chipset (either from Realtek, or emulated by Nvidia). If your motherboard or soundcard has one of these on it (you should probably throw it in the trash, return it, or get another model), the ALSA drivers don't handle detection of the headphone signal correctly and consequently turn the speakers off all the time. This problem is reported to be fixed by adding this line to the end of the /etc/modprobe.d/alsa-base.conf file:

     options snd_hda_intel model=auto position_fix=3

If that doesn't work, some users have reported that the sledge hammer approach works, when you add this line to the end of the /etc/modprobe.d/alsa-base.conf file:

     options snd_hda_intel model=generic

In either case, a reboot is required.

Remote Controls

Many remote controls are supported directly by Mythbuntu. From years of experience with third party IR receivers, we have learned that the best ones to use (from the user experience perspective) are any of the USB, MCE-based remotes -- those that use the MCE driver lirc_mceusb or just mceusb (for later versions of Mythbuntu such as 12.04). The lirc_mceusb/mceusb driver is loaded into the kernel and therefore responds quickly and reliably to button presses by the user. The instances where the system does not respond to the helm are minimized, thereby maintaining the user's illusion of control. The Home Electro USB Tira-2 also seems to work well. Response to button presses is consistent and unexpected lockups rarely if ever occur.

However, despite warnings against crappy performance, unexpected lockups and other eratic behavior, should you still wish to use one of the other third party IR receivers (e.g. Home Electro serial Ira, or Iguana Works USB IguanaIR), you will need to do some work. Or, if you wish to use your favorite, unsupported remote, you will likewise have your work cut out for you.

For the MCE-based receivers, LIRC supports them via the "default" driver. You merely need to load the correct kernel module via modprobe for the MCE-based receivers to work properly. Typically, this is done automatically by the LIRC startup script, when you choose one of the MCE-based remotes in the config file so there's nothing else to be done. This is especially true for the latest versions of Mythbuntu (such as 12.04), which include, by default, drivers for not only the MCE-based receivers but a large number of other receivers as well.

Despite the fact that many remotes are directly supported by LIRC, you may sitll want or need to change the kernel module used by your current version of LIRC. For example, you may wish to replace the lirc_mceusb kernel driver in version 0.8.6 of LIRC (which comes built in to earlier versions of Mythbuntu), with a newer version of this driver that supports IR blasting for the latest TopSeed and Pinnacle MCE IR receivers. These receivers are readily obtainable on the Internet for a reasonable price but some of them (the 0x0008 version of the TopSeed, for example) have quirks that prevent IR blasting from working without the use of the latest code in lirc_mceusb.

If you have the latest version of Mythbuntu, it probably comes with version 0.9.0 of LIRC built in. It works quite well with many remotes. For earlier versions of Mythbuntu, that don't have the latest LIRC built in, or if you need to build an up-to-date version of LIRC to support some new, bleeding edge remote, you should follow these steps.

To begin, get the latest, packaged source for LIRC from http://www.lirc.org/software.html and prepare to build it in the usual manner. Then, if necessary, either download the new bleeding edge driver source from SourceForge (or wherever else is appropriate) and replace it in the proper subdirectory of the LIRC build tree, or update the latest source with any patches that you wish to make. Be careful that any new driver source that you use is compatible with the LIRC source that you download. The changes found in the latest source in the build tree may render it incompatible with the distributed source.

For instance, the code that adds support for IR blasting using the 0x0008 version of the above noted TopSeed receivers was added to the build tree after major architectural changes had been made that diverged from the 0.8.6 version of LIRC. Thus, to get TopSeed IR blasting to work, the following patch should be applied to the 0.8.6 LIRC source for lirc_mceusb.c:

lirc-0.8.6/drivers/lirc_mceusb/lirc_mceusb.c:

     --- lirc_mceusb-0.8.6.c     2009-09-02 10:04:02.000000000 -0400
     +++ lirc_mceusb-topseed.c   2010-05-19 17:59:01.824157087 -0400
     @@ -184,6 +184,8 @@
             { USB_DEVICE(VENDOR_TOPSEED, 0x0008) },
             /* Topseed eHome Infrared Transceiver /
             { USB_DEVICE(VENDOR_TOPSEED, 0x000a) },
     +       / Topseed eHome Infrared Transceiver /
     +       { USB_DEVICE(VENDOR_TOPSEED, 0x0011) },
             / Ricavision internal Infrared Transceiver /
             { USB_DEVICE(VENDOR_RICAVISION, 0x0010) },
             / Itron ione Libra Q-11 /
     @@ -226,6 +228,12 @@
             { }
      };
 
     +static struct usb_device_id gen3_list[] = {
     +       { USB_DEVICE(VENDOR_PINNACLE, 0x0225) },
     +       { USB_DEVICE(VENDOR_TOPSEED, 0x0008) },
     +       {}
     +};
     +
      static struct usb_device_id pinnacle_list[] = {
             { USB_DEVICE(VENDOR_PINNACLE, 0x0225) },
             {}
     @@ -245,6 +253,7 @@
             { USB_DEVICE(VENDOR_TOPSEED, 0x0007) },
             { USB_DEVICE(VENDOR_TOPSEED, 0x0008) },
             { USB_DEVICE(VENDOR_TOPSEED, 0x000a) },
     +       { USB_DEVICE(VENDOR_TOPSEED, 0x0011) },
             { USB_DEVICE(VENDOR_PINNACLE, 0x0225) },
             {}
      };
     @@ -272,7 +281,7 @@
             unsigned char is_pulse;
             struct {
                     u32 connected:1;
     -               u32 pinnacle:1;
     +               u32 gen3:1;
                     u32 transmitter_mask_inverted:1;
                     u32 microsoft_gen1:1;
                     u32 reserved:28;
     @@ -296,6 +305,12 @@
      static char pin_init2[] = { 0x9f, 0x13};
      static char pin_init3[] = { 0x9f, 0x0d};
 
     +static char DEVICE_RESET[]     = {0x00, 0xff, 0xaa};
     +static char GET_CARRIER_FREQ[] = {0x9f, 0x07};
     +static char GET_RX_TIMEOUT[]   = {0x9f, 0x0d};
     +static char GET_TX_BITMASK[]   = {0x9f, 0x13};
     +static char GET_RX_SENSOR[]    = {0x9f, 0x15};
     +
      #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 11)
      static unsigned long usecs_to_jiffies(const unsigned int u)
      {
     @@ -944,8 +959,9 @@
             int i;
             char buf[63], name[128] = "";
             int mem_failure = 0;
     -       int is_pinnacle;
     -       int is_microsoft_gen1;
     +       bool is_gen3;
     +       bool is_microsoft_gen1;
     +       bool is_pinnacle;
 
          dprintk(DRIVER_NAME ": %s called\n", __func__);
 
     @@ -955,10 +971,12 @@
 
          idesc = intf->cur_altsetting;
 
     -       is_pinnacle = usb_match_id(intf, pinnacle_list) ? 1 : 0;
     +       is_gen3 = usb_match_id(intf, gen3_list) ? 1 : 0;
 
          is_microsoft_gen1 = usb_match_id(intf, microsoft_gen1_list) ? 1 : 0;
 
     +       is_pinnacle = usb_match_id(intf, pinnacle_list) ? 1 : 0;
     +
             / step through the endpoints to find first bulk in and out endpoint /
             for (i = 0; i < idesc->desc.bNumEndpoints; ++i) {
                     ep = &idesc->endpoint[i].desc;
     @@ -975,13 +993,14 @@
                                     "found\n");
                             ep_in = ep;
                             ep_in->bmAttributes = USB_ENDPOINT_XFER_INT;
     -                       if (is_pinnacle)
     +                       if (!is_pinnacle)
                                     /
     -                                * setting seems to 1 seem to cause issues with
     -                                * Pinnacle timing out on transfer.
     +                                * Ideally, we'd use what the device offers up,
     +                                * but that leads to non-functioning first and
     +                                * second-gen devices, and many devices have an
     +                                * invalid bInterval of 0. Pinnacle devices
     +                                * don't work witha  bInterval of 1 though.
                                      /
     -                               ep_in->bInterval = ep->bInterval;
     -                       else
                                     ep_in->bInterval = 1;
                     }
 
     @@ -997,13 +1016,14 @@
                                     "found\n");
                             ep_out = ep;
                             ep_out->bmAttributes = USB_ENDPOINT_XFER_INT;
     -                       if (is_pinnacle)
     +                       if (!is_pinnacle)
                                     /
     -                                * setting seems to 1 seem to cause issues with
     -                                * Pinnacle timing out on transfer.
     +                                * Ideally, we'd use what the device offers up,
     +                                * but that leads to non-functioning first and
     +                                * second-gen devices, and many devices have an
     +                                * invalid bInterval of 0. Pinnacle devices
     +                                * don't work witha  bInterval of 1 though.
                                      /
     -                               ep_out->bInterval = ep->bInterval;
     -                       else
                                     ep_out->bInterval = 1;
                     }
             }
     @@ -1103,7 +1123,7 @@
             ir->len_in = maxp;
             ir->overflow_len = 0;
             ir->flags.connected = 0;
     -       ir->flags.pinnacle = is_pinnacle;
     +       ir->flags.gen3 = is_gen3;
             ir->flags.microsoft_gen1 = is_microsoft_gen1;
             ir->flags.transmitter_mask_inverted =
                     usb_match_id(intf, transmitter_mask_list) ? 0 : 1;
     @@ -1136,7 +1156,7 @@
             ir->urb_in->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
 
          / initialize device /
  -       if (ir->flags.pinnacle) {
  +       if (is_pinnacle) {
                  int usbret;
 
                  /
  @@ -1165,6 +1185,38 @@
                  request_packet_async(ir, ep_in, NULL, maxp, MCEUSB_INBOUND);
                  request_packet_async(ir, ep_out, pin_init3, sizeof(pin_init3),
                                       MCEUSB_OUTBOUND);
  +       }
  +
  +       /* initialize device /
  +       if (ir->flags.gen3) {
  +               request_packet_async(ir, ep_in, NULL, maxp, MCEUSB_INBOUND);
  +
  +               / device reset /
  +               request_packet_async(ir, ep_out, DEVICE_RESET,
  +                                    sizeof(DEVICE_RESET), MCEUSB_OUTBOUND);
  +               request_packet_async(ir, ep_in, NULL, maxp, MCEUSB_INBOUND);
  +
  +               / get the carrier and frequency /
  +               request_packet_async(ir, ep_out, GET_CARRIER_FREQ,
  +                                    sizeof(GET_CARRIER_FREQ),
  +                                    MCEUSB_OUTBOUND);
  +               request_packet_async(ir, ep_in, NULL, maxp, MCEUSB_INBOUND);
  +
  +               / get the transmitter bitmask /
  +               request_packet_async(ir, ep_out, GET_TX_BITMASK,
  +                                    sizeof(GET_TX_BITMASK), MCEUSB_OUTBOUND);
  +               request_packet_async(ir, ep_in, NULL, maxp, MCEUSB_INBOUND);
  +
  +               / get receiver timeout value /
  +               request_packet_async(ir, ep_out, GET_RX_TIMEOUT,
  +                                    sizeof(GET_RX_TIMEOUT), MCEUSB_OUTBOUND);
  +               request_packet_async(ir, ep_in, NULL, maxp, MCEUSB_INBOUND);
  +
  +               / get receiver sensor setting /
  +               request_packet_async(ir, ep_out, GET_RX_SENSOR,
  +                                    sizeof(GET_RX_SENSOR), MCEUSB_OUTBOUND);
  +               request_packet_async(ir, ep_in, NULL, maxp, MCEUSB_INBOUND);
  +
          } else if (ir->flags.microsoft_gen1) {
                  / original ms mce device requires some additional setup */
                  mceusb_gen1_init(ir);

Once your have the updated or modified source, build LIRC as follows:

     cd lirc-0.8.6
     ./configure --with-driver=mceusb
     make

Most versions of Mythbuntu install the necessary build environment to allow you to build the mceusb driver from scratch. However, if you get an error message that says "you need to have the Linux kernel source installed for this driver", you may have used the wrong driver name with the configure command (e.g. you used "--with-driver=lirc_mceusb" by mistake, instead of "--with-driver=mceusb") or you may not have the correct build environment installed. If you're sure you didn't use the wrong driver name, you should be able to install what you need with:

     sudo apt-get install build-essential linux-headers-`uname -r`

After the build succeeds, locate the existing LIRC kernel driver with a command something like this (here we're searching for the mceusb driver):

     sudo find /lib -name \*mceusb.ko

Once you find the existing driver, replace it in this fashion (assuming that the existing module is found in the kernel modules tree):

     sudo cp ~/lirc/lirc-0.8.6/drivers/lirc_mceusb/lirc_mceusb.ko \
       /lib/modules/`uname -r`/kernel/ubuntu/lirc/lirc_mceusb

Note that you may also need to replace the lirc_dev module if the new lirc_mceusb module references new symbols in lirc_dev. If that's the case, follow the same steps outlined herein for lirc_mceusb but substitute lirc_dev instead.

Check to see if the original module is loaded by the kernel and, if so, remove it:

     lsmod | grep lirc_mceusb
     sudo rmmod lirc_mceusb

Now, complete the install of the new module on the Mythbuntu machine:

     sudo depmod -a
     sudo insmod \
       /lib/modules/`uname -r`/kernel/ubuntu/lirc/lirc_mceusb/lirc_mceusb.ko

You can check whether the install is successful by doing:

     lsmod | grep lirc_mceusb

After you've completed all of the above, you must make the changes permanent. Mythbuntu boots from a RAM image of the kernel which will still have the old driver (if any) installed and the new driver missing. You need to update this image or the original driver will still get loaded. To update the RAM image:

     sudo update-initramfs -u

Reboot the machine to see if the changes are permanent and that the remote still works:

     sudo reboot

Then, test the updates that you've made accordingly.

Note that for later versions of the kernel and lirc (e.g. 3.2.0 and 0.9.0), mceusb is now one of the kernel drivers. Thus, mceusb.ko is now found in /lib/modules/`uname -r`/kernel/drivers/media/rc and you must build it as a kernel driver instead of as part of lirc. Hopefully, you won't have any need to do so but, if you do, make sure you have the driver build environment (this is not necessarily the full kernel build environment). To verify that you do have the driver build environment, try:

     ls -l /lib/modules/`uname -r`/build

If you have this directory installed, you're good to go (Mythbuntu usually provides them in a typical installation). Otherwise, you'll need to first get the build environment, either using the Package Manager or by doing:

     sudo apt-get install build-essential

Then, you should make sure to install the latest headers for your kernel:

     sudo apt-get install linux-headers-`uname -r`

Finally, if the link doesn't already exist, link the headers to the build folder in the proper place. This should get you compiling:

     sudo ln -s /usr/src/linux-headers-`uname -r` /lib/modules/`uname -r`/build

Download the latest version of the mceusb driver from the kernel sources Web site of your choice and place it in a convenient directory (you can build it in a subdirectory under your home directory, for example lirc_mceusb).

You can find lots of build instructions for kernel drivers on the Internet. Here's a link to a site that covers building the mceusb kernel module:

     http://www.hack-job.org/uncategorized/
          recompile-a-kernel-module-example-mceusb-c/

Apparently, it isn't necessary to place the driver in the system source tree any more, in order to build it (i.e. the way it used to be). Of course, you may opt to do this, if you wish, but we build it in our own directory. To do so, we create this makefile with our favorite editor:

.../lirc_mceusb/Makefile:

     obj-m = mceusb.o
     KVERSION = $(shell uname -r)
     all:
             make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
     clean:
             make -C /lib/modules/$(KVERSION)/build M=$(PWD) clean

Note that the whitespace before each of the indented "make" commands is a single tab, not a bunch of spaces.

Once you have the makefile, you can compile the driver like this:

     cd .../lirc_mceusb
     make

Now, install the mceusb.ko module into the system:

     sudo install -m 744 -c mceusb.ko
          /lib/modules/`uname -r`/kernel/drivers/media/rc

There could be an older version of the module that you are replacing. You can check, for example, if the mceusb module is installed as follows:

     lsmod | grep mceusb

If mceusb is installed then you should remove it:

     sudo rmmod mceusb

Now, complete the install of the new module on the machine:

     sudo depmod -a
     sudo insmod mceusb.ko

You can check whether the install is successful by doing:

     lsmod | grep mceusb

Once you've completed all of the above, you must make the changes permanent. Mythbuntu boots from a RAM image of the kernel which will still have the old driver installed and the new driver missing. You need to update this image or the old driver will still get loaded. To do so, update the RAM image:

     sudo update-initramfs -u

Reboot the machine to make the changes permanent:

     sudo reboot

Then, test the updates that you've made accordingly.

LIRC supports the Tira-2 so Mythbuntu should have support for it built in. You can check whether it does with the following command:

     lircd --driver=?

This will give a list of drivers that are built into the lircd that is installed on the system. If you see "tira", you should be in business and you can skip ahead to the irrecord step, below. However, some versions of Mythbuntu ship without tira being built into LIRC. To remedy this situation, if you don't see the tira driver in the list, you will first need to download the latest LIRC software from http://www.lirc.org/software.html.

Once you've downloaded the software, you can uncompress it and unpack it, then build LIRC with tira enabled:

     cd lirc
     tar -xvjf lirc-0.8.3.tar.bz2
     cd lirc-0.8.3
     ./configure --with-driver=tira
     make

To install the new lircd, become super user and do the install:

     sudo make install

This should put the new lircd in /usr/local/sbin while keeping the original in /usr/sbin -- handy if you need to fall back on the original lircd. You can now skip ahead to the part about using irrecord to record your remote's key codes.

For the Ira-2 or Ira-3 OEM serial IR receivers from Home Electro, the setup is essentially the same as the Tira-2, above. You should check whether Mythbuntu has support for serial devices built in with the following command:

     lircd --driver=?

This will give a list of drivers that are installed on the system. If you see "irman", you should be in business. You can skip ahead to the irrecord step, below. If you don't see the irman driver in the list, in order to get the Ira-2/3 to work, you will first need to download the latest LIRC software from http://www.lirc.org/software.html.

Once you've downloaded the software, you can uncompress it and unpack it, then build LIRC with tira enabled:

     cd lirc
     tar -xvjf lirc-0.8.3.tar.bz2
     cd lirc-0.8.3
     ./configure --with-driver=irman
     make

To install the new lircd, become super user and do the install:

     sudo make install

This should put the new lircd in /usr/local/sbin while keeping the original in /usr/sbin -- handy if you need to fall back on the original lircd. You can now skip ahead to the part about using irrecord to record your remote's key codes.

The Iguana Works USB iguanaIR driver requires a special daemon to operate with LIRC (consider carefully the repercussions on response time and the potential for lockup issues that are implied by this architecture). You can try applying the appropriate RPM or module from their Web site but we have found that we need to compile it ourselves, on Mythbuntu.

To begin with, the daemon needs a whole bunch of prerequisite modules to build properly. On Mythbuntu 9.04, the required modules are:

     python-dev
     libusb-1.0-0
     libusb-1.0-0-dev
     libpopt-dev
     swig

You can install these modules from the Synaptic package manager's GUI or you can use the following command line, once for each package:

     sudo apt-get install pkgname

Once you got all the prerequisites, you can download the latest daemon source from http://iguanaworks.net/downloads.php. After you've done that, uncompress it and unpack it, then build the Iguana daemon:

     cd iguana
     tar -xvjf iguanaIR-1.0pre2.tar.bz2
     cd iguanaIR-1.0pre2
     ./configure
     make

Install the new daemon and other modules into the system:

     sudo make install

At this point, you must reboot, since a new rule is added to /lib/udev/rules.d (named 80-iguanaIR.rules) that creates the /dev/iguanaIR directory and sets its ownership to iguanair:iguanair. This allows the driver to run as user iguanair, not root, which is much safer. However, if you don't reboot, the udev rule will not yet be applied and the next step will fail.

Incidentally, if you experience problems with the responsivness of the remote or just want to be preemptive, you may want to alter the iguanaIR startup script to set the nice level to -3. This will give the daemon a higher priority than other tasks in the system (although a lower priority than the really important ones). Change the lines that set the start parameters as follows:

/etc/init.d/iguanaIR:

.

           .
      # figure out what command to run to start the daemon
      #
      # Set the nice level to -3 so that the remote is more responsive.
      if [ "$LOCKFILE" != "" ]; then 
          if [ ! -e $LOCKFILE ]; then
              START="daemon --user=iguanair -3 $IGPATH $IGUANAIR_OPTIONS \
                  -l $LOGFILE"
          fi
      else
          START="start-stop-daemon --start --chuid iguanair \
              --group iguanair --nicelevel -3 --exec $IGPATH -- \
              $IGUANAIR_OPTIONS -l $LOGFILE"
      fi
           .
           .
           .

Another problem with the startup script is that the Iguana install script sets it up to start in the wrong order. If you use the default installation of LIRC, it will probably start lirc in runlevels 2,3,4,5 at step 19. The Iguana install script sets iguanaIR up to run at step 20. Basically, its a race. Sometimes iguanaIR wins and all is fine. Sometimes lirc beats it to the punch and the remote disappears. Swell.

The fix is to start iguanaIR earlier on, before lirc is even started. You can list the contents of the runlevel 5 directory and see whether the start order is wrong. Enter this command:

     ls -l /etc/rc5.d

If you see:

     /etc/rc5.d/S19lirc --> ./init.d/lirc
     /etc/rc5.d/S20iguanaIR --> ./init.d/iguanaIR

You've got the makings of a race condition. The following commands should fix it:

     sudo rm -f /etc/rc*.d/S20iguanaIR
     sudo ln -s ../init.d/iguanaIR /etc/rc2.d/S15iguanaIR
     sudo ln -s ../init.d/iguanaIR /etc/rc3.d/S15iguanaIR
     sudo ln -s ../init.d/iguanaIR /etc/rc4.d/S15iguanaIR
     sudo ln -s ../init.d/iguanaIR /etc/rc5.d/S15iguanaIR

Note that we picked step 15 in runlevels 2,3,4,5 because there is nothing in between step 15 and step 19 (when lirc is started) that iguanaIR should depend on. If there is, you could change it to start at a later step. You could even move lirc, if you have to. However, starting iguanaIR at step 15 does the trick (eliminating the race) and hasn't caused any side effects as far as we can tell.

Once you've made your changes to the startup script (or not), start up the Iguana daemon:

     sudo /etc/init.d/iguanaIR start

Test it with:

     igclient --receiver-on --sleep 10

You should see commands being sent to the driver and the results being echoed for about 10 seconds, if all is well. If not, proceed to the IguanaWorks troubleshooting page:

     http://iguanaworks.net/projects/IguanaIR/wiki/TroubleShooting

Make sure that the Iguana device driver is started at the proper runlevels (2, 3, 4, and 5). To do this, using the dain-bramaged update-rc.d, run:

     sudo update-rc.d iguanaIR defaults

If you're on a regular system that uses chkconfig, you know what to do.

Now, as noted above for the other drivers, download the latest LIRC software from http://www.lirc.org/software.html, uncompress it and unpack it, then build LIRC with iguanaIR enabled:

     cd lirc
     tar -xvjf lirc-0.8.3.tar.bz2
     cd lirc-0.8.3
     ./configure --with-driver=iguanaIR
     make

To install the new lircd, become super user and do the install:

     sudo make install

Once again, this should put the new lircd in /usr/local/sbin while keeping the original in /usr/sbin where you can get to it if you need to fall back on the original lircd.

Since the new lircd is installed in a different location than the original, we need to modify /etc/init.d/lirc to invoke it. We can choose to do this by adding a new variable called LOAD_PATH that we set to "/usr/local/sbin". We then change all occurrences of /usr/sbin to ${LOAD_PATH}. This lets us change back to the original lircd, if need be.

Also, in some versions of the lirc startup script, it appears that someone forgot about the need to create the /var/run/lirc directory. We can fix this by adding a line in the start routine to create /var/run/lirc.

And, speaking of forgetting things, the hardware.conf file has pointers to two config files, one for the remote and one for the transmitter. Unfortunately, the lircd daemon always loads its config from /etc/lirc/lircd.conf and the two config files pointed to by hardware.conf are ignored. Consequently if you'd like to use two remote config files, one for your actual remote, and one for blasting your cable box, something needs to be done to make up a composite lircd.conf on the fly, using the two named config files (however, you should be careful with this change, if you aren't going to be setting the proper config file name in hardware.conf, since it will break any pre-existing lircd.conf).

Some later versions of lirc create the sockets needed for communication with their client in /var/run/lirc whereas your version of MythTV may expect to find them in /dev. This comes as a huge surprise to MythTV which petulantly refuses to talk to lircd. Consequently, the startup script may need to be modified to always tell lircd to create a pipe named /dev/lircd or /var/run/lirc/lircd instead of where it thinks the pipe should go. Bear this in mind, if all else in your remote setup is perfect and MythTV still won't talk to the remote. The startup script can be made to force the use of one socket name or another, as your MythTV requires.

Finally, you may experience problems with sluggish response from your remote control at times when the system is busy. Since the user typically believes (and who's to argue with them) that the system should always respond promptly to their commands, such sluggish response may not be acceptable. Setting the nice level of lircd to give it a higher priority may help. If you wish to try it, that change can be made in the startup script too.

Here's the complete, modified, startup script:

/etc/init.d/lirc:

     #! /bin/sh
     ### BEGIN INIT INFO
     # Provides:          lirc
     # Required-Start:    $remote_fs $syslog
     # Required-Stop:     $remote_fs $syslog
     # Default-Start:     2 3 4 5
     # Default-Stop:      0 1 6
     # Short-Description: Starts LIRC daemon.
     # Description:       LIRC is used to control different
     #                    infrared receivers and transceivers.
     ### END INIT INFO
     # Where we load lircd and lircmd from.
     LOAD_PATH=/usr/sbin
     # LOAD_PATH=/usr/local/sbin
     # The old name where lirc used to put its socket.  Some programs may still
     # look there.
     #
     # If this variable is defined, a symlink will be made when lircd is started
     # and removed when it is stopped.
     OLD_SOCKET="/dev/lircd"
     load_modules ()
     {
         local MODULES_MISSING=false
      log_daemon_msg "Loading LIRC modules"
      for mod in $*; do
          if [ $mod = "udev" ]; then
              log_end_msg 0
              log_success_msg "Restarted via udev, don't reload modules"
              break
          else
              modprobe $mod 2> /dev/null || MODULES_MISSING=true
          fi
      done
      log_end_msg $?
      if $MODULES_MISSING; then
          log_failure_msg "Unable to load LIRC kernel modules. Verify your"
          log_failure_msg "selected kernel modules in /etc/lirc/hardware.conf"
          START_LIRCMD=false
          START_LIRCD=false
      fi

}

     build_remote_args ()
     {
         local REMOTE_ARGS="$*"
      #For remote only detection support, we need
      #both REMOTE_DEVICE and TRANSMITTER_DEVICE undefined
      if [ -z "$REMOTE_DEVICE" ] && [ -z "$TRANSMITTER_DEVICE" ]; then
          for dev in /dev/lirc0; do
              if [ -c $dev ]; then
                  REMOTE_DEVICE="$dev"
                  break
              fi
          done
      fi
      #If we have a REMOTE_DEVICE or REMOTE_DRIVER defined (either because
      #no devices were defined, OR if we explicitly did), then populate
      #REMOTE_ARGS
      if [ ! -z "$REMOTE_DEVICE" ] || [ ! -z "$REMOTE_DRIVER" ]; then
          if [ -n "$REMOTE_DEVICE" ] && [ "$REMOTE_DEVICE" != "none" ]; then
              REMOTE_ARGS="--device=$REMOTE_DEVICE $REMOTE_ARGS"
          fi
          if [ -n "$REMOTE_DRIVER" ] && [ "$REMOTE_DRIVER" != "none" ]; then
              REMOTE_ARGS="--driver=$REMOTE_DRIVER $REMOTE_ARGS"
          fi
          #Now, if we ALSO have a transmitter defined, add some args
          #To make the first lircd listen up
          if [ ! -z "$TRANSMITTER_DEVICE" ] \
              || [ ! -z "$TRANSMITTER_DRIVER" ]; then
              REMOTE_ARGS="$REMOTE_ARGS --listen"
          fi
          #Because there's some confusion with locally-compiled versions of
          #lircd over what our pipe name is, let's make sure we're all
          #talking on the same one.
          REMOTE_ARGS="$REMOTE_ARGS --output=$REMOTE_SOCKET"
      fi
    
      echo $REMOTE_ARGS

}

     build_transmitter_args ()
     {
         local TRANSMITTER_ARGS="$*"
      #Transmitters must be explicitly be defined
      if [ ! -z "$TRANSMITTER_DEVICE" ] \
          || [ ! -z "$TRANSMITTER_DRIVER" ]; then
          if [ -n "$TRANSMITTER_DEVICE" ] \
              && [ "$TRANSMITTER_DEVICE" != "none" ]; then
              TRANSMITTER_ARGS="--device=$TRANSMITTER_DEVICE $TRANSMITTER_ARGS"
          fi
          if [ -n "$TRANSMITTER_DRIVER" ] \
              && [ "$TRANSMITTER_DRIVER" != "none" ]; then
              TRANSMITTER_ARGS="--driver=$TRANSMITTER_DRIVER $TRANSMITTER_ARGS"
          fi
          # Now, if we ALSO have a remote defined, add some args
          # to make the second lircd connect.
          if [ ! -z "$REMOTE_DEVICE" ] || [ ! -z "$REMOTE_DRIVER" ]; then
              TRANSMITTER_ARGS="$TRANSMITTER_ARGS \
                  --output=$TRANSMITTER_SOCKET --connect=localhost:8765 \
                  --pidfile=/var/run/lircd1.pid"
          # Otherwise, because there's some confusion with locally-compiled
          # versions of lircd over what our pipe name is, let's make sure
          # we're all talking on the same one.
          else
              TRANSMITTER_ARGS="$TRANSMITTER_ARGS --output=$TRANSMITTER_SOCKET"
          fi
      fi
      echo $TRANSMITTER_ARGS

}

     in_kernel_support()
     {
         if [ -d /sys/class/rc ]; then
             for file in `find /sys/class/rc/*/ -name protocols`; do
                 if [ "$1" = "disable" ]; then
                     echo "lirc" > $file
                 else
                     echo "none" > $file
                     for protocol in `cat $file`; do
                         echo "+${protocol}" > $file
                     done
                 fi
             done
         fi
     }
     . /lib/lsb/init-functions
     test -f ${LOAD_PATH}/lircd || exit 0
     test -f ${LOAD_PATH}/lircmd || exit 0
     START_LIRCMD=true
     START_LIRCD=true
     START_IREXEC=true
     if [ -f /etc/lirc/hardware.conf ];then
         . /etc/lirc/hardware.conf
     fi
     # The hardware.conf file has pointers to two config files, one for the
     # remote and one for the transmitter.  Unfortunately, the lircd daemon
     # always loads its config from /etc/lirc/lircd.conf and the two config files
     # pointed to by hardware.conf are ignored.  Nice, huh?  Consequently, we
     # make up lircd.conf on the fly, here, from the two named config files.
     if [ -n "$1" ] && [ "$1" = "start" ]; then
         rm -f /etc/lirc/lircd.conf >/dev/null 2>&1
      if [ -n "$REMOTE_LIRCD_CONF" ] \
          && [ "$REMOTE_LIRCD_CONF" != "none" ]; then
          cat $REMOTE_LIRCD_CONF >/etc/lirc/lircd.conf
          if [ -n "$TRANSMITTER_LIRCD_CONF" ] \
              && [ "$TRANSMITTER_LIRCD_CONF" != "none" ]; then
              cat $TRANSMITTER_LIRCD_CONF >>/etc/lirc/lircd.conf
          fi
      else
          if [ -n "$TRANSMITTER_LIRCD_CONF" ] \
              && [ "$TRANSMITTER_LIRCD_CONF" != "none" ]; then
              cat $TRANSMITTER_LIRCD_CONF >/etc/lirc/lircd.conf
          fi
      fi
      # Here we test to see if anyone has configured the lircd.conf file.  If
      # we made one up (above), it should be configured.  If not, there may
      # be a default one that was put there by install.  It is possible that
       the user configured this file.  If not, we don't start lirc.
      if [ ! -f /etc/lirc/lircd.conf ] \
          || grep -q "^UNCONFIGURED"  /etc/lirc/lircd.conf;then
          if [ "$1" = "start" ]; then
              log_success_msg "No valid /etc/lirc/lircd.conf has been found."
              log_success_msg "Remote control support has been disabled."
              log_success_msg "Reconfigure LIRC or manually replace \
                  /etc/lirc/lircd.conf to enable."
          fi
          START_LIRCD=false
          START_LIRCMD=false
          START_IREXEC=false
      fi

fi

     # Here we test to see if anyone has configured the lircmd.conf file.  If
      not, we don't start lircmd.
     if [ ! -f /etc/lirc/lircmd.conf ] \
         || grep -q "^UNCONFIGURED" /etc/lirc/lircmd.conf; then
         START_LIRCMD=false
     fi
     # Here we test to see if anyone has configured the lircrc.conf file.  If
      not, we don't start irexec.
     if [ ! -f /etc/lirc/lircrc ] \
         || grep -q "^UNCONFIGURED" /etc/lirc/lircrc; then
         START_IREXEC=false
     fi
     # The user can define which pipe path to use.  The default is /var/run/lirc
     # but this can be overridden.
     if [ -n "$PIPE_PATH" ] && [ "$PIPE_PATH" != "none" ]; then
         OUTPUT_PATH=$PIPE_PATH
     else
         OUTPUT_PATH="/var/run/lirc"
     fi
     # The user can define what socket names to use.  The defaults are "lirc"
     # and "lirc1".
     if [ -z "$REMOTE_SOCKET" ]; then
         REMOTE_SOCKET="${OUTPUT_PATH}/lircd"
     else
         REMOTE_SOCKET="${OUTPUT_PATH}/${REMOTE_SOCKET}"
     fi
     if [ -z "$TRANSMITTER_SOCKET" ]; then
         TRANSMITTER_SOCKET="${OUTPUT_PATH}/lircd"
      # Now, if we ALSO have a remote defined, change the default
      # transmitter socket.
      if [ ! -z "$REMOTE_DEVICE" ] || [ ! -z "$REMOTE_DRIVER" ]; then
          TRANSMITTER_SOCKET="${TRANSMITTER_SOCKET}1"
      fi
  else
      TRANSMITTER_SOCKET="${OUTPUT_PATH}/${TRANSMITTER_SOCKET}"

fi

     # Process the command given to this script (e.g. start, stop).
     case "$1" in
      # Start up all of the daemons.
      start)
          if [ "$LOAD_MODULES" = "true" ] && [ "$START_LIRCD" = "true" ]; then
              load_modules $2 $REMOTE_MODULES $TRANSMITTER_MODULES $MODULES
              in_kernel_support "disable"
          fi
          # If we're starting the lirc daemon, do it now.
          if [ "$START_LIRCD" = "true" ]; then
              # If the socket/pid directory isn't there, create it.
              if [ ! -d $OUTPUT_PATH ]; then
                  mkdir -p $OUTPUT_PATH >/dev/null 2>&1
              fi
              log_daemon_msg "Starting remote control daemon(s) : LIRC "
              REMOTE_LIRCD_ARGS=`build_remote_args $REMOTE_LIRCD_ARGS`
              TRANSMITTER_LIRCD_ARGS=`build_transmitter_args \
                  $TRANSMITTER_LIRCD_ARGS`
              # If we have a remote defined, it is the primary process
              #
              # We'll set the nice level of this process so that the remote
              # control is more responsive.
              if [ ! -z "$REMOTE_LIRCD_ARGS" ]; then
                  start-stop-daemon --start --quiet --nicelevel -5 \
                      --exec ${LOAD_PATH}/lircd -- $REMOTE_LIRCD_ARGS \
                      </dev/null
                  log_end_msg $?
                  # If an old socket is named, symlink it to the one that lirc
                  # is using now.  Note that, because of the "&&", the symlink
                  # is only put in if the old socket exists.
                  if [ -S "$REMOTE_SOCKET" \
                      -a "$OLD_SOCKET" != "$REMOTE_SOCKET" ]; then
                      rm -f $OLD_SOCKET \
                          && ln -s $REMOTE_SOCKET $OLD_SOCKET
                  fi
                  # Now, if we additionally have a transmitter defined, it
                  # is secondary process.
                  if [ ! -z "$TRANSMITTER_LIRCD_ARGS" ]; then
                      ${LOAD_PATH}/lircd $TRANSMITTER_LIRCD_ARGS < /dev/null
                      # If an old socket is named, symlink it to the one that
                      # lirc is using now.  Note that, because of the "&&",
                      # the symlink is only put in if the old socket exists.
                      if [ -S "$TRANSMITTER_SOCKET" ]; then
                          rm -f ${OLD_SOCKET}1 \
                              && ln -s $TRANSMITTER_SOCKET ${OLD_SOCKET}1
                      fi 
                  fi
              # Otherwise, if there's a transmitter defined, it is the
              # primary process.
              elif [ ! -z "$TRANSMITTER_LIRCD_ARGS" ]; then
                  start-stop-daemon --start --quiet \
                      --exec ${LOAD_PATH}/lircd -- $TRANSMITTER_LIRCD_ARGS \
                      </dev/null
              # Otherwise, we're done.
              else
                  log_end_msg 1
              fi
          fi
          # If we're starting the mouse daemon, do it now.
          if [ "$START_LIRCMD" = "true" ]; then
              # If the socket/pid directory isn't there, create it.
              if [ ! -d $OUTPUT_PATH ]; then
                  mkdir -p $OUTPUT_PATH >/dev/null 2>&1
              fi
              log_daemon_msg "Starting remote control mouse daemon : LIRCMD "
              start-stop-daemon --start --quiet \
                  --exec ${LOAD_PATH}/lircmd </dev/null
              log_end_msg $?
          fi
          # If we're starting the execution daemon, do it now.
          if [ "$START_IREXEC" = "true" ]; then
              # If the socket/pid directory isn't there, create it.
              if [ ! -d $OUTPUT_PATH ]; then
                  mkdir -p $OUTPUT_PATH >/dev/null 2>&1
              fi
              log_daemon_msg "Starting execution daemon: irexec"
              start-stop-daemon --start --quiet --oknodo \
                  --exec ${LOAD_PATH}/irexec -- -d /etc/lirc/lircrc \
                  </dev/null
              log_end_msg $?
          fi
          ;;
      # Shut down all of the daemons.
      stop)
          in_kernel_support "enable"
          # If we're started the execution daemon, do it now.
          if [ "$START_IREXEC" = "true" ]; then
              log_daemon_msg "Stopping execution daemon: irexec"
              start-stop-daemon --stop --quiet --exec ${LOAD_PATH}/irexec
              log_end_msg $?
          fi
          # If we're started the mouse daemon, do it now.
          if $START_LIRCMD; then
              log_daemon_msg "Stopping remote control mouse daemon: LIRCMD"
              start-stop-daemon --stop --quiet --exec ${LOAD_PATH}/lircmd
              log_end_msg $?
          fi
          # If we're started the lirc daemon, do it now.
          if $START_LIRCD; then
              log_daemon_msg "Stopping remote control daemon(s): LIRC"
              start-stop-daemon --stop --quiet --exec ${LOAD_PATH}/lircd
              log_end_msg $?
          fi
          ;;
      # Reload signals all of the daemons to reload their config.
      reload|force-reload)
          if [ "$START_IREXEC" = "true" ]; then
              start-stop-daemon --stop --quiet --signal 1 \
                  --exec ${LOAD_PATH}/irexec
          fi
          if [ "$START_LIRCD" = "true" ]; then
              start-stop-daemon --stop --quiet --signal 1 \
                  --exec ${LOAD_PATH}/lircd
          fi
          if $START_LIRCMD; then
              start-stop-daemon --stop --quiet --signal 1 \
                  --exec ${LOAD_PATH}/lircmd
          fi
          ;;
      # Restarts the service by shutting everything down and then starting
      # it back up.
      #
      # Note that, when we restart, we pass parameter $2, which is possibly
      # our udev paramater.
      restart)
          $0 stop
          $0 start $2
          ;;
      *)
          echo "Usage: /etc/init.d/lircd {start|stop|reload|restart|\
              force-reload}"
          exit 1

esac

     exit 0

For later versions of Mythbuntu, many of the services that are necessary to run the system have been migrated to upstart. Fortunately for us, as of Mythbuntu 12.04, this hasn't happened to LIRC yet. So, the script that is shown above can still be used with the latest Mythbuntu. As a matter of fact, you can probably just use the LIRC that is pre-installed on the system (no need to build the latest one because the OS probably comes with the latest one). To do this, you simply have to switch the load path as follows:

     # Where we load lircd and lircmd from.
     LOAD_PATH=/usr/sbin
     # LOAD_PATH=/usr/local/sbin

If your system already had the appropriate driver built into lircd or you've successfully installed the updated LIRC software, its time to record all of the key codes that are generated by the remote that you wish to use with Mythbuntu. These steps are repeated for each remote that you wish to use or every time that you add a new remote.

Begin by making sure that lircd is not running (if you are not doing this for the first time) and then record the buttons as follows (picking the appropriate invocation of irrecord, depending on which IR receiver you are using, and being sure to use the correct installation of irrecord, if you built the source from scratch):

     [sudo /etc/init.d/lirc stop]
     sudo irrecord -n MCEUSB_myremote.conf
     sudo irrecord -n -H tira -d /dev/ttyUSB0 Tira-2_myremote.conf
     sudo irrecord -n -H irman -d /dev/ttyS0 Ira_myremote.conf
     sudo irrecord -n -H iguanaIR -d /dev/iguanaIR/0 Iguana_myremote.conf

If you have problems with irrecord recognizing the keys on your remote, you can run it in raw mode and then deal with the problems post-facto:

     [sudo /etc/init.d/lirc stop]
     sudo irrecord -f -n MCEUSB_myremote.conf
     sudo irrecord -f -n -H tira -d /dev/ttyUSB0 Tira-2_myremote.conf
     sudo irrecord -f -n -H irman -d /dev/ttyS0 Ira_myremote.conf
     sudo irrecord -f -n -H iguanaIR -d /dev/iguanaIR/0 Iguana_myremote.conf

Essentially, once you're running irrecord, you should follow its instructions. Be sure to carry out the first steps exactly (i.e. keep pressing keys or holding down a single key, as it instructs, until it tells you to stop) so that the correct gap is found and irrecord figures out how to decode the raw data. Also, at the end, press a single key rapidly so that the toggle bits can be figured out. If you fail to do these tasks properly, the remote will not be set up correctly.

Incidentally, there may be a problem when some remotes are being recorded by some IR receivers (e.g. the Sony TiVo remotes with any of the irman serial receivers). In these cases, irrecord asks you to press and hold a single key until it can figure out the correct gap. However, this depends on the remote's key being typematic (i.e. repeats automatically at a rapid rate, when held). If the "arbitrary" key that you hold down isn't typematic or doesn't repeate at a fast enough rate, irrecord won't be able to figure things out. To get it to work, you need to pick a key that is typematic and repeats fast enough (you should see a good stream of dots forming in short order). Often, the volume controls on a remote (if it has them) are typematic and work quite well when irrecord asks you to hold down an "arbitrary" key.

Once the initial phase of remote setup is completed, irrecord proceeds to capturing each of the remote's key codes. For each of the keys, you enter the key name on the computer's keyboard, press the enter key, and then press the remote's key and hold it until irrecord can identify its key code and record it. Try to give the keys meaningful names that can be used in the various LIRC config files.

If you want the remote to work with other applications (especially the script that auto-generates the MythTV config files -- you'll thank me for this later), pick the common key names from this list:

     ArrowDown
     ArrowLeft
     ArrowRight
     ArrowUp
     ChannelUp
     ChannelDown
     Eight  (the number 8)
     Enter
     Exit
     Five  (the number 5)
     Forward
     Four  (the number 4)
     Guide
     Home
     Info
     List
     Menu
     Mute
     Nine  (the number 9)
     One  (the number 1)
     Pause
     Play
     Power
     Record
     Replay
     Return
     Rewind
     Seven  (the number 7)
     Six  (the number 6)
     Skip
     Stop
     Three  (the number 3)
     Two  (the number 2)
     VolumeDown
     VolumeUp
     Zero  (the number 0)

For other keys that don't appear on this list, you can examine one or more .lircrc files (e.g. for your favorite application) to see what names are common. The names that you choose will be used to map the LIRC keypress codes to your application's control commands so making them meaningful is a good idea. Also, it is best to know what names you'll be using for all of the remote's keys before you begin so that you won't have to go looking once you start. Just for the sake of having a plan, I usually start with the top-left key on the remote and work my way down to the bottom-right so having the key names printed out in that order is helpful.

Once you have recorded your remote or remotes, you should join all of the config files together, for all of the remotes that you wish to use simultaneously, into a single lircd.conf file in /etc/lirc. It should look something like this (let's assume we want to use either the Sony or the Philips TiVo remote, or the Samsung TV remote to run Mythbuntu, depending on which one is closer to hand):

/etc/lirc/lircd.conf:

     # ========================  Tira-2_TiVoSony.conf  ==========================
     # Please make this file available to others
     # by sending it to <lirc@bartelmus.de>
     #
     # this config file was automatically generated
     # using lirc-0.8.3(tira) on Thu May 15 13:21:08 2008
     #
     # contributed by: xxx@yyy.com (Xxx Yyy)
     #
     # brand: Home Electro Tira-2 xceiver
     # model no. of remote control: TiVo (Sony) (RMT-V303)
     # devices being controlled by this remote: MythTV (Mythbuntu)
     #
     begin remote
     name  TiVoSony
     bits           48
     eps            30
     aeps          100
     one             0     0
     zero            0     0
     pre_data_bits   8
     pre_data       0x0
     post_data_bits  8
     post_data      0x0
     gap          149967
     toggle_bit_mask 0x0
        begin codes
            Power                    0xC0FF49BF5EC3
            TVPower                  0xFF3C75000000  # Programmable by user
            Menu                     0xC003748C5DC3  # TiVo logo on button
            Guide                    0xC0C3B7735DC3
            List                     0xC00F874F5DC3
            UpArrow                  0xC0F348835DC3
            DownArrow                0xC003964352C3
            LeftArrow                0xC003974F51C3
            RightArrow               0xC00386735EC3
            Select                   0xC0F358B351C3
            ThumbsDown               0xC0C3B67F5EC3
            ThumbsUp                 0xC0C3A64F52C3
            Mute                     0xFF3F65000000  # TiVo logo on button
            Record                   0xC0FF8A8F5EC3
            Play                     0xC0FFAB7051C3
            Back                     0xC0FFBB405DC3
            Forward                  0xC0FF9ABF52C3
            Pause                    0xC0FFBA4C5EC3
            Slow                     0xC00F447F5DC3
            Replay                   0xC0F378405DC3
            Skip                     0xC0C3A74351C3
            VolumeUp                 0xFF3F54000000  # TiVo logo on button
            VolumeDown               0xFF3F44000000  # TiVo logo on button
            ChannelUp                0xC0FF694C52C3
            ChannelDown              0xC0FF797C5EC3
            One                      0xC03F594052C3
            Two                      0xC03F49705EC3
            Three                    0xC03F584C51C3
            Four                     0xC03F487C5DC3
            Five                     0xC03F698352C3
            Six                      0xC03F79B35EC3
            Seven                    0xC03F688F51C3
            Eight                    0xC03F78BF5DC3
            Nine                     0xC03F9A7052C3
            Zero                     0xC03F8A405EC3
            Clear                    0xC003877F5DC3
            Enter                    0xC03F8B4C5DC3
        end codes
     end remote
     # =======================  Tira-2_TiVoPhilips.conf  ========================
     # Please make this file available to others
     # by sending it to <lirc@bartelmus.de>
     #
     # this config file was automatically generated
     # using lirc-0.8.3(tira) on Thu May 15 06:22:55 2008
     #
     # contributed by: xxx@yyy.com (Xxx Yyy)
     #
     # brand: Home Electro Tira-2 xceiver
     # model no. of remote control: TiVo (Philips) Peanut (SBOM-00004-000)
     # devices being controlled by this remote: MythTV (Mythbuntu)
     #
     begin remote
     name  TiVoPhilips
     bits           48
     eps            30
     aeps          100
     one             0     0
     zero            0     0
     pre_data_bits   8
     pre_data       0x0
     post_data_bits  8
     post_data      0x0
     gap          207966
     min_repeat      2
     toggle_bit_mask 0x0
        begin codes
            Power                    0xFF3C75000000  # Programmable by user
            Menu                     0xA914FDFF5FFF  # TiVo logo on button
            Guide                    0x29147D7F5FFF
            UpArrow                  0x29147DF75FFF
            DownArrow                0x29147DD75FFF
            LeftArrow                0x29147D575FFF
            RightArrow               0x29147D775FFF
            Select                   0x29147D7D5FFF
            ThumbsDown               0x29147DFD5FFF
            ThumbsUp                 0x29147DDD5FFF
            Mute                     0xFF3C65000000  # Programmable by user
            Record                   0x8914DDFF5FFF
            Play                     0x8914DD7F5FFF
            Back                     0x8914DDDF5FFF
            Forward                  0x8914DDF75FFF
            Pause                    0x8914DD5F5FFF
            Slow                     0x8914DD775FFF
            Replay                   0x8914DDD75FFF
            Skip                     0x8914DD575FFF
            VolumeUp                 0xFF3C54000000  # Programmable by user
            VolumeDown               0xFF3C44000000  # Programmable by user
            ChannelUp                0x29147DD55FFF
            ChannelDown              0x29147D555FFF
            One                      0x8914DDFD5FFF
            Two                      0x8914DD7D5FFF
            Three                    0x8914DDDD5FFF
            Four                     0x8914DD5D5FFF
            Five                     0x8914DDF55FFF
            Six                      0x8914DD755FFF
            Seven                    0x8914DDD55FFF
            Eight                    0x8914DD555FFF
            Nine                     0x09145DFF5FFF
            Zero                     0x09145D7F5FFF
            Clear                    0x09145DDF5FFF
            Enter                    0x09145D5F5FFF
        end codes
     end remote
     # =====================  Tira-2_SamsungLN32A450.conf  ======================
     # Please make this file available to others
     # by sending it to <lirc@bartelmus.de>
     #
     # this config file was automatically generated
     # using lirc-0.8.4a(tira) on Sat Jan 23 19:28:51 2010
     #
     # contributed by: xxx@yyy.com (Xxx Yyy)
     #
     # brand: Home Electro USB Tira-2
     # model no. of remote control: Samsung LN32A450 TV (BN59-00687A)
     # devices being controlled by this remote: MythTV (Mythbuntu)
     #
     # Codes marked with "x" should not be used because the display interprets
     # them under all conditions (e.g. Power).
     #
     # Codes marked with "*" can be used but the display pops up an annoying
     # idiot message about the key not being available right now.  These keys
     # are good for displaying things like the OSD (i.e. something that will
     # hang around for awhile until the annoying message goes away).
     #
     # Codes marked with "M" work OK but they actually do something when the
     # Menu button is pressed and the Menu is displayed.  If you map these keys,
     # you probably should exit your application before you enter the display's
     # Menu.
     #
     begin remote
     name  SamsungLN32A450
     bits            48
     eps             30
     aeps            100
     one             0     0
     zero            0     0
     pre_data_bits   8
     pre_data        0x0
     post_data_bits  8
     post_data       0x0
     gap             207962
     min_repeat      1
     toggle_bit_mask 0x0
        begin codes
            Power                    0xFF17FC9FFF07    # x
            TVMode                   0x7F907D18FE07    # x
            Source                   0xFFF7FD7FFE07    # x
            One                      0xFF6FFCE7FF07    # *
            Two                      0xFFEFFD67FE07    # *
            Three                    0xFF0FFC87FF07    # *
            Four                     0xFF71FCF9FF07    # *
            Five                     0xFFF1FD79FE07    # *
            Six                      0xFF11FC99FF07    # *
            Seven                    0xFF69FCE1FF07    # *
            Eight                    0xFFE9FD61FE07    # *
            Nine                     0xFF09FC81FF07    # *
            Zero                     0x7FF67D7EFE07    # *
            Minus                    0x9F979D1FFE07    # *
            Previous                 0x7F967D1EFE07    # *  - Pre-Ch button
            VolumeUp                 0xFF8FFD07FE07    # x
            VolumeDown               0xFF91FD19FE07    # x
            Mute                     0xFF89FD01FE07    # x
            ChannelUp                0x7F167C9EFF07    # x
            ChannelDown              0x7F767CFEFF07    # x
            List                     0x87918519FE07    # *  - Ch. List button
            Menu                     0x7F107C98FF07    # x
            ClosedCaption            0x9FEF9D67FE07    # *  - CC button
            Tools                    0xE791E519FE07    # x  - Tools button
            Info                     0x7F887D00FE07    # x
            Return                   0x677064F8FF07    # M  - Return button
            Exit                     0x9FE99D61FE07    # xM
            ArrowUp                  0x877784FFFF07    # M  - In circular
                                                       #       button cluster
            ArrowDown                0x87F7857FFE07    # M
            ArrowLeft                0x87EF8567FE07    # M
            ArrowRight               0x8717849FFF07    # M
            Enter                    0x877184F9FF07    # M
            Red                      0x876984E1FF07    # Red button
            Green                    0x7F6E7CE6FF07    # Green button
            Yellow                   0x7FEE7D66FE07    # Yellow button
            Blue                     0x7F0E7C86FF07    # Blue button
            SRSButton                0x87098481FF07    # x  - SRS button
            MTSButton                0xFF77FCFFFF07    # x  - MTS button
            DMAButton                0x8797851FFE07    # x  - DMA button
            EMode                    0x796E7AE6FF07    # x  - E. Mode button
            PSize                    0x1F081C80FF07    # x  - P. Size button
            FavoriteChannel          0xE76FE4E7FF07    # x  - Fav. Ch. button
            Rewind                   0xE7EFE567FE07
            Pause                    0xE711E499FF07
            FastForward              0xE771E4F9FF07
            Record                   0xE7F1E579FE07
            Play                     0xE78FE507FE07
            Stop                     0xE70FE487FF07
        end codes
     end remote

As long as the codes are different for each remote, you can have as many remotes defined as you want. LIRC will figure out which one is being used by the codes that it receives. Thus, you can control one system with several remotes, if you're that ambitious.

LIRC needs a hardware configuration file to tell it what remote and IR blaster drivers to use, etc. This file should be set up now and should look something like this (the combined file, above, is used with a USB Tira-2):

/etc/lirc/hardware.conf:

     # /etc/lirc/hardware.conf
     #
     #Chosen Remote Control
     REMOTE="Combined"
     REMOTE_MODULES=""
     REMOTE_DRIVER="tira"
     REMOTE_DEVICE="/dev/ttyUSB0"
     REMOTE_LIRCD_CONF="/etc/lirc/lircd.conf"
     REMOTE_LIRCD_ARGS=""
     #Chosen IR Transmitter
     TRANSMITTER="None"
     TRANSMITTER_MODULES=""
     TRANSMITTER_DRIVER=""
     TRANSMITTER_DEVICE=""
     TRANSMITTER_LIRCD_CONF=""
     TRANSMITTER_LIRCD_ARGS=""
     #Enable lircd
     START_LIRCD="true"
     #Don't start lircmd even if there seems to be a good config file
     #START_LIRCMD="false"
     #Try to load appropriate kernel modules
     LOAD_MODULES="false"
     # Default configuration files for your hardware if any
     LIRCMD_CONF=""
     #Forcing noninteractive reconfiguration
     #If lirc is to be reconfigured by an external application
     #that doesn't have a debconf frontend available, the noninteractive
     #frontend can be invoked and set to parse REMOTE and TRANSMITTER
     #It will then populate all other variables without any user input
     #If you would like to configure lirc via standard methods, be sure
     #to leave this set to "false"
     FORCE_NONINTERACTIVE_RECONFIGURATION="false"
     START_LIRCMD=""

As another example, the hardware.conf file for a Samsung LN32A450 remote, used with a USB IguanaIR, should include this section for the remote:

     #Chosen Remote Control
     REMOTE="SamsungLN32A450"
     REMOTE_MODULES=""
     REMOTE_DRIVER="iguanaIR"
     REMOTE_DEVICE="/dev/iguanaIR/0"
     REMOTE_LIRCD_CONF="/etc/lirc/lircd.conf"
     REMOTE_LIRCD_ARGS=""

Finally, in this example a singel Philips TiVo remote is used with a serial Ira:

     #Chosen Remote Control
     REMOTE="TiVoPhilips"
     REMOTE_MODULES=""
     REMOTE_DRIVER="irman"
     REMOTE_DEVICE="/dev/ttyS0"
     REMOTE_LIRCD_CONF="/etc/lirc/lircd.conf"
     REMOTE_LIRCD_ARGS=""

If you want, you can give your config files meaningful names, based on the remote or class of remotes that they represent and then copy those files to the /etc/lirc directory, whereupon they can be symlinked to the proper file names. For example:

     sudo ln -s Ira_TiVoPhilips-hardware.conf hardware.conf
     sudo ln -s TiVoRemotes-lircd.conf lircd.conf

Incidentally, if you made the modifications to /etc/init.d/lirc, mentioned above, to allow the hardware.conf file to correctly specify which lircd config file should be used for the receiver and transmitter, you can have descriptions for the same remote under different receivers, in different files, and select them in the config file. For example, here's the same Samsung LN34A450 remote (shown in the combined file, above) as it would appear to an Iguana Works receiver:

/etc/lirc/IguanaIR_SamsungLN32A450.conf:

     # ====================  IguanaIR_SamsungLN32A450.conf  =====================
     # Please make this file available to others
     # by sending it to <lirc@bartelmus.de>
     #
     # this config file was automatically generated
     # using lirc-0.8.6(iguanaIR) on Fri Jan 22 14:30:37 2010
     #
     # contributed by: xxx@yyy.com (Xxx Yyy)
     #
     # brand: Iguana Works USB iguanaIR
     # model no. of remote control: Samsung LN32A450 TV (BN59-00687A)
     # devices being controlled by this remote: MythTV (Mythbuntu)
     #
     # Codes marked with "x" should not be used because the display interprets
     # them under all coditions (e.g. Power).
     #
     # Codes marked with "*" can be used but the display pops up an annoying
     # idiot message about the key not being available right now.  These keys
     # are good for displaying things like the OSD (i.e. something that will
     # hang around for awhile until the annoying message goes away).
     #
     # Codes marked with "M" work OK but they actually do something when the
     # Menu button is pressed and the Menu is displayed.  If you map these keys,
     # you probably should exit your application before you enter the display's
     # Menu.
     #
     begin remote
     name  SamsungLN32A450
     bits            16
     flags           SPACE_ENC
     eps             30
     aeps            100
     header          4529 4418
     one             586  1625
     zero            586  498
     ptrail          585
     pre_data_bits   16
     pre_data        0xE0E0
     gap             46780
     min_repeat      1
     toggle_bit_mask 0x0
        begin codes
            Power                    0x40BF    # x
            TVMode                   0xD827    # x
            Source                   0x807F    # x
            One                      0x20DF    # *
            Two                      0xA05F    # *
            Three                    0x609F    # *
            Four                     0x10EF    # *
            Five                     0x906F    # *
            Six                      0x50AF    # *
            Seven                    0x30CF    # *
            Eight                    0xB04F    # *
            Nine                     0x708F    # *
            Zero                     0x8877    # *
            Minus                    0xC43B    # *
            Previous                 0xC837    # *  - Pre-Ch button
            VolumeUp                 0xE01F    # x
            VolumeDown               0xD02F    # x
            Mute                     0xF00F    # x
            ChannelUp                0x48B7    # x
            ChannelDown              0x08F7    # x
            List                     0xD629    # *  - Ch. List button
            Menu                     0x58A7    # x
            ClosedCaption            0xA45B    # *  - CC button
            Tools                    0xD22D    # x  - Tools button
            Info                     0xF807    # x
            Return                   0x1AE5    # M  - Return button
            Exit                     0xB44B    # xM
            ArrowUp                  0x06F9    # M  - In circular button
                                               #      cluster
            ArrowDown                0x8679    # M
            ArrowLeft                0xA659    # M
            ArrowRight               0x46B9    # M
            Enter                    0x16E9    # M
            Red                      0x36C9    # Red button
            Green                    0x28D7    # Green button
            Yellow                   0xA857    # Yellow button
            Blue                     0x6897    # Blue button
            SRSButton                0x7689    # x  - SRS button
            MTSButton                0x00FF    # x  - MTS button
            DMAButton                0xC639    # x  - DMA button
            EMode                    0x29D6    # x  - E. Mode button
            PSize                    0x7C83    # x  - P. Size button
            FavoriteChannel          0x22DD    # x  - Fav. Ch. button
            Rewind                   0xA25D
            Pause                    0x52AD
            FastForward              0x12ED
            Record                   0x926D
            Play                     0xE21D
            Stop                     0x629D
        end codes
     end remote

The modified /etc/init.d/lirc, mentioned above, allows the hardware.conf file to correctly specify that the Iguana lircd config file should be used for the receiver, like this:

     #Chosen Remote Control
     REMOTE="SamsungLN32A450"
     REMOTE_MODULES=""
     REMOTE_DRIVER="iguanaIR"
     REMOTE_DEVICE="/dev/iguanaIR/0"
     REMOTE_LIRCD_CONF="/etc/lirc/IguanaIR_SamsungLN32A450.conf"
     REMOTE_LIRCD_ARGS=""

After your hardware configuration file is all set, you can restart the LIRC daemon and test whether your remote is being mapped properly:

     sudo /etc/init.d/lirc start
     sudo irw

As long as irw is running, you should see the names of each of the keys that you press on the remote echoed on the display.

Now, you should go to the Infrared Devices configuration page that is found under the Applications/System/Mythbuntu Control Center menu on the Mythbuntu desktop. Here you can select Enable A Remote Cotrol and pick the Custom remote, and optionally select Enable An IR Transmitter and pick the Custom IR blaster. Uncheck the box to Generate Dynamic Button Mappings. After you apply these changes, this should get MythTV listening to the remote.

The last step is to generate mappings for all of the applications, that you'll be using the remote with. Each mapping translates the key names, that you gave to each of the remote's keys, to the actions that are actually to be carried out in the application. In Mythbuntu, there is a slick little application that uses common key names (i.e. the ones that were suggested above) as input to create the key mappings for all of the Mythbuntu applications automatically. To use it, do the following:

     [Make sure you're logged in as the user that runs Mythbuntu]
     cd ~/
     mythbuntu-lircrc-generator

This will generate mapping files for all of the Mythbuntu applications in the ~/.lirc directory. If the remote then works perfectly with the generated mapping files, well and good. Be sure to test it with any and all of the following applications that you use:

     elisa
     mplayer
     mythtv
     totem
     vlc
     xine
     xmame
     xmess

If the remote does not work perfectly (what are the chances of that), you may wish to hack the files in the ~/.lirc directory. Begin by deleting any remote keys that are needed to operate other devices (e.g. the TV/Display). Here is a list of suggested keys to delete:

     ChannelDown
     ChannelUp
     Menu
     Mute
     VolumeDown
     VolumeUp

Next, you might want to add or remap the special keys that mean so much to your application (e.g. for MythTV, the commercial skip key is always a winner). Do this in consultation with your application's key/command table and a list of the remote's keys (or, you can just look at the remote). Here we show, by way of example, hacks made to the mythtv mapping file for a Sony TiVo remote:

~/.lirc/mythtv:

     Most of the generated key mappings are OK but, for the TiVo remote, you may
     want to add the missing keys like this:
     begin
         remote = TiVoSony
         prog = mythtv
         button = List
         config = I
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoSony
         prog = mythtv
         button = Select
         config = Return
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoSony
         prog = mythtv
         button = ThumbsDown
         config = W
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoSony
         prog = mythtv
         button = ThumbsUp
         config = C
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoSony
         prog = mythtv
         button = Back
         config = <
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoSony
         prog = mythtv
         button = Slow
         config = J
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoSony
         prog = mythtv
         button = Clear
         config = Esc
         repeat = 0
         delay = 0
     end

If we also wanted the Philips TiVo remote to control MythTV, here are the additional hacks made to the mythtv mapping file for a that remote:

~/.lirc/mythtv:

     Most of the generated key mappings are OK but, for the TiVo remote, you may
     want to add the missing keys like this:
     begin
         remote = TiVoPhilips
         prog = mythtv
         button = List
         config = I
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoPhilips
         prog = mythtv
         button = Select
         config = Return
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoPhilips
         prog = mythtv
         button = ThumbsDown
         config = W
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoPhilips
         prog = mythtv
         button = ThumbsUp
         config = C
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoPhilips
         prog = mythtv
         button = Back
         config = <
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoPhilips
         prog = mythtv
         button = Slow
         config = J
         repeat = 0
         delay = 0
     end
     begin
         remote = TiVoPhilips
         prog = mythtv
         button = Clear
         config = Esc
         repeat = 0
         delay = 0
     end

You could actually have the identical keys on the two remotes mapped to different functions, if you want, but there's no percentage in that. We're just pointing out that, because there's a set of mappings for each remote that can generate keys (from the lircd config file), each remote's keys can be handled in whatever way you see fit.

Anyway, here we show, by way of another example, the complete key mapping file for a Samsung LN32A450 remote. This remote comes with the LN32A450 display/TV and is normally meant to be used to control the TV. We'd like to only use one remote for watching Myth TV so we take over some of the TV remote's keys to control MythTV, thereby giving the user a single remote solution to MythTV and their display. Here's the mapping file:

~/.lirc/mythtv:

     # LIRCRC Auto Generated by Mythbuntu Lirc Generator
     # Author(s): Mario Limonciello, Nick Fox
     # Created for use with Mythbuntu
     #
     # Changed to reflect actual usage of the remote-ski.
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = One
         config = 1
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Two
         config = 2
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Three
         config = 3
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Four
         config = 4
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Five
         config = 5
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Six
         config = 6
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Seven
         config = 7
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Eight
         config = 8
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Nine
         config = 9
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Zero
         config = 0
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Previous
         config = I
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = List
         config = M
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = ClosedCaption
         config = T
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Return
         config = Escape
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = ArrowUp
         config = Up
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = ArrowDown
         config = Down
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = ArrowLeft
         config = Left
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = ArrowRight
         config = Right
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Enter
         config = Return
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Red
         config = W
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Green
         config = Q
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Yellow
         config = Z
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Rewind
         config = <
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Pause
         config = P
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = FastForward
         config = >
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Record
         config = Space
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Play
         config = P
         repeat = 0
         delay = 0
     end
     begin
         remote = SamsungLN32A450
         prog = mythtv
         button = Stop
         config = Escape
         repeat = 0
         delay = 0
     end

The best technique for building mapping files is to work your way through all of the keys in the appropriate LIRC config file for the remote and make sure that each key is mapped to something. You can also check that each key is only mapped once but this isn't a hard and fast rule (e.g. you might map both the Pause and Stop keys to a single command in MythTV, since the both do the same thing in that application).

All of the other files in the ~/.lirc directory may need hacking too, if you use the applications associated with them.

IR Blasters

IR blasters are needed when Mythbuntu must change channels through a set top box or digital transport adapter instead of just being able to record clear channels off of the antenna input. Usually, the set top box or digital transport adapter is required by a cable company so that they can control which channels you receive in a lineup or pack more services onto the wire using the most efficient technology. Whatever the reason, Mythbuntu must have some way of controlling the STB or DTA to cause it to change when it needs to record a particular program.

Many of the IR receivers also support IR blasters (transmitters). So to do some of the encoder cards. These are the steps to setting up an IR blaster for use by MythTV.

The first step is to make sure that you have a copy of LIRC that supports the IR receiver/transmitter that you will be using. You can take a look at the Remote Controls section (above) for notes on how to build LIRC for a number of remote control receivers but, essentially, this process begins by checking to see if LIRC already has support for the receiver/transmitter built in. You can check whether it does with the following command:

     lircd --driver=?

This will give a list of drivers that are built into the lircd that is installed on the system. If you see the one you need (e.g. "tira" for the Tira-2, "irman" for the Ira, or "iguanaIR" for the Iguana Works product), you are probably in business and you can skip ahead to the irrecord step, below. Otherwise, if you don't see the required driver in the list, or you know for sure that IR blasting with your receiver (e.g. the TopSeed) requires a patch to the LIRC source code, you'll need to download the latest LIRC software from http://www.lirc.org/software.html and build LIRC.

And, note that even if you do see the driver in the list, you still may need to download the latest LIRC because some of the devices that you'll want to control (e.g. the Pace DC50X DTA) may use remote control features that are not available in earlier releases of LIRC (such as XMP, which is only in 0.8.6). If that's the case, download and build the latest version with support for your IR device included.

Once you've downloaded the software, you can uncompress it and unpack it, then build LIRC with the appropriate driver enabled (here we show irman):

     cd lirc
     tar -xvzf lirc-0.8.6.tar.gz
     cd lirc-0.8.6
     ./configure --with-driver=irman
     make

To install the new lircd, become super user and do the install:

     sudo make install

This should put the new lircd in /usr/local/sbin while keeping the original in /usr/sbin -- handy if you need to fall back on the original lircd.

The next step is exactly like one of the steps that must be done to set up a remote control to control Mythbuntu. Begin by making sure that lircd is not running (if you are not doing this for the first time) and then record the STB/DTA's remote's buttons as follows (picking the appropriate invocation of irrecord, depending on which IR receiver you are using):

     [sudo /etc/init.d/lirc stop]
     sudo irrecord -f -H tira -d /dev/ttyUSB0 Tira-2_myremote.conf
     sudo irrecord -f -H irman -d /dev/ttyS0 Ira_myremote.conf
     sudo irrecord -f -n -H iguanaIR -d /dev/iguanaIR/0 Iguana_myremote.conf
     sudo irrecord -f -d /dev/lirc0 MCE_myremote.conf

When you run irrecord, you should follow its instructions. There are notes in the Remote Controls section (above), that you should read about how to record a remote. Be sure to carry out the instructions, as described, because failure to do so will lead to the remote not being set up correctly.

Note that the original MCE receiver doesn't do a very good job of catching the remote codes from many remote controls. If it doesn't, you will most likely get a config file that is recorded in raw mode. In all probability, this file will be junk but you never know. You can analyse it with irrecord to see if there is anything good in it like this:

     irrecord -a MCE_myremote.conf > MCE_myremote-codes.conf

In fact, for some of the DTA remotes that use newer transmission protocols (e.g. Pace DC50X), none of the IR receivers do a very good job of catching their codes. You may get a raw file that cannot be analysed by irrecord or you may get what looks like a good config file but is actually filled with bad or duplicate codes.

In other cases (e.g. Motorola DCT700), the raw file may look good and even appear to work but one or two keys, for example the zero key, will not be received by the DTA or STB. This may make channel changing a challenge.

Many of these devices use the newer XMP protocol from UEI. Rumors are that the a**holes at the cable company (you know who you are) deliberately picked this protocol because it is a b***ard to record and thereby thwarts attempts by owners of non-cable-company DVRs to use their DVR to record the cable company's content. Conspiracy theory or truth? Who knows? But, they are right about one thing. Capturing the protocol is a b***ard.

For these remotes, you may have to start with one of the generic config files:

     http://lirc.sourceforge.net/remotes/generic/

Here is an example of how to do it with the Pace DC50X, using a serial receiver, after downloading the XMP (renamed to XMP.conf) generic file:

     cp XMP.conf Ira_myremote
     sudo irrecord -n -H irman -d /dev/ttyS0 Ira_myremote

After you capture the remote's keys, the Ira_myremote file will be left untouched and new file named Ira_myremote.conf will be created with the captured keys.

Good luck. In truth, the problem undoubtedly lies with irrecord. Despite the fact that the prototype XMP file clearly says "flags XMP", irrecord does not seem to take this fact into account and the protocol does not get captured properly. Nor does using the raw flag yield much joy. If irrecord "thinks it knows" what the protocol is, it doesn't record a raw file regardless of the flag being set. And, we've never seen it not "think it knows" all about the XMP protocol, despite the fact that it has no clue....

If you can't get irrecord to capture your remote's codes, you can look around on the Internet. There are plenty of smart people out there who hate the cable company as much or more than you do. If you're in luck, they'll have figured out your remote's codes and posted them on a Web page, somewhere. Essentially, all you need are the key codes for the ten digits and the Enter key, so that Myth TV can change channels on the DTA/STB. Here, for example, are the codes for the dreaded Pace DC50X:

/etc/lirc/lircd.conf:

     # contributed by Mike Silliman
     #
     # brand: Comcast Branded Motorola DTA100 and Pace DC50X
     # model no. of remote control: Unknown, Comcast Label
     # devices being controlled by this remote: Pace DC50X
     #
     # Protocol: XMP-R
     # Device: 62.16
     #
     # Although this remote uses the XMP protocol, this config should still
     # work with lirc 0.8.5 or earlier because we've defined raw codes herein.
     begin remote
        name             PaceDC50X
        flags            RAW_CODES
        eps              30
        aeps             100
     gap              80412
         begin raw_codes
             name One
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 2656 210 763
             210 763 210 763 210 894
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1578 210 1841
             210 763 210 763 210 894
             210 763 210 763 210
             name Two
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 2524 210 763
             210 763 210 763 210 1026
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1446 210 1841
             210 763 210 763 210 1026
             210 763 210 763 210
             name Three
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 2393 210 763
             210 763 210 763 210 1157
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1315 210 1841
             210 763 210 763 210 1157
             210 763 210 763 210
             name Four
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 2261 210 763
             210 763 210 763 210 1315
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1157 210 1841
             210 763 210 763 210 1315
             210 763 210 763 210
             name Five
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 2130 210 763
             210 763 210 763 210 1446
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1026 210 1841
             210 763 210 763 210 1446
             210 763 210 763 210
             name Six
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1972 210 763
             210 763 210 763 210 1578
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 894 210 1841
             210 763 210 763 210 1578
             210 763 210 763 210
             name Seven
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1841 210 763
             210 763 210 763 210 1709
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 763 210 1841
             210 763 210 763 210 1709
             210 763 210 763 210
             name Eight
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1709 210 763
             210 763 210 763 210 1841
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 2787 210 1841
             210 763 210 763 210 1841
             210 763 210 763 210
             name Nine
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1578 210 763
             210 763 210 763 210 1972
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 2656 210 1841
             210 763 210 763 210 1972
             210 763 210 763 210
             name Zero
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 2787 210 763
             210 763 210 763 210 763
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1709 210 1841
             210 763 210 763 210 763
             210 763 210 763 210
             name Enter
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 1841 210 763
             210 763 210 1026 210 1446
             210 763 210 763 210 80413
             210 894 210 1709 210 763
             210 2787 210 1315 210 1315
             210 1157 210 2656 210 13805
             210 894 210 763 210 1841
             210 763 210 1026 210 1446
             210 763 210 763 210
         end raw_codes
     end remote

The raw codes should work with any version of LIRC and any IR blaster. However, you might not experience proper or reliable channel changing using raw codes with some IR blasters and DTAs/STBs (e.g. using the raw codes with the Pinnacle IR blaster and the Pace DC50X often results in a single key press being replicated as two key presses, although using the same raw codes with the MCE or Iguanna IR blaster and the Pace DC50X works fine). If you have a later version of LIRC (i.e. >= 0.8.6) that supports the XMP protocol, you can try a config file that has the generated codes. Using the proper XMP codes seems to work much more reliably, as in this example, once again for the dreaded Pace DC50X:

/etc/lirc/lircd.conf:

     # Please make this file available to others
     #
     # this config file was automatically generated
     # using lirc-0.8.6-CVS(default) on Mon Jan 11 21:34:36 2010
     #
     # contributed by Kirk Bocek
     #
     # brand: Comcast Branded Motorola DTA100 and Pace DC50X
     # model no. of remote control: Unknown, Comcast Label
     # devices being controlled by this remote: Motorola DTA100 & Pace DC50X
     #
     # These are a couple of the cheap digital converters being provided by
     # Comcast as part of their analog shutdown. DTA100 information here:
     # 
     # http://www.motorola.com/Business/US-EN/Business+Product+and+Services/
     #   TV+Video+Distribution/Customer+Premises+Equipment+%28Set-tops%29/
     #   All-Digital+QAM+Set-tops/DTA100_US-EN
     #
     # This remote also has power and volume buttons. You can program these
     # to control your TV. But these DTAs do have internal volume and mute
     # controls. The power button, however, is only for your TV and has no
     # effect on the DTA.
     #
     # Because this remote uses the XMP protocol, this config requires
     # lirc 0.8.6 or later.
     #
     # Generated by starting with the generic XMP protocol configuration:
     # http://lirc.sourceforge.net/remotes/generic/XMP
     # and then using irrecord to add the keys.
     #
     # V.2 - Added Volume Up and Volume Down
     #
     begin remote
     #  name             MotorolaDTA100
        name             PaceDC50X
        bits             24
        flags            XMP
        eps              20
        aeps             300
     one              0    137
     zero             250  710
     ptrail           250
     pre_data_bits    32
     pre_data         0x170F443E
     post_data_bits   8
     post_data        0x0
     pre              250  12921
     gap              81698
     toggle_bit_mask  0x0
         begin codes
             Info                         0x170026
             One                          0x1E0001
             Two                          0x1D0002
             Three                        0x1C0003
             Four                         0x1B0004
             Five                         0x1A0005
             Six                          0x190006
             Seven                        0x180007
             Eight                        0x170008
             Nine                         0x160009
             Zero                         0x1F0000
             Enter                        0x180025
             Last                         0x190051
             ChannelUp                    0x12000D
             ChannelDown                  0x11000E
             Mute                         0x13000C
             VolumeUp                     0x15000A
             VolumeDown                   0x14000B
             Language                     0x150082
         end codes
     end remote

Here is a working config file that can be used with the Motorola DCT700 (or QIP2500) that is preferred by the "other" cable company (or, so they think of themselves):

/etc/lirc/lircd.conf:

     # Contributed by lisat at Launchpad.
     #
     # Modified DCT2000 configuration for use with Verizon-
     # branded Motorola QIP2500 STB and DCT700 DTA.
     #
     # This config should work with lirc 0.8.5 or earlier because
     # we've defined raw codes herein.
     begin remote
        name             DCT700
        flags            RAW_CODES
        eps              30
        aeps             100
     ptrail           520
     repeat           0  0
     gap              100000
         begin raw_codes
     #          Note that numbers, particularly zero, are special.  If you
     #          record the remote with irrecord, you will not get a reliable
     #          sequence for IR blasting.  Quite possibly you will be able to
     #          receive all of the codes from the remote but the trailing
     #          "42050 9000 2250 500", which has been added to all of the
     #          following numeric codes, is often required to make IR blasting
     #          work reliably and repeatedly (a key requirement, when
     #          unattended channel changing is involved).
                name One
                9000 4400 550 4450 550 2150
                550 2200 550 2200 550 2150
                550 2200 550 2200 550 2150
                550 2200 550 2200 550 2150
                550 2200 550 4400 550 4450
                550 4400 550 4450 550 42050
                9000 2250 500
             name Two
             9000 4400 550 2200 550 4400
             550 2200 550 2150 550 2200
             550 2200 550 2150 550 2200
             550 2200 550 2150 550 2200
             550 2200 550 2150 550 4450
             550 4400 550 4450 500 42050
             9000 2250 500
             name Three
             9000 4400 550 4450 550 4400
             550 2200 550 2150 550 2200
             550 2200 550 2150 550 2200
             550 2200 550 2150 550 2200
             550 2200 550 4400 550 2200
             550 4400 550 4450 500 42050
             9000 2250 500
             name Four
             9000 4400 550 2200 550 2150
             550 4450 550 2150 550 2200
             550 2200 550 2150 550 2200
             550 2200 550 2150 550 2200
             550 2200 550 2150 550 2200
             550 4400 550 4450 550 42050
             9000 2250 500
             name Five
             9000 4450 550 4400 550 2200
             550 4400 550 2200 550 2150
             550 2200 550 2200 550 2150
             550 2200 550 2200 550 2150
             550 2200 550 4400 550 4450
             550 2200 500 4450 550 42050
             9000 2250 500
             name Six
             9000 4500 550 2150 550 4450
             550 4450 550 2200 500 2200
             550 2200 550 2200 550 2150
             550 2200 550 2200 550 2200
             500 2200 550 2200 550 4450
             500 2200 550 4450 550 42050
             9000 2250 500
             name Seven
             9000 4450 550 4450 550 4450
             500 4450 550 2200 550 2200
             550 2150 550 2200 550 2200
             550 2200 500 2200 550 2200
             550 2200 500 4450 550 2200
             550 2200 550 4450 500 42050
             9000 2250 500
             name Eight
             9000 4400 550 2200 550 2150
             550 2200 550 4400 550 2200
             550 2200 550 2150 550 2200
             550 2200 550 2150 550 2200
             550 2200 550 2150 550 2200
             550 2200 550 4400 550 42050
             9000 2250 500
             name Nine
             9050 4450 550 4450 550 2150
             550 2200 550 4450 550 2150
             550 2200 550 2200 550 2200
             500 2200 550 2200 550 2200
             500 2200 550 4450 550 4450
             550 4450 500 2200 550 42050
             9000 2250 500
             name Zero
             9000 4400 550 2200 550 2200
             550 2150 550 2200 550 2200
             550 2150 550 2200 550 2200
             550 2150 550 2200 550 2200
             550 2150 550 2200 550 2200
             550 2150 550 2200 550 42050
             9000 2250 500
             name Enter  # Same as OK
             9050 4400 550 4400 550 2200
             550 2200 550 2150 550 4450
             550 2150 550 2200 550 2200
             550 2150 550 2200 550 2200
             550 2150 550 2200 550 4400
             550 4450 550 4400 550
         end raw_codes
     end remote

These raw codes should work with any version of LIRC and any IR blaster.

Once you have the config file for the STB's or DTA's remote, you can either concatenate it to Myth TV's remote information in /etc/lirc/lircd.conf or, if you modified /etc/init.d/lirc to honor the information in hardware.conf, you can set up one config file for Myth TV's remote and one for the STB/DTA. I prefer the later solution, as this snippet from /etc/lirc/hardware.conf shows:

     # /etc/lirc/hardware.conf
     #
     #Chosen Remote Control
     REMOTE="SamsungLN32A450"
     REMOTE_MODULES=""
     REMOTE_DRIVER="iguanaIR"
     REMOTE_DEVICE="/dev/iguanaIR/0"
     REMOTE_LIRCD_CONF="/etc/lirc/IguanaIR_SamsungLN32A450.conf"
     REMOTE_LIRCD_ARGS=""
     #Chosen IR Transmitter
     TRANSMITTER="PaceDC50X"
     TRANSMITTER_MODULES=""
     TRANSMITTER_DRIVER="iguanaIR"
     TRANSMITTER_DEVICE="/dev/iguanaIR/0"
     TRANSMITTER_LIRCD_CONF="/etc/lirc/XMP_PaceDC50X.conf"
     TRANSMITTER_LIRCD_ARGS=""

Note that this configuration has both a receiver and a transmitter and uses two drivers (albeit both the same one). As shown here, /etc/init.d/lirc will start up two instances of lirc and create two pipes, /dev/lircd and /dev/lircd1. When you run irsend, you will need to specify the second pipe for the transmitter. Myth TV (and other applications) should use the first pipe by default.

For the MCE xceiver, only one copy of LIRC must be run. Furthermore, in some earlier versions of LIRC (e.g. 0.8.3) the lirc_mceusb2 module must be used instead of lirc_mceusb to drive the xceiver. You can find all of the details about which versions of the MCE remote will also allow IR blasting and which kernel module to use at:

     http://www.mythtv.org/wiki/MCE_Remote

This snippet from /etc/lirc/hardware.conf shows how to set things up (again with the modified /etc/init.d/lirc):

     # /etc/lirc/hardware.conf
     #
     #Chosen Remote Control
     REMOTE="Windows Media Center Remotes"
     REMOTE_MODULES="lirc_dev lirc_mceusb"
     REMOTE_DRIVER=""
     REMOTE_DEVICE="/dev/lirc0"
     REMOTE_LIRCD_CONF="/etc/lirc/MCEUSB.conf"
     REMOTE_LIRCD_ARGS=""
     #Chosen IR Transmitter
     TRANSMITTER="PaceDC50X"
     TRANSMITTER_MODULES=""
     TRANSMITTER_DRIVER=""
     TRANSMITTER_DEVICE=""
     TRANSMITTER_LIRCD_CONF="/etc/lirc/Raw_PaceDC50X.conf"
     TRANSMITTER_LIRCD_ARGS=""

When using irsend, there is no need to specify the second pipe, since there is only one.

Now that LIRC is configured correctly, start it up. If your remote was working before, it should still work (duh).

Incidentally, even slight errors in the config file can cause LIRC to fail silently so be careful. Be especially careful with comments because comment handling leaves a bit to be desired. Inside raw_codes, if the comment character doesn't appear in column 1 or if it doesn't appear on a line that has a command on it, it will silently break the config file and LIRC won't see any of your remotes. Nice, huh? Here's a few examples:

     #         This comment is good
               # This comment breaks the config file
               name Enter  # This comment is OK

To test blasting, you can send commands to the IR blaster as follows:

     sudo irsend set_transmitters 1 2 3 4
     sudo irsend send_once PaceDC50X One

If you compiled your own version of LIRC and you kept the original, you will probably want to use:

     sudo /usr/local/sbin/irsend set_transmitters 1 2 3 4
     sudo /usr/local/sbin/irsend send_once PaceDC50X One

OK, so since humans can't see IR radiation, how do we know if the IR blaster is working? Excellent question. One you'd like to have answered before you tape the IR blaster and the IR receiver together, in your version of a homemade optocoupler, with a half a pound of black tape. The answer is simple. Get your digital camera and turn it on so that its ready to take pictures. Point it at a white wall and depress the shutter release part way. Do you see a circular orange-ish glow bouncing back from the wall in the camera's viewfinder? That's the auto-focus IR range finder's light. If you can see it, you'll be able to see the light from the IR blaster too.

Aim the camera directly down the bore-sight of the IR blaster at its typical working distance. While looking at the IR blaster through the camera's viewfinder, run irsend send_once. You should see a momemtary glow from the IR blaster as it transmits the chosen code. This indicates that all is working correctly. You can also use this method to decide which IR blaster to actually select (instead of selecting them all), before you proceed to writing your STB/DTA control script.

Once you're sure the IR blaster is working, fashion an optocoupler from the IR blaster and the STB/DTA's remote IR receiver (if it has one). Usually, a short piece of tube, say 3/4", of the correct diameter can be employed to hold the blaster and receiver in close proximity to each other, so that the light from the blaster impinges directly on the face of the receiver. When you've arranged them in a suitable configuration, the whole thing can be taped up with black electrical tape, thereby excluding any extraneous light.

If your STB/DTA doesn't have a remote IR receiver, you'll need to position the IR blaster in front of its IR receiver, wherever that is on the STB/DTA box. The double sided tape, supplied with the IR blaster, can be used for this task. Or, black electrical tape may prove helpful.

You may have to experiment with the best location for the IR blaster so that it changes channels reliably on the DTA/STB. In the case of one DTA that we know of (Motorola DCT700), positioning the IR blaster 4-6 inches away from front of the DTA/STB actually makes it work better. Clearly some experimentation may be in order.

The next thing required is a script that can send channel change commands to the IR blaster. You'll need a script that accepts the numeric channel number that Myth sends when changing channels and then sends the appropriate keys to the correct blaster. The name of this script will be entered into the MythTV configuration page that connects the lineup (source) to an input (encoder card) so that MythTV can use it to change channels on the STB/DTA whenever it needs to record something.

The requirement to have a separate script for each IR blaster is annoying. And, we've seen lots of channel changer scripts in Internetland that require you to edit the remote name, LIRC pipe name, etc. into the script before you use it. This too is annoying.

The following script can be used to change channels on any IR blaster (by adding a symlink to it with the blaster number in the linked name) while configuring itself from the information in /etc/lirc/hardware.conf. In short, it is pretty much automagic. Install the following script somewhere convenient (I use /etc/lirc):

/etc/lirc/IRChangeChannel:

     #! /bin/sh
     # Shell script used to send channel change commands to a set top box (STB)
     # or digital transport adapter (DTA) via LIRC.
     #
     # This script is commonly used by applications such as Myth TV to change
     # the channels on a STB/DTA when the STB/DTA must be used to convert the
     # channels that a subscriber can see to a single channel (e.g. when
     # digital channels are to be viewed by the application on channel 3 with
     # an analog decoder card).
     #
     # The application invokes this script and passes the channel number to it
     # as the first parameter.  This script deconstructs the channel number and
     # decides what command sequence the STB/DTA's remote would have to send in
     # order to change to that channel (typically its the channel number,
     # followed by the Enter button).  It sends the channel change commands to
     # the STB/DTA through the IR blaster that was started by lircd.  The
     # information necessary to do this is obtained from the lircd config file
     # /etc/lirc/hardware.conf.
     #
     # If you need to send commands to a different IR emitter than number 1,
     # you can alias this script and use the aliases to send to any emitter
     # from 1 thru 4.  You must set up the aliases as follows:
     #
     #   ln -s IRChangeChannel IR1ChangeChannel
     #   ln -s IRChangeChannel IR2ChangeChannel
     #   ln -s IRChangeChannel IR3ChangeChannel
     #   ln -s IRChangeChannel IR4ChangeChannel
     #
     # You can then send commands to the alternate emitters as follows:
     #
     #   /path/to/scripts/IR1ChangeChannel 12
     #   /path/to/scripts/IR2ChangeChannel 22
     #        .
     #        .
     #        .
     #
     # Because of the nature of the way that the program name is determined,
     # you must use some kind of path prefix on the name (i.e. at the very
     # least, use "./IR3ChangeChannel 44").
     #
     # Note that, unless you are using stereo emitters on the IguanaIR, the two
     # emitters on the stick are IR1 and IR3 (two and four are not used).
     #
     # Some DTAs do not change the channel reliably, every time.  Or, they do it
     # fine with one IR blaster and not another.  In this case, if they typically
     # miss some digits and do nothing because of it (i.e. stay on the same
     # channel that they were originally on), you can set CHANGE_TRIES to
     # something other than one (below).  This will cause the script to try
     # changing the channel the number of times given and, hopefully, one will
     # stick.
     ##########################################################################
     # Constants that define how this script works.  Set these up once at
     # install time.
     # Where we load irsend from (depends whether this is a system install or
     # a local build).
     #ew LOAD_PATH=/usr/bin
     LOAD_PATH=/usr/local/bin
     # The delay (in seconds) that we should sleep between each key press (a
     # half a second seems to be a reasonable number).
     KEY_DELAY=0.5
     # The number of times this script should try changing the channel (see
     # above).
     CHANGE_TRIES=1
     # See if we can find the send module in the place where the user told us to
     # look.  If not, we're outta here quick.
     test -f ${LOAD_PATH}/irsend || exit 0
     # The user can symlink to this program to use an emitter other than 1.  We
     # figure this out from our invoking program name.
     Emitter=0
     ProgName=`echo $0 | sed -r s:.+/\([^/]+\)$:\\\1:`
     if [ ! -n "$ProgName" ] || [ "$ProgName" = "IRChangeChannel" ]; then
         Emitter=1
     else
         case "$ProgName" in
             IR1ChangeChannel)
                 Emitter=1
                 ;;
             IR2ChangeChannel)
                 Emitter=2
                 ;;
             IR3ChangeChannel)
                 Emitter=3
                 ;;
             IR4ChangeChannel)
                 Emitter=4
                 ;;
             *)
                 Emitter=1
         esac
     fi
     # Let's get the config file that was used to start lircd with.  It will
     # tell us what remote we're using (hopefully).
     if [ -f /etc/lirc/hardware.conf ]; then
         . /etc/lirc/hardware.conf
     fi
     # We need a remote name.
     if [ -z "$TRANSMITTER" ] || [ "$TRANSMITTER" = "none" ]; then
         exit 0
     fi
     # Figure out where the transmitter is.
     if [ -n "$PIPE_PATH" ] && [ "$PIPE_PATH" != "none" ]; then
         DEV_PATH=$PIPE_PATH
     else
         DEV_PATH="/var/run/lirc"
     fi
     # If there's a transmitter device or driver defined, the lirc init script
     # started a second copy of lircd.
     if [ ! -z "$TRANSMITTER_DEVICE" ] \
         || [ ! -z "$TRANSMITTER_DRIVER" ]; then
         DevArgs="--device=$DEV_PATH/lircd1"
     else
         DevArgs="--device=$DEV_PATH/lircd"
     fi
     # Select the appropriate IR emitter on the device.
     ${LOAD_PATH}/irsend $DevArgs set_transmitters $Emitter
     # Try setting the channel the number of times the user has requested us to
     # do so (some DTAs with some blasters don't get the message the first
     # time).
     Tries=1
     while [ $Tries -le $CHANGE_TRIES ]; do
      # Send the channel number.
      for Digit in $(echo $1 | sed -e 's/./& /g'); do
          case "$Digit" in
              1)
                  Key="One"
                  ;;
              2)
                  Key="Two"
                  ;;
              3)
                  Key="Three"
                  ;;
              4)
                  Key="Four"
                  ;;
              5)
                  Key="Five"
                  ;;
              6)
                  Key="Six"
                  ;;
              7)
                  Key="Seven"
                  ;;
              8)
                  Key="Eight"
                  ;;
              9)
                  Key="Nine"
                  ;;
              *)
                  Key="Zero"
          esac
          ${LOAD_PATH}/irsend $DevArgs send_once $TRANSMITTER $Key
          sleep 0.5
      done
      # Send the enter key.
      ${LOAD_PATH}/irsend --device=/dev/lircd SEND_ONCE $TRANSMITTER Enter
      if [ $Tries -lt $CHANGE_TRIES ]; then
          sleep $KEY_DELAY
      fi
      # Increment the try count, in case we're doing this more than once.
      Tries=`expr $Tries + 1`
     done

Don't forget to set the permissions to execute for everyone. Test the script to see that it changes channels OK. Plug a TV into the STB/DTA, tune it to channel 3, make sure the STB/DTA channel switch is set to 3, and send it a channel change command like this:

     /etc/lirc/IR1ChangeChannel 12

You should see the chosen channel on your TV. Try all of the other digits in your channel numbers, to make sure that all digits work, and try long and short channel numbers. If all of them work, you can cable the STB/DTA up to the input of the appropriate encoder card that you want to use with the DTA/STB.

Proceed to the "Connect source to input" MythTV configuration page. You can get to this page by launching the Mythbuntu Control Center off the desktop menu or, in earlier versions of MythTV, from the frontend, by selecting the Utilities/Setup | Setup | Mythbuntu menus. You must do this on the system that actually has the encoder card installed in it (if you have multiple systems networked to a single backend).

Enter your password to get the Mythbuntu Control Center to launch. From there, pick the MythTV Configuration menu item and then Launch MythTV Setup, once it becomes visible. You will need to shut down the backend to continue.

From the MythTV Setup main menu, pick the Input Connections item. Then, from the list of encoders, pick the encoder card that is physically connected to the STB/DTA. That should bring up the "Connect source to input" page. Under the "External channel change command" field, enter the full path to the change channel script. Make sure the path is absolutely correct because, if you make a typo, MythTV will simply hang for a while and then do nothing (i.e. you won't get any error messges or warnings).

Note that, if you are connecting multiple STB/DTAs to multiple encoder cards, you should set each one up so that it points to the symlinked file name for the appropriate IR blaster that controls the STB/DTA connected to that card. For example, the setup for /dev/video0 might look like this:

     /etc/lirc/IR1ChangeChannel

While the setup for /dev/video1 might look like this:

     /etc/lirc/IR2ChangeChannel

There is no other way to pass the IR emitter number to the channel changer script except by its file name, hence the reason for symlinking aliases to the channel changer script to tell it which IR emitter to change.

Under the "Preset tuner to channel" field, you should enter the channel number that the STB/DTA transmits on (typically it is channel 3). This will cause the encoder card to be set to the

Note that all of the channels in the lineup defined by the video source that is connected to this encoder will be selected by sending the channel number to the STB/DTA via the channel changer script and by presetting the encoder to the chosen channel (e.g. channel 3). If this doesn't work for some of your channels (e.g. you have a mixture of digital channels that can be directly tuned and analog channels that require the STB/DTA), you will need to construct more than one video source (lineup) and assign the separate sources to the disparate encoders.

After you've set up the external channel changer script, you can save the configuration, restart the backend and restart the frontend. From the frontend, pick Watch Live TV. Choose the tuner that you've set up to use the STB/DTA and see if it shows live TV. You should be able to change channels by entering a channel number, followed by Enter or by using the up/down arrows. If you don't see your chosen channel after 3 or 4 seconds, you need to go find out what's wrong with your configuration. Good luck! There are plenty of places for it to go wrong, including where you entered the path name of the external channel changer script. No errors are reported so it helps if you are psychic. If it works, you are basically in business.

Incidentally, some people have pointed out that the "Preset tuner to channel" field doesn't seem to work. If that's the case, you can install the ivtv-utils package and use one of its utilities to pretune the tuner to the correct channel:

     sudo apt-get install ivtv-utils

Add a line something like this to rc.local:

     /etc/rc.local:
     ivtv-tune -c 3 -d /dev/video0 -t us-cable

This should tune the encoder to the correct channel at startup.

Replacing Or Improving On The IR Blaster

Many of us have now been forced by Comcast to add a Pace DC50X in front of their MythTV setup in order to record programs in the extended basic tier that used to be broadcast in the clear. IR blasting to control the Pace DC50X works OK with the original MCE USB receiver as it does with the Iguana IR receiver. Sadly, the MCE USB receiver is no longer available and the performance of the Iguana receiver leaves much to be desired so you may be forced by expediency or common sense to use other IR receivers.

The TopSeed IR Receiver works with the on-board USB ports on some motherboards but not others so you can use it, if it is compatible with your motherboard. Its blaster may or may not work with the DC50X. The Pinnacle Systems PCTV Remote seems to work with all on-board USB ports and is readily available. Unfortunately, its IR blaster does not work reliably with the Pace DC50X.

If you are stuck using the Pace DC50X and you need to use one of the IR receivers (like the Pinnacle) whose blaster doesn't work with it, you can try substituting an optocoupler for the combination of the IR blaster supplied with your IR receiver and the IR receiver supplied with the DC50X. Not only is the likelihood of success much greater when an optocoupler is used but the setup looks much neater.

The typical IR blaster output of an IR receiver is a mono 3.5mm jack with the Tip being the Data signal and the Ring being the Ground. If you care to take the DC50X apart, you will see that the "IR IN" jack on the back is electrically connected to the IR detector on the front and, if you care to take the remote IR receiver that comes with the DTA apart, you'll find that the wires leading into it are labeled, and that, according to this labeling, the stereo 3.5mm plug that it uses has power on the Tip, Data on the Center Ring, and Ground on the Base Ring (furthest from the Tip). Or, you can just take our word for it.

To couple the IR blaster output port to the DC50X input port, we will use, as we noted above, an optocoupler to convert the IR blaster's active high signaling to the active low signaling needed on the DTA's input.

Since the basic problem with the Pace DC50X, that we are trying to solve, is that the power output by the IR blaster is not enough to reliably drive the DTA, we want an optocoupler with a high current transfer ratio. The 4N37 (which is an NPN transistor, optocoupler that comes in a 6-pin DIP package) has a CTR of 100 so it should work well. It is also readily available from sources such as Digi-Key for under a buck.

A 3.5mm mono plug is soldered onto a suitable length of flexible, two-conductor wire (if color coded, the red lead should be soldered to the Tip and the black soldered to the Ring). The other end of the wire is carefully soldered to pin 1 (Tip) and pin 2 (Ring) of the optocoupler. A couple of bits of shrink tubing can make the job neat and prevent short circuits.

A 3.5mm stereo plug is soldered onto another suitable length of flexible, two-conductor wire (if color coded, the red lead should be soldered to the First Ring and the black soldered to the Second Ring). The other end of the wire is, likewise, carefully soldered to pin 5 (First Ring) and pin 4 (Second Ring) of the optocoupler. More shrink tubing can be applied for insulation, including a larger piece over the optocoupler itself. Note that the DTA power, from the stereo plug's tip, is not connected.

When you plug the mono jack into the IR receiver and the stereo jack into the DTA (now's a good time to label them), control of the DTA should prove much more reliable.

Setting The Clock

The clock on the Mythbuntu system must be kept synchronized with a source of accurate time, in order for programs to be recorded at the correct start/stop times. Typically, NTP is used for this job. Mythbuntu comes precofigured with NTP installed and running.

To set up NTP properly, you will need to edit the config file and point it at two or three NTP servers. To do so:

     sudoedit /etc/ntp.conf

After the line that says "server ntp.ubuntu.com", you can add a few more servers, like this:

     server ntp.aserver.com

Look at the following list of public NTP servers and pick a couple more stratum 2 servers to synchronize with. Servers, from the list, that are close to you will provide better synchronization:

     http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers

If you have a local clock that is regulated well enough, you can synchronize your Mythbuntu systems to it.

/etc/ntp.conf:

     Here is a complete replacement for /etc/ntp.conf that synchronizes the
     system to a local clock.  Note that the local server is marked as a true
     chimer by the "true" keyword and it is also marked as the preferred server.
     Unfortunately, the "true" keyword seems not to work in the earlier versions
     of NTP (4.2.4) that are installed on some of the earlier Mythbuntu
     versions (e.g. 9.10) so you may have to take other steps (see below).
     Here is the file:
     #
     # /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help.
     # Read by ntpd at startup.
     #
     # For ntpd version 4.2.6.
     #
     #
     # Prohibit general access to this service.
     #
     restrict default ignore
     #
     # Local users may interrogate the ntp server more closely.
     #
     restrict 127.0.0.1
     restrict ::1
     #
     # Permit time synchronization with our local time source but do not
     # permit the source to query or modify the service on this system.
     #
     restrict 192.168.1.1
     #
     # Synchronize this system with our local NTP server.
     #
     server 192.168.1.1 true prefer minpoll 4 maxpoll 5
     #
     # Undisciplined Local Clock.  This is a fake driver intended for backup and
     # when no outside source of synchronized time is available.  The normal,
     # running stratum is usually 3, but in this case we elect to use stratum
     # 10.  Since the server line does not have the prefer keyword, this clock
     # is never used for synchronization, unless no other other synchronization
     # source is available.
     #
     # Actually, this happens way more than you'd think it might so it is
     # important to have this clock defined to keep things ticking along.
     #
     server 127.127.1.0
     fudge  127.127.1.0 stratum 10
     #
     # Drift file.  Put this in a directory which the daemon can write to.  No
     # symbolic links allowed, either, since the daemon updates the file by
     # creating a temporary file in the same directory and then renameing it to
     # the file named.
     #
     # This file is read at startup to give the daemon a leg up on getting
     # running without having to go through the laborious chore of figuring out
     # drift from scratch.
     #
     driftfile /var/lib/ntp/ntp.drift
     #
     # Enable this if you want statistics to be logged.
     #
     #statsdir /var/log/ntp/
     #
     # Statistics to be logged.
     #
     statistics loopstats peerstats clockstats
     filegen loopstats file loopstats type day enable
     filegen peerstats file peerstats type day enable
     filegen clockstats file clockstats type day enable

/etc/init.d/ntpd:

     You may also need to alter the NTP startup script to begin by synchronizing
     the Mythbuntu machine's clock with NTP on the reference clock's machine.
     This is necessary if there can be large amounts of drift between the
     reference clock and the local clock when the Mythbuntu machine is down.  As
     is well known, NTP will not synchronize clocks that are too far apart, hence
     the need to do it manually at startup.  The following is a complete
     replacement for the ntpd script that carries out synchronization at startup
     as well as fixes a few other problems.  You may wish to use it in lieu of the
     script provided by Mythbuntu:
     #!/bin/sh
     ### BEGIN INIT INFO
     # Provides:        ntp
     # Required-Start:  $network $remote_fs $syslog
     # Required-Stop:   $network $remote_fs $syslog
     # Default-Start:   2 3 4 5
     # Default-Stop:    0 1 6
     # Short-Description: Start NTP daemon
     ### END INIT INFO
     PATH=/sbin:/bin:/usr/sbin:/usr/bin
     . /lib/lsb/init-functions
     NAME=ntp
     DAEMON=/usr/sbin/ntpd
     PIDFILE=/var/run/ntpd.pid
     # Use a local clock as the step ticker at startup.
     STEP_TICKER=192.168.1.1
     test -x $DAEMON || exit 5
     if [ -r /etc/default/$NAME ]; then
         . /etc/default/$NAME
     fi
     if [ -e /etc/ntp.conf.dhcp ]; then
         NTPD_OPTS="$NTPD_OPTS -c /etc/ntp.conf.dhcp"
     fi
     # Running as user ntp doesn't cut it.
     # RUNASUSER=ntp
     RUNASUSER=root
     UGID=$(getent passwd $RUNASUSER | cut -f 3,4 -d:) || true
     case $1 in
         start)
             log_daemon_msg "Synchronizing with $STEP_TICKER" "ntpd"
             ntpdate $STEP_TICKER
             log_daemon_msg "Starting NTP server" "ntpd"
             if [ -z "$UGID" ]; then
                 log_failure_msg "user \"$RUNASUSER\" does not exist"
                 exit 1
             fi
             start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE \
                 --startas $DAEMON -- -p $PIDFILE -u $UGID $NTPD_OPTS
             log_end_msg $?
             ;;
         stop)
             log_daemon_msg "Stopping NTP server" "ntpd"
             start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
             log_end_msg $?
             rm -f $PIDFILE
             ;;
         restart|force-reload)
             $0 stop && sleep 2 && $0 start
             ;;
         try-restart)
             if $0 status >/dev/null; then
                 $0 restart
             else
                 exit 0
             fi
             ;;
         reload)
             exit 3
             ;;
         status)
             pidofproc -p $PIDFILE $DAEMON >/dev/null
             status=$?
             if [ $status -eq 0 ]; then
                 log_success_msg "NTP server is running."
             else
                 log_failure_msg "NTP server is not running."
             fi
             exit $status
             ;;
         *)
             echo "Usage: $0 {start|stop|restart|try-restart|force-reload|\
                             status}"
             exit 2
             ;;
     esac

For NTP to work well, the local clock should run fairly closely to the clock that you are trying to synchronize it with. If it does not, you can try adjusting the clock, using the tickadj command. The default value for the tick (usually 10000) can be found by running:

     tickadj

If the clock is constantly running behind, you can cause it to slew ahead a bit, thereby regulating it more closely to the source you are trying to synchronize with. Small deviations from the default value are usually all that is required. For example:

     tickadj 9990

If the clock is constantly running ahead, you can cause it to slew behaind a bit, thereby regulating it more closely to the source you are trying to synchronize with. Once again, small deviations from the default value are usually all that is required. For example:

     tickadj 10010

If you cannot keep the clock on the Mythbuntu machine synchronized using NTP, because the clock you are trying to synchronize against is too poorly regulated or for other reasons, and the "true" keyword does not force NTP on the Mythbuntu machine to use the clock anyway (as is the case on earlier versions of Mythbuntu, such as 9.10), you may have to resort to synchronizing it at regular intervals using ntpdate.

The first step is to stop the NTP daemon from running. Begin by checking to see if it is actually installed and being started as a system service. Unfortunately, the update-rc.d command on Mythbuntu does not provide any "List" option to show whether a system service is set up to be run automatically. To find this out, you can do:

     ls -l /etc/rc.d/ntp

Look at the results of this command. If the symlink to /etc/init.d/ntp starts with 'K', NTP is shutdown at the runlevel given by "rcx". If the symlink starts with 'S', NTP is started at the runlevel given by "rcx". If NTP is started at runlevels 2, 3, 4, or 5, you will need to stop it. To do this, using the dain-bramaged update-rc.d, run:

     sudo /etc/init.d/ntp stop
     sudo rm -f /etc/rc.d/ntp
     sudo update-rc.d ntp stop 20 0 1 2 3 4 5 6 .

However, even this may not be sufficient to stop the ntp daemon. On some versions of Mythbuntu, this daemon is automatically started at boot time, regardless of the symlinks in /etc/init.d. If this is the case with your system, see the additional line to be added to crontab (below).

Incidentally, if you ever need to put NTP back the way it was originally installed, remove the crontab entries for ntpdate (see below) and run:

     sudo rm -f /etc/rc.d/ntp
     sudo update-rc.d ntp stop 20 0 1 6 . start 20 2 3 4 5 .
     sudo /etc/init.d/ntp start

You'll then need to add a line or two to crontab to cause ntpdate to be run often enough to keep the clocks synchronized. Using the editor:

     sudoedit /etc/crontab

Add something like the following:

     # Run ntpdate at regular intervals to synchronize the clock (ntp itself fails
     # in this respect).  Note that some annoying piece of s**t keeps starting the
     # ntp daemon, which prevents ntpdate from working.  So, just before we run
     # ntpdate, we kill the daemon.
     55 * * * * root /etc/init.d/ntp stop 2>&1 >/dev/null
     56 * * * * root /usr/sbin/ntpdate 192.168.1.1 2>&1 >/dev/null

Note that you best ensure that this is working. To do so, you can issue the ntpdate command periodically until you are sure all is well:

     /usr/sbin/ntpdate 192.168.1.1

will windge if the daemon is still running. If so, figure out why and fix it. Its no fun having 56-minute hour shows.

Keeping MythBackend Up And Running

>>>>>>
<<<<<<
MythBackend has a propensity to crash at inopportune moments (e.g. a couple hours after you've just left on a week's vacation). Well, nobody's perfect. Stuff happens. You can't expect to write code that never crashes. But, given Myth's status as a consumer appliance, you wonder why the Mythbuntu bozos didn't bother to include this watchdog for MythBackend in the distro. As it is now, you have to install it yourself.

This section was distilled from:

     http://www.mythtv.org/wiki/index.php/Using_pcsk_to_Supervise_mythbackend

Obtain the latest PCSK from http://www.nix.hu/projects/pcsk/. Uncompress and unpack the distro and build it. For example:

     mkdir pcsk
     cd pcsk
     wget http://downloads.nix.hu/downloads/pcsk/pcsk-0.0.5.tar.bz2
     tar xjf pcsk-0.0.5.tar.bz2
     cd pcsk-0.0.5
     make
     sudo make install

Create the following script (from Mythbuntu 8.04LTS) in your pcsk directory (see below for a Mythbuntu 9.04 script). I called mine mythtv-backend.pcsk:

     #! /bin/sh
     ### BEGIN INIT INFO
     # Provides:          mythtv-backend
     # Required-Start:    $local_fs $remote_fs $network
     # Required-Stop:     $local_fs
     # Default-Start:     50
     # Default-Stop:      S
     # Short-Description: Start/Stop the MythTV server.
     ### END INIT INFO
     #
     # modified mythtv-backend rc script
     # V0.22 by EW  6th Jun 2008:
     #       Updated for Mythbuntu 8.04LTS
     #       Removed mythtv-status
     # v0.21 by DJK 3rd Dec 2007:
     #       Removed -0 option for pcsk
     #               mythbackend seems to catch all signals (even when core
     #               dumping) and still exits 0! so we actually need to restart
     #               it no matter what its exit code was...
     # v0.2  by DJK 28th Nov 2007:
     #       Added pcsk supervision to restart if it dies
     #       Had to lose NICE for now, sorry.  Might be able to use renice
     #         sometime in the future?
     #       Call mythtv-status script for extra details
     #
     PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
     DAEMON=/usr/bin/mythbackend
     NAME="mythbackend"
     DESC="MythTV server"
     # Check that the mythbackend binary exists
     if ! [ -x "$DAEMON" ] ; then
             log_end_msg "Could not find $DAEMON binary"
             exit 1
     fi
     # Check that the pcsk binary exists somewhere in the path (I choose
     # /usr/local/bin)
     if ! PCSKBINARY="`which pcsk`" > /dev/null 2>&1; then
             log_end_msg "Could not find pcsk binary to supervise $NAME.  \
                 Try www.nix.hu/projects/pcsk..."
             exit 1
     fi
     . /lib/lsb/init-functions
     set -e
     prime_firewire()
     {
         if [ "$ENABLE_FIREWIRE" = "TRUE" ]; then
         log_daemon_msg "Priming Firewire "
             su - $USER -c "/usr/bin/mythprime"
         log_end_msg $?
         fi
     }
     USER=mythtv
     USER_HOME=$(grep ^$USER /etc/passwd | awk -F : '{print $6}')
     RUNDIR=/var/run/mythtv
     # mythbackend arguments - I've removed --daemon since pcsk will daemonise
     # it for me
     ARGS="--logfile /var/log/mythtv/mythbackend.log --pidfile $RUNDIR/$NAME.pid"
     EXTRA_ARGS=""
     NICE=0
     # The pid and log files for pcsk to use
     PCSKPIDFILE="$RUNDIR/$NAME-pcsk.pid"
     PCSKLOGFILE="/var/log/mythtv/mythbackend-pcsk.log"
     # Command line options for pcsk:
     # -r: restart the program if it dies
     # -e: log stderr, if there is any
     # -o: log stdout, if there is any
     ## -0: don't restart if the exit code was 0 - not using this at the moment
     # -w3: wait 3 sec before restart (default in original script)
     # -i10: increment each wait between restarts by 10s
     # -c10: restart up to 10 times if the restart is unsuccessful, before giving
     #       up
     # -m60: restart wasn't successful if the program exits within 60 sec
     # -p $PIDFILE: use that file for the pid
     # -l $PCSKLOGFILE: log file to keep track of things - good to set up
     #    logrotate
     PCSKOPTS="-reo -w3 -i10 -c10 -m60 -p $PCSKPIDFILE -l $PCSKLOGFILE"
     # Check for alternate options for mythtv-backend
     if [ -f /etc/default/mythtv-backend ]; then
       . /etc/default/mythtv-backend
     fi
     ARGS="$ARGS $EXTRA_ARGS"
     PCSKARGS="$PCSKOPTS $DAEMON -- $ARGS"
     mkdir -p $RUNDIR
     chown -R $USER $RUNDIR
     unset DISPLAY
     unset SESSION_MANAGER
     #create a symbolic link for mysql.txt so it can't be overwritten
     mkdir -p $USER_HOME/.mythtv
     chown -R $USER $USER_HOME/.mythtv
     if [ ! -e $USER_HOME/.mythtv/mysql.txt ]; then
             ln -s /etc/mythtv/mysql.txt $USER_HOME/.mythtv/mysql.txt
     fi
     case "$1" in
       start)
         # Check if pcsk is already supervising this process by checking for
         # the existance of a pidfile and that it's a currently running process
         PCSKPID=
         DAEMONPID=
         if [ -e "$PCSKPIDFILE" ] ; then
             read PCSKPID < "$PCSKPIDFILE"
             if [ -n "$PCSKPID" ] && [ -d "/proc/$PCSKPID" ] ; then
                 # pcsk is running, what about our daemon?
                 if [ -e "$RUNDIR/$NAME.pid" ] ; then
                     read DAEMONPID < "$RUNDIR/$NAME.pid"
                     if [ -n "$DAEMONPID" ] && [ -d "/proc/$DAEMONPID" ] ; then
                         # daemon is running too
                         log_success_msg "pcsk($NAME) (pid $PCSKPID) is already \
                             running, supervising $NAME (pid $DAEMONPID); \
                             use restart instead."
                         exit 1
                     fi
                     # daemon isn't running at the moment (pcsk might be waiting
                     # to respawn it) anyway, take the opportunity to restart
                     # everything now
                     log_success_msg "pcsk($NAME) (pid $PCSKPID) is running but \
                         $NAME is currently stopped.  Restarting now..."
                     $0 restart
                     exit $?
                 fi
             fi
         fi
         prime_firewire
         log_daemon_msg "Starting $DESC: pcsk($NAME) "
         # NICE gets ignored because pcsk doesn't support it and start-stop-daemon
         # would just nice pcsk, not the daemon.
         # Maybe we could somehow use renice?  Later...
         if ! start-stop-daemon --start --pidfile "$PCSKPIDFILE" \
             --chuid $USER --exec "$PCSKBINARY" -- $PCSKARGS ; then
             log_end_msg "failed (start-stop-daemon exited with code $?)"
             exit 1
         fi
         log_end_msg $?
         ;;
       stop)
         log_daemon_msg "Stopping $DESC: pcsk($NAME) "
         start-stop-daemon --stop --oknodo --pidfile "$PCSKPIDFILE" \
             --chuid $USER --retry 5 --exec "$PCSKBINARY" -- $PCSKARGS
         log_end_msg $?
         [ -e "$PCSKPIDFILE" ] && rm -f "$PCSKPIDFILE"
         [ -e "$RUNDIR/$NAME.pid" ] && rm -f "$RUNDIR/$NAME.pid"
         ;;
       restart)
         $0 stop
         sleep 3
         $0 start
         ;;
       force-reload)
         log_daemon_msg "force-reload not supported, restarting instead..."
         $0 restart
         ;;
       status)
         # We have an advantage in this mess that we know what the pidfiles
         # (and therefore pids) are.  Poor-man's status can be had by checking
         # for the existance of a pidfile and then that it's a currently running
         # process by looking for that directory in /proc
         PCSKPID=
         DAEMONPID=
         if [ -e "$PCSKPIDFILE" ] ; then
             read PCSKPID < "$PCSKPIDFILE"
             if [ -n "$PCSKPID" ] && [ -d "/proc/$PCSKPID" ] ; then
                 echo "pcsk($NAME) (pid $PCSKPID) is running..."
             else
                 echo "pcsk($NAME) is dead but pid file exists"
             fi
         else
             echo "pcsk($NAME) is stopped"
         fi
         if [ -e "$RUNDIR/$NAME.pid" ] ; then
             read DAEMONPID < "$RUNDIR/$NAME.pid"
             if [ -n "$DAEMONPID" ] && [ -d "/proc/$DAEMONPID" ] ; then
                 echo "$NAME (pid $DAEMONPID) is running..."
             else
                 echo "$NAME is dead but pid file exists"
             fi
         else
             echo "$NAME is stopped"
         fi
         ;;
       *)
         echo "Usage: $0 {start|stop|restart|status|force-reload(unsupported)}" \
             >&2
         exit 2
         ;;
     esac
     exit 0

The mythtv-backend script has been updated for Mythbuntu 9.04. Here is an updated version of the script for Mythbuntu 9.04:

     #! /bin/sh
     ### BEGIN INIT INFO
     # Provides:          mythtv-backend
     # Required-Start:    $local_fs $remote_fs $network
     # Required-Stop:     $local_fs
     # Default-Start:     2 3 4 5
     # Default-Stop:      0 1 6
     # Short-Description: Start/Stop the MythTV server.
     ### END INIT INFO
     #
     # modified mythtv-backend rc script
     # V0.23 by EW  22th Sep 2009:
     #       Updated for Mythbuntu 9.04
     # V0.22 by EW  6th Jun 2008:
     #       Updated for Mythbuntu 8.04LTS
     #       Removed mythtv-status
     # v0.21 by DJK 3rd Dec 2007:
     #       Removed -0 option for pcsk
     #               mythbackend seems to catch all signals (even when core
     #               dumping) and still exits 0! so we actually need to restart
     #               it no matter what its exit code was...
     # v0.2  by DJK 28th Nov 2007:
     #       Added pcsk supervision to restart if it dies
     #       Had to lose NICE for now, sorry.  Might be able to use renice
     #       sometime in the future?
     #       Call mythtv-status script for extra details
     #
     PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
     DAEMON=/usr/bin/mythbackend
     NAME="mythbackend"
     DESC="MythTV server"
     . /lib/lsb/init-functions
     # Check that the mythbackend binary exists
     if ! [ -x "$DAEMON" ] ; then
         log_failure_msg "Could not find $DAEMON binary"
         log_end_msg 1
         exit 1
     fi
     # Check that the pcsk binary exists somewhere in the path (I choose
     # /usr/local/bin)
     if ! PCSKBINARY="`which pcsk`" > /dev/null 2>&1; then
         log_failure_msg "Could not find pcsk binary to supervise $NAME.  \
             Try www.nix.hu/projects/pcsk..."
         log_end_msg 1
         exit 1
     fi
     set -e
     prime_firewire()
     {
         if [ "$ENABLE_FIREWIRE" = "TRUE" ]; then
             log_daemon_msg "Priming Firewire "
             su - $USER -c "/usr/bin/mythprime"
             log_end_msg $?
         fi
     }
     USER=mythtv
     USER_HOME=$(grep ^$USER /etc/passwd | awk -F : '{print $6}')
     RUNDIR=/var/run/mythtv
     # mythbackend arguments - I've removed --daemon since pcsk will daemonise
     # it for me
     ARGS="--logfile /var/log/mythtv/mythbackend.log --pidfile $RUNDIR/$NAME.pid"
     EXTRA_ARGS=""
     NICE=0
     # The pid and log files for pcsk to use
     PCSKPIDFILE="$RUNDIR/$NAME-pcsk.pid"
     PCSKLOGFILE="/var/log/mythtv/mythbackend-pcsk.log"
     # Command line options for pcsk:
     # -r: restart the program if it dies
     # -e: log stderr, if there is any
     # -o: log stdout, if there is any
     ## -0: don't restart if the exit code was 0 - not using this at the moment
     # -w3: wait 3 sec before restart (default in original script)
     # -i10: increment each wait between restarts by 10s
     # -c10: restart up to 10 times if the restart is unsuccessful, before giving
     #       up
     # -m60: restart wasn't successful if the program exits within 60 sec
     # -p $PIDFILE: use that file for the pid
     # -l $PCSKLOGFILE: log file to keep track of things - good to set up
     #    logrotate
     PCSKOPTS="-reo -w3 -i10 -c10 -m60 -p $PCSKPIDFILE -l $PCSKLOGFILE"
     # Check for alternate options for mythtv-backend
     if [ -f /etc/default/mythtv-backend ]; then
       . /etc/default/mythtv-backend
     fi
     ARGS="$ARGS $EXTRA_ARGS"
     PCSKARGS="$PCSKOPTS $DAEMON -- $ARGS"
     mkdir -p $RUNDIR
     chown -R $USER $RUNDIR
     unset DISPLAY
     unset SESSION_MANAGER
     # Check that the MythTV home directory exists.
     if [ ! -d $USER_HOME ]; then
         log_failure_msg "MythTV home directory, $USER_HOME does not exist."
         exit 1
     fi
     #create a symbolic link for mysql.txt so it can't be overwritten
     mkdir -p $USER_HOME/.mythtv
     chown -R $USER $USER_HOME/.mythtv
     if [ ! -e $USER_HOME/.mythtv/mysql.txt ]; then
         ln -s /etc/mythtv/mysql.txt $USER_HOME/.mythtv/mysql.txt
     fi
     #create config.xml for bindings
     if [ ! -e $USER_HOME/.mythtv/config.xml ]; then
         ln -s /etc/mythtv/config.xml $USER_HOME/.mythtv/config.xml
     fi
     case "$1" in
       start)
           # Check if pcsk is already supervising this process by checking for
           # the existance of a pidfile and that it's a currently running
           # process
           PCSKPID=
           DAEMONPID=
           if [ -e "$PCSKPIDFILE" ] ; then
               read PCSKPID < "$PCSKPIDFILE"
               if [ -n "$PCSKPID" ] && [ -d "/proc/$PCSKPID" ] ; then
                   # pcsk is running, what about our daemon?
                   if [ -e "$RUNDIR/$NAME.pid" ] ; then
                       read DAEMONPID < "$RUNDIR/$NAME.pid"
                       if [ -n "$DAEMONPID" ] && [ -d "/proc/$DAEMONPID" ] ; then
                           # daemon is running too
                           log_success_msg "pcsk($NAME) (pid $PCSKPID) is \
                               already running, supervising $NAME \
                               (pid $DAEMONPID); use restart instead."
                           exit 1
                       fi
                       # daemon isn't running at the moment (pcsk might be waiting
                       # to respawn it).  Anyway, take the opportunity to restart
                       # everything now
                       log_success_msg "pcsk($NAME) (pid $PCSKPID) is running \
                           but $NAME is currently stopped.  Restarting now..."
                       $0 restart
                       exit $?
                   fi
               fi
           fi
           prime_firewire
           log_daemon_msg "Starting $DESC: pcsk($NAME) "
           # NICE gets ignored because pcsk doesn't support it and
           # start-stop-daemon would just nice pcsk, not the daemon.
           # Maybe we could somehow use renice?  Later...
           if ! start-stop-daemon --start --pidfile "$PCSKPIDFILE" --chuid $USER \
               --exec "$PCSKBINARY" -- $PCSKARGS ; then
               log_failure_msg "failed (start-stop-daemon exited with code $?)"
               log_end_msg 1
               exit 1
           fi
           log_end_msg $?
           ;;
       stop)
           log_daemon_msg "Stopping $DESC: pcsk($NAME) "
           start-stop-daemon --stop --oknodo --pidfile "$PCSKPIDFILE" \
               --chuid $USER --retry 5 --exec "$PCSKBINARY" -- $PCSKARGS
           log_end_msg $?
           [ -e "$PCSKPIDFILE" ] && rm -f "$PCSKPIDFILE"
           [ -e "$RUNDIR/$NAME.pid" ] && rm -f "$RUNDIR/$NAME.pid"
           ;;
       restart|force-reload)
           log_daemon_msg "Restarting $DESC: $NAME "
           $0 stop
           sleep 3
           $0 start
           log_end_msg $?
           ;;
       status)
           # We have an advantage in this mess that we know what the pidfiles
           # (and therefore pids) are.  Poor-man's status can be had by checking
           # for the existance of a pidfile and then that it's a currently
           # running process by looking for that directory in /proc
           PCSKPID=
           DAEMONPID=
           if [ -e "$PCSKPIDFILE" ] ; then
               read PCSKPID < "$PCSKPIDFILE"
               if [ -n "$PCSKPID" ] && [ -d "/proc/$PCSKPID" ] ; then
                   echo "pcsk($NAME) (pid $PCSKPID) is running..."
               else
                   echo "pcsk($NAME) is dead but pid file exists"
               fi
           else
               echo "pcsk($NAME) is stopped"
           fi
           if [ -e "$RUNDIR/$NAME.pid" ] ; then
               read DAEMONPID < "$RUNDIR/$NAME.pid"
               if [ -n "$DAEMONPID" ] && [ -d "/proc/$DAEMONPID" ] ; then
                   echo "$NAME (pid $DAEMONPID) is running..."
               else
                   echo "$NAME is dead but pid file exists"
               fi
           else
               echo "$NAME is stopped"
           fi
           ;;
       *)
           N=/etc/init.d/$NAME
           echo "Usage: $N {start|stop|restart|force-reload|status}" >&2
           exit 2
           ;;
     esac
     exit 0

Once you've created the script, stop the backend, copy the script to the /etc/init.d directory, rename the original script to get it out of the way and then symlink the new script as the backend startup script:

     sudo /etc/init.d/mythtv-backend stop
     sudo cp mythtv-backend.pcsk /etc/init.d/mythtv-backend.pcsk
     cd /etc/init.d
     sudo chmod ugo+x mythtv-backend.pcsk
     sudo mv mythtv-backend mythtv-backend.orig
     sudo ln -s mythtv-backend.pcsk mythtv-backend
     sudo /etc/init.d/mythtv-backend start

Finally, you'll probably want to update the logrotate config file for mythtv-backend (/etc/logrotate.d/mythtv-backend) to rotate the log file created by pcsk too, by adding the following lines to it:

     /var/log/mythtv/mythbackend-pcsk.log {
         daily
         rotate 7
         notifempty
         copytruncate
     }

Backing Up the MythTV Database

The MySQL database (named mythconverg) that is used to store all of the information used by MythTV is very important. Without it, you ain't got nothin'. MythTV's backend and frontend won't run, you won't know what shows are recorded, no upcoming shows will be recorded, you won't be able to find any of your movies on your video server, etc. Heck, if you don't look out the window, you won't even be able to tell what the weather is like.

So, it should be pretty clear that having a regular backup of this database is very, very important.

The good news is that Mythbuntu, out of the can, comes with a regular backup procedure installed. The bad news is: that it only runs once a week; that it doesn't notify you of success or failure; that it only backs itself up to the local hard disk (where the backup will get destroyed right along with the database when the hard disk goes south).

So, if you're paranoid like us, you might want to tweak the backup process a bit to make it more robust. We altered the backup script to create and keep six daily backups as well as a couple months worth of weekly epoch backups, FTP the latest backup to a remote location, and send email when the backup succeeds.

Here is a copy of the altered backup script, which can be installed in the /etc/cron.daily directory (although, see the following "Scheduling Jobs When You Want Them To Run" section) instead of /etc/cron.weekly:

/etc/cron.daily/mythtv-database:

     #!/bin/bash
     #
     # /etc/cron.daily/mythtv-database script - check and backup mythconverg tables
     #
     # Copyright 2005/12/02 2006/10/08 Paul Andreassen
     #
     # Modified 2009/12/08 by Eric Wilde
     #           Switch to daily operation. Create weekly epoch backups as well
     #           as daily backups (this lets us keep multiple weeks of epoch
     #           backups, as well as a full week of daily backups). Email backup
     #           status, if requested. FTP backup to another server, if requested.
     #           Fix documentation.
     #
     # Modified 2012/06/07 by Eric Wilde
     #           Take advantage of the new database backup script, if it is
     #           available.  Better error discovery and reporting.
     #
     # Note that the new database backup script (as of MythTV 0.25) is dain
     # bramaged when it comes to database parameter handling.  Its behavior is
     # to check for a "config.xml" file in the ".mythtv" directory of the logged
     # in user.  Since the backup script is typically run periodically by
     # dropping it into the "cron.daily" or "cron.weekly" directory, it is run
     # under the user "root".
     #
     # The default installation of Mythbuntu makes a symlink to "/etc/config.xml"
     # from "/root/.mythtv/config.xml" so that, when the backup script runs, it
     # finds "/etc/config.xml".  Unfortunately, the default installation of
     # Mythbuntu installs an empty "/etc/config.xml".  The database parameter
     # handling in the backup script finds the empty file and gives up looking
     # further, despite the fact that it hasn't found the database name,
     # database user name, or anything else needed to backup the database.
     #
     # What it should do is carry on looking for parameters in the
     # "/etc/mythtv/mysql.txt" file but it does not.  If you will be running
     # this script from either the "cron.daily" or "cron.weekly" directory, the
     # easiest fix for this problem is to delete the symlink to the bogus empty
     # config file, like this:
     #
     #   sudo rm -f /root/.mythtv/config.xml
     #
     # Should you lose the mythconverg, MySQL database and you are running a
     # pre-0.22 version of MythTV (i.e. one that doesn't have the database backup
     # script), begin by deleting what's left of the database, if anything.
     #
     # Beware that performing this step will remove the entire database.  You
     # will lose all of your settings and will need to re-run the
     # /usr/share/mythtv/sql/mc.sql script to set up the database structure
     # before running the restore.
     #
     # To delete the database, do:
     #
     #   mysql -u mythtv -p 'drop database mythconverg'
     #
     # To restore (assuming that you've dropped the database), do:
     #
     #   mysql -u mythtv -p 'create database mythconverg'
     #   /usr/share/mythtv/sql/mc.sql
     #   zcat /var/backups/mythconverg.sql.gz | mysql -u mythtv -p mythconverg
     #
     # For more information on how to drop the database and create a new database,
     # see:
     #
        http://www.mythtv.org/docs/mythtv-HOWTO-23.html#dropdb
        http://www.mythtv.org/docs/mythtv-HOWTO-6.html#setupdb
     #
     # If you need to restore the mythconverg, MySQL database under a post-0.21
     # (i.e. 0.22 and up) version of MythTV, do this:
     #
     #   ./mythconverg_restore.pl --hostname=localhost \
     #       --drop_database --create_database \
     #       --directory=/var/backups --filename=mythconverg.sql.gz
     #
     set -e -u
     # Get the mythconverg database parameters.
     if [ -f /etc/mythtv/mysql.txt ]; then
         . /etc/mythtv/mysql.txt
     fi
     # Set the options and parameters used to backup the database.
     DBNAME="mythconverg"
     BACKDIR="/var/backups"
     DEBIAN="--defaults-extra-file=/etc/mysql/debian.cnf"
     OPTIONS="--all --complete-insert --extended-insert --quick --quote-names \
         --lock-tables"
     SAVEEPOCHS=8
     EMAILSTATUS="root"
     FTPHOST="myotherserver"
     FTPUSER="mythtv"
     FTPPASSWD="abigsecret"
     # If the mysql.txt file for MythTV sets the database name, use it instead of
     # the default.
     if [ "x$DBName" != "x" ] ; then
         DBNAME=$DBName
     fi
     # Figure out which kind of a backup (daily or epoch) we're doing.  Daily is
     # M-Sa, epoch is Su.
     DayNum=`date +%w`
     if [ "x$DayNum" != "x0" ] ; then
         BackupFile="${DBNAME}-daily.sql"
         SAVEEPOCHS=6
     else
         BackupFile="${DBNAME}.sql"
     fi
     BackupPath="${BACKDIR}/${BackupFile}.gz"
     # Check the database for consistency.
     /usr/bin/mysqlcheck $DEBIAN -s $DBNAME
     # Save some copies of the backup. If we're doing the daily backup, we'll
     # always keep 6 copies (M-Sa).  If we're doing the weekly (epoch) backup,
     # we'll save as many as the user asked for.
     /usr/bin/savelog -c $SAVEEPOCHS -l -n -q $BackupPath
     # Dump and zip the database backup.  Its either a daily or epoch backup,
     # depending on which day of the week it is.
     #
     # If the backup script exists, we'll use it because, presumably, it is
     # better.  Otherwise, we just do a straight dump.  Basically, they both
     # end up running the mysqldump command.
     if [ -f /usr/share/mythtv/mythconverg_backup.pl ]; then
         /usr/share/mythtv/mythconverg_backup.pl --hostname=localhost \
             --dbname=${DBNAME} --directory=${BACKDIR} \
             --filename=${BackupFile}
     else
         /usr/bin/mysqldump $DEBIAN $OPTIONS $DBNAME | gzip > $BackupPath
     fi
     # In order to see if the backup succeeded, we test to see if a non-zero
     # file was created.  Since savelog will have moved up any previous files,
     # there should be no file with the unadorned backup file name before the
     # backup starts.  Thus, if it creates a file and fills it with some bytes
     # its a pretty good bet that it worked.
     if [ ! -s $BackupPath ]; then
         # If we're not emailing status to anyone, we're all done.  Otherwise,
         # send a failure email message to the appropriate user.
         if [ ! "x$EMAILSTATUS" != "x" ] || [ ! -f /usr/bin/mail ]; then
             exit 1
         fi
      HostName=`hostname`
      /usr/bin/mail -s "Message from MythTV, failed database backup" \
          root <<-ENDMSG

The $DBNAME database on $HostName faile to be backed up to $BackupPath
ENDMSG

      exit 1

fi

      Add a note to the log.
     /usr/bin/logger -p daemon.info -i -t${0#*/} "$DBNAME checked and backed up."
     # FTP the backup somewhere safe, just in case the local disk goes south.
     if [ "x$FTPHOST" != "x" ] && [ "x$FTPUSER" != "x" ]; then
         echo -e "user ${FTPUSER} ${FTPPASSWD}\\nbin\\nput ${BackupPath} \
             ${BackupFile}.gz" | ftp -n $FTPHOST
     fi
     # If we're not emailing status to anyone, we're all done.  Otherwise, send an
     # email message to the appropriate user.
     if [ ! "x$EMAILSTATUS" != "x" ] || [ ! -f /usr/bin/mail ]; then
         exit 0
     fi
     HostName=`hostname`
     /usr/bin/mail -s "Message from MythTV, database backup" root <<-ENDMSG
     The $DBNAME database on $HostName has been successfully backed up
     to $BackupPath
     ENDMSG
     # End of file.

Note that you should remove the original mythtv-database script from the /etc/cron.weekly directory so that it doesn't run once a week and conflict with the running of this script. You can simply delete it or move it to some other directory, if you feel the need to keep it.

If you are running on a later version of MythTV (i.e. 0.22 or greater), you also need to remove the symlink in /root/.mythtv, like this:

     sudo rm -f /root/.mythtv/config.xml

To have the script email a completion message to you when it runs, set the EMAILSTATUS variable to the email address that you wish to send the message to. In the example, we've set EMAILSTATUS to "root". If you don't wish to send email anywhere, set EMAILSTATUS to "".

To have the script FTP a copy of the database to another server, you first need to set up a userid on that server. We use another Linux server and set the user's login script to /sbin/nologin so that nobody can actually login on that userid. The userid should, however, be created with a home directory so that FTP has somewhere to drop the files.

The name of the server should be set in the FTPHOST variable (in this case we've used "myotherserver") and the userid and password should be set in the FTPUSER and FTPPASSWD variables (in this case we've used "mythtv" and "abigsecret"). By setting FTPHOST and FTPUSER to something other than "", we cause the script to copy the database backup file to another server, where it will be safe if anything happens to Mythbuntu. The files will be copied to the home directory of the "mythtv" user on that server.

We then use the following logrotate file to rotate the copied files once a week and thereby keep a number of copies on the backup server:

/etc/logrotate.d/mythtv-database:

     /home/mythtv/mythconverg.sql.gz {
         missingok
         notifempty
         nocreate
         rotate 8
     }

In this case, we're keeping eight copies of the backup file and rotating once a week so we have eight weeks of backups.

>>>>>>
Scheduling Jobs When You Want Them To Run


Since Ubuntu, the platform which Mythbuntu is built upon, is primarily intended to be a laptop and personal workstation product, it has features which are meant to

/etc/stability

     mythtv-database

Rebooting

Move anacron stuff to:

     04:07 hourly
     04:17 daily
     04:27 weekly
     04:37 monthly

Reduce the xfs_fsr time to 6600 from 7200.

/etc/stability

     sysreboot

))))))
#!/bin/sh
#
# Shell script to reboot the system at regular intervals to heal all of # the Myth infelicities like recordings that never end, encoders that # don't get reset properly, lockups, etc., etc. #
/sbin/shutdown -r now
((((((

     /sbin/shutdown -r now
     -rwxr-x---

<<<<<<

Displaying MythTV Status at Login

>>>>>>
<<<<<<
By default, Mythbuntu installs an init script in /etc/init.d, called mythtv-status, and a similarly-named cron file in /etc/cron.d. The purpose of these two files are to cause current MythTV status to be written to the message of the day file (/var/run/motd) at regular intervals (every 10 minutes).

Unfortunately, the script, as installed, is broken. It fails to update the message of the day file and, if you enable sendmail for mail delivery, generates a windge email every cycle. Furthermore, the motd.new file that it creates isn't removed on shutdown, leading to the message of the day file being corrupted, if it is restarted. So, if you want actual status in your message of the day file, or don't want your mailbox filled up with 144 idiot messages every day, or want to be able to update the message of the day file, you need to fix the script. Here's our take on it:

     #!/bin/sh 
     #
     # Copyright (c) 2007 Javier Fernandez-Sanguino <jfs@debian.org>
     #
     # This is free software; you may redistribute it and/or modify
     # it under the terms of the GNU General Public License as
     # published by the Free Software Foundation; either version 2,
     # or (at your option) any later version.
     #
     # This is distributed in the hope that it will be useful, but
     # WITHOUT ANY WARRANTY; without even the implied warranty of
     # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     # GNU General Public License for more details.
     #
     # You should have received a copy of the GNU General Public License with
     # the Debian operating system, in /usr/share/common-licenses/GPL;  if
     # not, write to the Free Software Foundation, Inc., 59 Temple Place,
     # Suite 330, Boston, MA 02111-1307 USA
     #
     ### BEGIN INIT INFO
     # Provides:          mythtv-status
     # Required-Start:    $mythtv-backend
     # Required-Stop:     
     # Should-Start:      $named
     # Should-Stop:       
     # Default-Start:     2 3 4 5
     # Default-Stop:      0 1 6
     # Short-Description: Update the MOTD with the MythTV status
     # Description:       Update the MOTD with the MythTV status
     ### END INIT INFO
     PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
     DAEMON=/usr/bin/mythtv-status # Introduce the server's location here
     NAME=mythtv-status            # Introduce the short server's name here
     DESC="MythTV Status"          # Introduce a short description here
     test -x $DAEMON || exit 0
     . /lib/lsb/init-functions
     # Include defaults if available
     if [ -f /etc/default/$NAME ] ; then
     . /etc/default/$NAME
     fi
     # Use this if you want the user to explicitly set 'RUN' in 
     # /etc/default/
     if [ "x$RUN" != "xyes" ] ; then
     log_failure_msg "$NAME disabled, please adjust the configuration to \
         your needs "
     log_failure_msg "and then set RUN to 'yes' in /etc/default/$NAME to \
         enable it."
     exit
     fi
     set -e
     case "$1" in
     start|reload|refresh|restart|force-reload)
       log_daemon_msg "Updating $DESC" "$NAME"
       [ ! -f /var/run/motd.orig ] && cp /var/run/motd /var/run/motd.orig
     $DAEMON $ARGS -h $HOST >/var/run/motd.new 2>/dev/null
     if [ -f /var/run/motd.new ]; then
       cat /var/run/motd.orig /var/run/motd.new >/var/run/motd 2>/dev/null
       touch "/var/run/$NAME" 
     else
       if [ -f /var/run/motd.orig ]; then
         cp /var/run/motd.orig /var/run/motd
       else
         rm -f /var/run/motd 2>/dev/null
       fi
      rm -f "/var/run/$NAME" 2>/dev/null || true

fi
log_end_msg 0
;;
stop)
log_daemon_msg "Stopping $DESC" "$NAME" [ -f /var/run/motd.orig ] && cp /var/run/motd.orig /var/run/motd rm -f /var/run/motd.orig 2>/dev/null rm -f "/var/run/$NAME" 2>/dev/null || true log_end_msg 0
;;
status)
if [ -f "/var/run/$NAME" ]; then

      log_success_msg "$NAME is running"
      exit 0
    else
      log_failure_msg "$NAME is not running"
      exit 1

fi
;;
*)
N=/etc/init.d/$NAME
echo "Usage: $N {start|stop|reload|refresh|status}" >&2 exit 1
;;
esac

     exit 0

Freeing Up Storage

No matter how big your storage pools are, it seems that the recorded content always expands to fit the space available. If you are like us, you never manage to get enough time to watch everything you want to watch so that, eventually, you are bound to start running out of space for new recordings. When the time comes, you could just buy some larger hard drives or you could bite the bullet and clean up the disks instead.

In this section, we describe a script that can help you make the decision as to which programs to watch first (thereby freeing up the most space), which programs are so old that you'll never watch them, and which programs are orphaned from the database and therefore using up space for nothing.

Obviously, orphaned programs are the low hanging fruit, since nobody even knows that they exist. Despite its best efforts to keep track of things, sometimes orphaned recordings are created when Mythbuntu loses the connection to recording files in the storage groups, especially when storage groups are spread across multiple systems. This occurs most often when database updates are done on the master backend without the benefit of communication with the secondary backends (e.g. when a network connection goes down).

Occasionally, MythTV will ask you if your want to delete a database entry (i.e. for a recorded program) despite the fact that the file associated with it cannot be found. The reason may well be that MythTV querried the remote, secondary backend that owns the file but the secondary backend didn't respond. The clever MythTV code then assumes that the file doesn't exist (not that we can't talk now because the network is down). If you allow it to proceed with the database delete, an orphaned file will be created.

On other occasions, power failures, system failures, etc., may lead to orphaned files with no database entries. Regardless of how they are created, orphaned files occupy space, thereby reducing the amount of recording capacity available and leading to a cluttered storage groups. When you only have three or four terabytes of storage left for recording, its not a good thing (tm).

Further good candidates for cleanup are old recordings that have been hanging around forever and that are large in size (depending on the source, capture method and content type, the file size of a recording on disk can bear little relationship to its length in minutes). If you are ever planning to watch these recordings, watching the largest ones first can be the most productive in terms of reclaimed space. If you aren't going to watch these recordings, seeing them listed as really old could provide the incentive needed to delete them.

Finally, watching the largest recordings first can give back the most space in the quickest time, in terms of viewing time. Thus, using a list of recordings ordered by disk size, to assist you with deciding which recordings to watch first, will prove to be the most fruitful approach when space needs to be reclaimed.

The cleanup script, shown below, can be used to assist with choosing which recording files to delete, which recordings to watch first and which recordings to simply delete. However, before we proceed with that, we should note that the contrib directory has a Perl script which can be used to identify orphaned recording files and optionally reinsert them into the database. If you wish to use it to recover orphaned recordings instead of just deleting them, you should unzip it and install it somewhere where it can be run:

     su
     cp /usr/share/doc/mythtv-backend/contrib/myth.rebuilddatabase.pl.gz
        /usr/local/bin
     cd /usr/local/bin
     gunzip myth.rebuilddatabase.pl.gz
     chmod ugo+ myth.rebuilddatabase.pl

Information about how to run this script can be found at:

     http://www.mythtv.org/wiki/Myth.rebuilddatabase.pl

Our cleanup script can be installed in /usr/local/bin as well:

     #!/bin/bash
     #
     # cleanup - Shell script to help the user clean up MythTV recordings.
     #
     #
     # Usage
     # -----
     #
     # cleanup storage_path [age] [host] [user] [password]
     #
     #      storage_path      The full path (minus trailing slash) of the storage
     #                        directory that is to be checked for orphaned and
     #                        aged recordings.
     #
     #                        Note that you can give a list of storage
     #                        directories to check by enclosing the list in
     #                        double quotes and separating each individual
     #                        path by a space.
     #
     #      age               The optional age in days.  Any recordings that are
     #                        older than this many days should be included in the
     #                        list of recordings to be cleaned up.  The default,
     #                        if omitted, is 365.
     #
     #      host              The optional, remote host where the database is
     #                        kept.  If you are running this script on a
     #                        secondary backend, you should supply the hostname
     #                        of the master backend.  The default is no hostname,
     #                        which will cause the the query to be run on
     #                        localhost.
     #
     #      user              The optional user name to connect to the database
     #                        with.  The default, if omitted, is obtained from
     #                        the MythTV "mysql.txt" file.  If this file cannot
     #                        be found, the default is "mythtv".
     #
     #                        Typically, you would need to supply this parameter
     #                        if you are using a remote host for the database
     #                        and the local "mysql.txt" file doesn't exist or
     #                        has an incorrect user name.
     #
     #      password          The optional password for the user chosen.  The
     #                        default, if omitted, is obtained from the MythTV
     #                        "mysql.txt" file.  If this file cannot be found,
     #                        the default is "mythtv" (yeah, like that'll work
     #                        -- you should probably use the password that you
     #                        set when you configured MythTV).
     #
     #                        Typically, you would need to supply this parameter
     #                        if you are using a remote host for the database
     #                        and the local "mysql.txt" file doesn't exist or
     #                        has an incorrect password.
     #
     #
     # Description
     # -----------
     #
     # This script can be used by the user, when they are running out of space,
     # to decide which MythTV recordings should be cleaned up.  Cleanup must be
     # done maually by the user, either through the MythTV UI or, in the case of
     # orphaned recordings, from the command line.
     #
     # Orphaned recordings are listed first since the user will, presumably, want
     # to delete them right away.  The listing of old programs then follows in
     # order, sorted by size.  The expectation is that the user then watches and
     # deletes the recordings.
     #
     # Given the premise of the preceding paragraph, for orphaned files, the file
     # name is given.  The user deletes them from the command line with "rm".
     # For programs that aren't orphaned but that meet the age cutoff, the
     # program name, instead of the file name, is given, along with the program's
     # size, so that the user can find the program in MythTV's recorded programs
     # listing.
     #
     #
     # Revision History
     # ----------------
     #
     # E. Wilde    2012Oct24  Use mysql.txt, allow multiple paths, prioritize
     #                        orphan reporting.
     # E. Wilde    2012May7   Initial coding.
     #
     ############################################################################
     # The possible locations of the MythTV "mysql.txt" file, in order of usage.
     MythConfigs=("/etc/mythtv/mysql.txt" \
       "/usr/local/share/mythtv/mysql.txt" \
       "/usr/share/mythtv/mysql.txt" \
       "/usr/local/etc/mythtv/mysql.txt")
     # Default values.  You can change these, if you don't want to have to supply
     # these values on the command line all the time.
     DefAge=365
     DefUser="mythtv"
     DefPasswd="mythtv"
     # Let's see if we can figure out the MythTV database userid and password.
     for MythConfig in "${MythConfigs[@]}"; do
       if [ -f $MythConfig ]; then
         . $MythConfig
      if [ x"$DBUserName" != "x" ] ; then
        DefUser=$DBUserName
      fi
      if [ x"$DBPassword" != "x" ] ; then
        DefPasswd=$DBPassword
      fi

fi
done

     # See if there's a storage path supplied.
     if [ x"$1" == "x" ] ; then
       echo Storage directory path omitted
       exit 1
     fi
     # See if there's an age supplied.
     if [ x"$2" == "x" ] ; then
       Age=$DefAge
     else
       Age=$2
     fi
     # See if there's a hostname supplied.
     if [ x"$3" == "x" ] ; then
       Host=""
     else
       Host=" -h$3"
     fi
     # See if there's a userid and password supplied.
     if [ x"$4" == "x" ] ; then
       Userid=$DefUser
     else
       Userid=$4
     fi
     if [ x"$5" == "x" ] ; then
       Password=$DefPasswd
     else
       Password=$5
     fi
     # Start with the title.
     echo Recordings stored in: $1
     # Create a temp file that we can use for sorting.
     TmpFile=`mktemp /tmp/CleanupRecorded.XXXXXXXXXX`
     if [ ! $TmpFile ] ; then
       echo Unable to create temporary file, sorting not possible
     fi
     # Process all of the paths that we were given.
     for MythPath in $1; do
     # Get a listing of all of the recording files in the given directory, that
     # are older than the time given, and get their information from the
     # database.
     find $MythPath -mtime +$Age -regex '.*\(avi\|m4v\|mkv\|mp4\|mpg\|nuv\)' | while read Line; do
      # Strip the path name off the recording file name.  Only the file names
      # are stored in the database.
      File=`echo $Line | sed -ne "s|.$MythPath/\(.\)|\1|p"`
      if [ ! -f "$MythPath/$File" ] ; then continue ; fi
      # Let's see if we can find the recording in the database.  If not, it is
      # orphaned.  All of the orphans are listed first since, presumably, the
      # user will want to delete them right away.
      Info=`mysql -e "select title, starttime, subtitle from recorded where basename='$File';" -N -u$Userid -p$Password$Host mythconverg`
      if [ x"$Info" == "x" ] ; then
        echo Orphaned, $File
      else
        FileSize=`stat -c %s $MythPath/$File`
        if [ $TmpFile ] ; then
          echo $FileSize, $Info >>$TmpFile
        else
          echo $FileSize, $Info
        fi
      fi
     done
     done
     # If we were able to capture the output, sort it in order of descending size.
     if [ $TmpFile ] ; then
       sort -nr $TmpFile
       rm -f $TmpFile
     fi
     # That's all for Ray Nance.
     exit 0

Update Manager -- Not Another Good Idea

Later versions of Mythbuntu come with a version of the Update Manager that is configured to pop up a window and ask the user if they want to perform the updates on the spot. I suppose this could be construed as desirable behavior in some instances but it will come as a huge surprise to anyone using Mythbuntu.

The Update Manager pops up at some random time, when it decides that updates are available or it is time to nag the user, and is given the focus, as a consequence. However, the Myth frontend application remains in the foreground thereby obscuring the Update Manager. This effectively redirects keyboard input to a hidden application which has no idea what to do with it. The viewer is frantically pushing keys on the remote contro, to get their program to pause, rewind, skip commercials, etc., etc. but to no avail. They have no idea that the Update Manager is sucking up all of their key presses and throwing them in the trash, because it is invisible, so they think the system has crashed. Its all pretty comical.

There are two ways to disable the update-manager popup. The first is from the Mythbuntu system, using the gconf-editor application. This secret application allows you to change Gnome desktop settings. You may have to install it (since it is not installed by default) using the package manager or via:

     sudo apt-get install gconf-editor

Once you've installed the editor, you can pick it from the System menu, if it is there, or launch it from a command window via:

     gconf-editor&

The editor window will appear. You should navigate your way through the tree to the apps/update-notifier settings. There you will see a setting named "auto_launch" which has a checkbox for its value. Uncheck that box. Even if the box isn't checked, check it and uncheck it. This will acutally force the setting to be written to the configuration, which it probably wasnt't before. The default behavior (always do whatever is most annoying) needs to be overridden, which it will be when you exit from the editor window.

The alternative method is to run this command, from a SSH terminal session, while you are logged in as the user the normally runs the Myth frontend (this is very important):

     gconftool -s --type bool /apps/update-notifier/auto_launch false

Note that, if you run this command as root or some other user, since the Gnome settings are stored in the user's home directory, the auto launch flag will not have any effect on the session that runs the Myth frontend (i.e. the annoying behavior will still be with us).

However, you may want to run this command while logged in as root, so that when you log in as root (you did remember to set the root password, above, didn't you) you won't be annoyed by the Update Manager either.

You can check that the auto launch flag has been properly set by looking in the home directory of the user. Doing:

     ls -l /home/mythuser/.gconf/apps/update-notifier

Should show something like:

     -rw-r--r-- 1 mythuser mythuser    113 2009-09-11 09:15 %gconf.xml

If you display this file, you should see something like:

     <?xml version="1.0"?>
     <gconf>
       <entry name="auto_launch" mtime="1252674870" type="bool" value="false"/>
     </gconf>

The Update Manager also comes preconfigured to nag the user in other ways, besides the popup that is disabled above. For example, it will periodically pop up a modal dialog box to show the user a list of updates and system upgrades. The dialog box is not hidden but, even if the user can figure out how to move the mouse over the dialog box (mostly, the mouse is hidden, under the Mythbuntu frontend application), you probably don't want them applying the updates or upgrading the system by accident.

The best approach, in our opinion, is to launch the Update Manager from the System menu and the click on the Settings button. From the dialog box that pops up, change the "Automatically check for updates" field to "Never" and the "Notify me of a new Ubuntu version" to "Never". When the windge dialog box that says you must check for updates manually appears, check the box about never showing me this again Once you close this final dialog box and exit the Update Manager, you should experience no further problems.

Useful Software

The Synaptics Package Manager is a GUI-based application which is useful for adding and removing packages to/from your system. The Ubuntu Software Center is not. Many users who upgrade to a later version of Mythbuntu, from an earlier version, will miss the Synaptics Package Manager. The won't find the selling of magazine subscriptions by their package manager, while they are trying to install software, to be an amusing feature. Fortunately, you can easily add the Synaptics Package Manager back in, from the command line, like this:

     sudo apt-get install synaptic

The "Useless and Annoying Software" section details how the Ubuntu Software Center package can be removed, if you don't wish to keep it around (and, why would you).

Using the Synapics Package Manager, you can install all of the useful packages you'll ever need. Here is a list of some of the one's that we've found useful:

     emacs
     vsftpd
     sendmail (if you'd like email delivery)
     mailutils (mail utilities such as "mail")

You can also install these packages using apt-get, as follows:

     sudo apt-get install emacs
     sudo apt-get install vsftpd
     sudo apt-get install sendmail
     sudo apt-get install mailutils

EMACS

If you installed EMACS and you intend to use it for all of your editing needs, probably the very first thing you will want to do is to configure it not to leave turds lying around everywhere. That way, you can then edit files with impunity and not have to worry about cleaning up Stallman's mess everywhere you go. Edit both the ~/.emacs and the /root/.emacs (if you'll do any editing as root). Add, at least:

     (custom-set-variables
     '(make-backup-files nil))
     (custom-set-faces)

Another annoying feature (or should we say, non-feature) is the behavior of the latest EMACS versions whereby filename completion, which used to be bound to the space bar, no longer works. Apparenly, the whiners convinced the developers (in a rare display of political correctness stupidity) that an existing feature, which has been around forever, should be turned off, by default, to accomodate a small group of really annoying people who are dumb enough to want to put blanks in their file names. God help us. The Macintosh winkies are taking over.

At least we aren't so clueless to not know how to fix default behavior that we don't like by editing the config file. Heaven help us if those few idiots who actually use blanks in their file names should have to figure that one out. Better to f**k the rest of us. Well, if you don't like it, try adding the following to the EMACS config files mentioned above:

     (define-key minibuffer-local-filename-completion-map
       " " 'minibuffer-complete-word)
     (define-key minibuffer-local-must-match-filename-map
       " " 'minibuffer-complete-word) 

VSFTPD

The VSFTP daemon comes preconfigured for anonymous FTP only. And, the default timeouts don't allow much time for thinking about what you want to send/receive. If you're like us, you want to hack the configuration file (/etc/vsftpd.conf) and set the following:

     local_enable=YES
     write_enable=YES
     local_umask=022
     pasv_promiscuous=YES             # if you want PASV to actually work
     idle_session_timeout=7200        # if you want a couple of hours timeout

Sendmail

If you wish email messages to be delivered from the various automatic subsystems on your Mythbuntu machine, you can install sendmail and the mailutils packages (see above) on the system. Then, you can hack sendmail.mc on the Mythbuntu machine to use your regular SMTP server to relay the mail. Begin by adding a SMART_HOST line at the end of the macro file (probably /etc/mail/sendmail.mc) and aim it at your SMTP server:

     dnl #
     dnl # Smart host (the guy who really delivers the mail)
     dnl #
     define(`SMART_HOST',`pri-host')dnl

Rebuild the sendmail.cf file:

     sudo sendmailconfig

Answer yes to all of the questions. This will restart sendmail at the same time.

You should now be able to send mail to the main mail server from the local Mythbuntu machine (if relaying is denied, you may need to add the Mythbuntu machine's address to relay-domains on the mail server). You also might want to alias the following users in /etc/aliases on the local machine:

     root: joeblow@mydomain.com
     mythuser: joeblow@mydomain.com

Where "mythuser" is the name of the user that Mythbuntu was installed under (i.e. the initial user from setup) and joeblow@mydomain.com is the name of the user whom the mail should delivered to on the smart host.

As long as the aliased name contains a domain name, it will be forwarded by the local sendmail to the SMART_HOST. If the domain name is marked as a local domain on the main mail server, the mail will get delivered there. Note that you need to rebuild the aliases database and then recycle sendmail on the Mythbuntu machine when you add aliases to /etc/aliases:

     sudo newaliases
     /etc/init.d/sendmail restart

Useless and Annoying Software

Mythbuntu installations are coming with more and more useless packages pre-installed. Why should M$ platforms be the only platforms that come with craplets, crapware and bloatware? Linux (and especially Ubuntu) should get in on the game. Looks like we're taking this idea to heart.

One particularly useless as well as annoying piece of crapware is the Ubuntu Software Center. Not only is this an especially lame attempt at a package manager but it also tries to sell you magazine subscriptions as you go. Who needs this junk? The Synaptics Package Manager (see the "Useful Software" section) works quite well, thank-you very much. To get rid of the Ubuntu Software Center, you can enter this command on the command line:

     sudo apt-get purge software-center

Another really annoying "feature" is Zeroconf and the daemon that implements it, AVAHI. This feature is a misguided attempt to make all of your computers work like Macs, with their plug 'n pray Bonjour protocol. Just plug your computer into a network port and it will figure everything out. An idiot could do it. Sadly, if you're an idiot, you won't be using Mythbuntu since it is difficult to operate itself and way above the idiot level, so software for idiots like Zeroconf just gets in the way.

Unfortunately, for our purposes and especially when we're running a master backend, we need to know the IP address of each machine. We can't have some well-meaning but misguided piece of crapware making up IP addresses for us. But, that's just what AVAHI does. If your DHCP server is a wee bit slow to respond, AVAHI will make up an incorrect IP address for you and then nothing will work. Or, if you forget to assign a static IP address, same thing. Hours of debugging fun will then follow, since your network will appear to be working but nothing will be where you think it is. And how about this? If your network connection goes down, even for a few seconds, AVAHI steps in, makes up an IP address and then all of your other network addresses stop working when the network comes back. Who dreams this stuff up?

To get rid of Zeroconf, it is simply necessary to get rid of AVAHI:

     apt-get purge avahi-autoipd avahi-daemon

Once you're done, you can yo-yo the network down/up. On earlier versions of Mythbuntu, this was easy, simply requiring a few commands to be typed on the console. With the later versions of Mythbuntu, that use upstart, this theoretically can be accomplished with:

     sudo stop networking
     sudo start networking

Although, under Mythbuntu 12.04LTS, this method doesn't work and seems to leave networking sort of in limbo (nice work, guys -- that upstart thingy is a real winner). Of course, the ultimate test is to reboot the system, which works even when upstart doesn't. Either way, listing the routes on the system should show that everything is working OK:

     /sbin/route

You should see something like this (with no mention of link-local or any 169.254.x.x addresses):

     Kernel IP routing table
     Destination     Gateway        Genmask         Flags Metric Ref   Use Iface
     default         192.168.1.1 0.0.0.0         UG    100    0       0 eth0
     192.168.1.0     *              255.255.255.0   U     0      0       0 eth0

CUPS or the Common Unix Printing System is a fine system that does an excellent job of spooling printed output to all sorts of printers. Its just not something that most people need to have installed on their media computers. If you don't think you'll be wanting to print anything from your Mythbuntu system, you may wish to uninstall CUPS like this:

     sudo apt-get purge cups

These packages auto-install a number of packages which may not be needed after the useless packages have been purged. You can remove them, once you've removed all of the useless packages, by running:

     sudo apt-get autoremove

MythWeather

MythWeather can be installed on the later versions of Mythbuntu by selecting it from the list of plug-in applications from the Mythbuntu configuration application (either run this app from the System menu choice or run it by selecting Mythbuntu setup from the frontend setup menu. Once MythWeather is installed, setup should be easy (or so you think). A good synopsis of the vanilla part of setup is given here:

     http://www.mythtv.org/wiki/MythWeather

Fortunately, all of the code that extracts weather data from remote sites via HTTP is written in Perl so that it can be easily modified. Unfortunately, it is quite badly written. If any of the extracted weather data changes in the slightest, the Perl code craps out and the MythWeather display either hangs or shows a blank screen.

The worst offender is the NWS XML extraction module that is used to obtain current weather information from the National Weather Service -- probably the one script you're most likely to want to use. Consequently, if you want to see the current weather, you'll probably have to patch the extraction module as follows (all changes are marked with #ew):

/usr/share/mythtv/mythweather/scripts/us_nws/nwsxml.pl:

     #! /usr/bin/perl -w
     use strict;
     use XML::Simple;
     use LWP::Simple;
     use Data::Dumper;
     use Getopt::Std;
     use NWSLocation;
     our ($opt_v, $opt_t, $opt_T, $opt_l, $opt_u, $opt_d); 
     my $name = 'NWS-XML';
     my $version = 0.2;
     my $author = 'Lucien Dunning';
     my $email = 'ldunning@gmail.com';
     my $updateTimeout = 15*60;
     my $retrieveTimeout = 30;
     my @types = ('cclocation', 'station_id', 'latitude', 'longitude',
             'observation_time', 'observation_time_rfc822', 'weather',
             'temperature_string', 'temp', 'relative_humidity', 'wind_string',
             'wind_dir', 'wind_degrees', 'wind_speed', 'wind_gust',
             'pressure_string', 'pressure', 'dewpoint_string', 'dewpoint',
             'heat_index_string', 'heat_index', 'windchill_string', 'windchill',
             'visibility', 'weather_icon', 'appt', 'wind_spdgst');
     my $dir = "./";
     getopts('Tvtlu:d:');
     if (defined $opt_v) {
         print "$name,$version,$author,$email\n";
         exit 0;
     }
     if (defined $opt_T) {
         print "$updateTimeout,$retrieveTimeout\n";
         exit 0;
     }
     if (defined $opt_l) {
         my $search = shift;
         NWSLocation::AddLocSearch($search);
         NWSLocation::AddStateSearch($search);
         NWSLocation::AddStationIdSearch($search);
         my $results = doSearch();
         my $result;
         while($result = shift @$results) {
             if ($result->{latitude} ne "NA" && $result->{longitude} ne "NA") {
                 print "$result->{station_id}::";
                 print "$result->{station_name}, $result->{state}\n";
             }
         }
      exit 0;
     }
     if (defined $opt_t) {
         foreach (@types) {print; print "\n";}
         exit 0;
     }
     if (defined $opt_d) {
         $dir = $opt_d;
     }
     # we get here, we're doing an actual retrieval, everything must be defined
     my $loc = shift;
     if (!(defined $opt_u && defined $loc && !$loc eq "")) {
         die "Invalid usage";
     }
     my $units = $opt_u;
     my $base_url = 'http://www.weather.gov/data/current_obs/';
     my $response = get $base_url . $loc . '.xml';
     die unless defined $response;
     my $xml = XMLin($response);
     foreach (@types) {
         my $label;
         my $key;
      $label = $_;
      if (/temp$/ || /dewpoint$/ || /heat_index$/ || /windchill$/) {
          $key = $ . 'f' if $units =~ /ENG/;
          $key = $ . 'c' if $units =~ /SI/;
      }
      elsif (/pressure$/) {
          $key = $ . 'in' if $units =~ /ENG/;
          $key = $ . 'mb' if $units =~ /SI/;
      }
      elsif (/wind_speed/) {
          if ($units =~ /ENG/) {
              $key = 'wind_mph';
          } else {
              $key = 'wind_kph';
              $xml->{$key} = int($xml->{'wind_mph'} * 1.609344 + .5);
          }
      } elsif (/wind_gust/) {
          if ($units =~ /ENG/ || $xml->{'wind_gust_mph'} eq 'NA') {
              $key = 'wind_gust_mph';
          } else {
              $key = 'wind_gust_kph';
              $xml->{$key} = int($xml->{'wind_gust_mph'} * 1.609344 + .5);
          }
      } elsif (/visibility/) {
          if ($units =~ /ENG/) {
              $key = 'visibility_mi';
          } else {
              $key = 'visibility_km';
              $xml->{$key} = int($xml->{'visibility_mi'} * 1.609344 + .5);
          }
      } elsif (/weather_icon/) {
          $key = 'weather_icon';
          $xml->{$key} = 'unknown.png';
          local FH;
          open(FH, "icons") or die "Cannot open icons";
          while(my $line = <FH>) {
              chomp $line;
              if ($line =~ /$xml->{'icon_url_name'}::/) {
                  $line =~ s/.:://;
                  $xml->{$key} = $line;
                  last;
              }
          }
      } elsif (/cclocation/) {
          $key = 'location';   
      } elsif (/appt$/) {
  #ew        if ($xml->{windchill_f} eq 'NA') {
          if (!defined($xml->{windchill_f}) || $xml->{windchill_f} eq 'NA') { #ew
              $key = 'heat_index_f' if ($units =~ /ENG/); 
              $key = 'heat_index_c' if ($units =~ /SI/);
          } else { 
              $key = 'windchill_f' if ($units =~ /ENG/); 
              $key = 'windchill_c' if ($units =~ /SI/);
          };
      
      } elsif (/wind_spdgst/) {
          # relying on this being after speed and gust
          $key = "wind_spdgst";
          if ($units =~ /ENG/ ) {
              if (defined($xml->{"wind_gust_mph"})) { #ew
                  $xml->{$key} = "$xml->{wind_mph} ($xml->{wind_gust_mph})"; #ew
              } else { #ew
                  $xml->{$key} = "$xml->{wind_mph} ($xml->{wind_mph})"; #ew
                  } #ew
          } else {
              if (defined($xml->{"wind_gust_kph"})) { #ew
                  $xml->{$key} = "$xml->{wind_kph} ($xml->{wind_gust_kph})"; #ew
              } else { #ew
                  $xml->{$key} = "$xml->{wind_kph} ($xml->{wind_kph})"; #ew
                  } #ew
          }
      } else {
          $key = $label;
      }
      if (defined($xml->{$key})) { #ew
          printf $label . "::" . $xml->{$key}. "\n";
      } #ew
      else { #ew
          if ($label =~ /string/i) { #ew
              printf $label . "::none\n"; #ew
          } #ew
          else { #ew
              printf $label . "::" . #ew
                  (($units =~ /ENG/) ? $xml->{"temp_f"} : $xml->{"temp_c"}) . #ew
                  "\n"; #ew
          } #ew
      } #ew

}

Once you install this copy of the script in the scripts directory:

     /usr/share/mythtv/mythweather/scripts/us_nws

You should make sure the permissions on nwsxml.pl look like this:

     -rwxr-xr-x 1 root root   4868 2009-09-11 21:51 nwsxml.pl

This will allow MythWeather to execute the script to extract weather data from the NWS. You should now be able to include the Current Conditions page in the list of pages to be shown by MythWeather.

Adjusting Samba To Fit In With Your Network

Samba server comes pre-installed on MythTV and set up to share the default recordings, videos and music directories. To our thinking, the choices made for these shares are badly made. Firstly, the workgroup "MSHOME" is chosen as the domain to belong to. Secondly, I don't really care if the media directories are shared.

The following Samba configuration may be more of use to you:

>>>>>>
/etc/samba/smb.conf:

     [global]
     workgroup = WORKGROUP
     server string = %h server (Samba, Mythbuntu)
     log file = /var/log/samba/log.%m
     max log size = 1000
     syslog = 0
     panic action = /usr/share/samba/panic-action %d
     dns proxy = no
     security = share
     [Root]
     comment = Root Directory
     path = /
     public = no
     browseable = yes
     writeable = yes
     write list = @joeblow

Once you've made these changes to smb.conf, don't forget to recycle Samba for them to take effect:

     sudo /etc/init.d/samba restart

Or, for later versions of Mythbuntu (e.g. 12.04) that use init, recycle it like this:

     stop smbd
     stop nmbd
     start nmbd
     start smbd

Also, you may want to add a user or two so that they can access the shared directory:

     smbpasswd -a joeblow

Supply an appropriate password (remember, this needn't be the user's login password).
<<<<<<

UPS Monitoring with NUT

Begin by installing the latest version of NUT using the Package Manager or Ubuntu Software Center. You will need these packages (plus any dependencies):

     nut
     nut-cgi

You can also install these packages using apt-get, as follows:

     sudo apt-get install nut
     sudo apt-get install nut-cgi

Since Ubuntu uses udev, we need to hack one of the udev rules to give permission on the appropriate serial port. The best place is in a separate rules file that you make up just for this purpose (that way, subsequent releases of NUT won't monkey with your rules for the serial port). We suggest calling the file "52_nut-ttyups.rules. It should be created in the /etc/udev/rules.d directory. You should add something like the following to that file, depending on which serial port you need to use:

     # udev rules for NUT serial drivers
     # Special case for the UPS devices
     KERNEL=="ttyS1", GROUP="nut", MODE="0660"

/etc/nut/ups.conf:

     Copy the file ups.conf.sample and hack it to set up the machine/UPS
     configuration, per the instructions in the INSTALL file.  For an APC
     SmartUPS, the following config information applies:
     [fusion-reactor]
          driver = apcsmart
          port = /dev/ttyS0

/etc/nut/upsd.conf:

     On older versions of NUT, copy the file upsd.conf.sample and replace the
     existing rules with:
     ACL all 0.0.0.0/0
     ACL localhost 127.0.0.1/32
     ACL homeworld 192.168.1.0/24
     ACCEPT homeworld
     ACCEPT localhost
     REJECT all
     On newer versions of NUT (e.g. the version that comes with Mythbuntu 9.04),
     copy the upsd.conf.sample file and replace the LISTEN directives with:
     LISTEN 127.0.0.1
     LISTEN 192.168.1.123 3493
     You should use the actual IP address of the machine where NUT is being
     installed in place of 192.168.1.123 (above).  If the machine has two or more
     NICs and you want NUT to listen on all of them, add additional LISTEN
     directives for the IP address of each of them.
     Note that, if you have an older config file and are upgrading to a newer
     version of NUT, you will need to remove all of the ACL, ACCEPT and REJECT
     rules and simply use LISTEN.  Apparently, the designers have decided that NUT
     should get out of the security business and leave everything to the firewall.
     Consequently, the rules are no longer accepted and LISTEN is simply used to
     tell NUT which port to listen on.

/etc/nut/upsd.users:

     Copy the file upsd.users.sample. Add a user that will allow upsmon on the
     local host to shut down the machine if the power goes south as well as do
     periodic battery tests:
     [lmmonitor]
         password = ItsASecret
         allowfrom = localhost
         instcmds = test.battery.start
         actions = set
         upsmon master

/etc/nut/upsmon.conf:

     Copy the file upsmon.conf.sample. Change the group ownership to the nut user
     and give it group permissions:
     chgrp ups /etc/nut/upsmon.conf
     chmod g+rw /etc/nut/upsmon.conf
     Make the following changes to the file to begin monitoring the UPS:
     NOTIFYCMD /etc/nut/notify
     RUN_AS_USER nut
     MONITOR fusion-reactor@localhost 1 lmmonitor ItsASecret master
     NOTIFYFLAG COMMBAD  SYSLOG+EXEC
     NOTIFYFLAG COMMOK   SYSLOG+EXEC
     NOTIFYFLAG FSD      SYSLOG+EXEC
     NOTIFYFLAG LOWBATT  SYSLOG+EXEC
     NOTIFYFLAG NOCOMM   SYSLOG+EXEC
     NOTIFYFLAG ONBATT   SYSLOG+WALL+EXEC
     NOTIFYFLAG ONLINE   SYSLOG+WALL+EXEC
     NOTIFYFLAG REPLBATT SYSLOG+EXEC
     NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC
     NOTIFYFLAG OVERTEMP SYSLOG+EXEC
     If you want to monitor UPS temperature and you've applied the proper hacks
     (or the temperature hacks are included in your version of the source), add
     the following:
     # --------------------------------------------------------------------------
     # UPSOVERTEMP - Temperature (in Celcius) which is too high for operation
     #
     # upsmon will check all UPS that return temperature information against
     # this value.  If the UPS temperature exceeds this value, an OVERTEMP
     # notification will be generated.
     #
     # Note that certain UPS are renown for cooking and even burning up
     # batteries (some reports of spectacular battery fires have been received).
     # From actual observed log data, it appears that prior to burning up the
     # batteries, the UPS internal temperature rises significantly.  Hence,
     # monitoring the UPS temperature can be a valuable tool towards detecting
     # battery cooking, before the UPS burns the place down (the UPS is supposed
     # to solve problems, not cause them, isn't it).
     #
     # Once again, typical observed internal temperatures are in the 40 to 50
     # degree Celcius range.  Observed temperatures of 80 degrees Celcius prior
     # to an actual battery failure are indicative of pending failure.  Thus, to
     # be safe, the the UPSOVERTEMP value should be set in the 60-70 degree
     # range.
     UPSOVERTEMP 60.0

/etc/nut/notify:

     Create the following script to send event notifications to root, via email,
     whenever the UPS has something important to say.  Note that the indentation
     in front of "ENDMSG" can be tabs only.  If your lame-ass text editor sticks
     spaces in there, the shell script will get a syntax error.  Set the
     UPS_BOXES variable to your list of UPS boxes.  Here is the script:
     #!/bin/sh
     # A shell script that can be used by the UPS power monitor to send messages
     # to root when power failures occur.
     #
     # If you would like to log all of the UPS events that take place in the log
     # file too, define the location of the log file.  Otherwise, if the
     # LOG_PATH is set to an empty string, no log entries are written.
     # Define the log path and the boxes we're logging.
     LOG_PATH="/var/log/upslog"
     UPS_BOXES="fusion-reactor bevatron"
     # Write the event to the log, if there is one.
     if [ x"$LOG_PATH" != x ]; then
         timestamp=`date "+%Y/%m/%d %H:%M:%S"`
         for LogBox in $UPS_BOXES; do
             echo $timestamp EVENT: $1 >> ${LOG_PATH}.$LogBox
         done
     fi
     # Some events we only log.
     if ([ x"$NOTIFYTYPE" != xONBATT ]) && ([ x"$NOTIFYTYPE" != xONLINE ]) \
         && ([ x"$NOTIFYTYPE" != xREPLBATT ]) \
         && ([ x"$NOTIFYTYPE" != xSHUTDOWN ]) \
         && ([ x"$NOTIFYTYPE" != xOVERTEMP ]); then
         exit 0
     fi
     # Email the message to root so that they can see everything that's going
     # on.  After all, if you're omnipotent, you need to know everything.
     HostName=`hostname`
     if [ x"$NOTIFYTYPE" != xSHUTDOWN ]; then
         /usr/bin/mail -s "Message from the UPS" root <<-ENDMSG
             The power monitor on $HostName has generated the following message:
             $1
             ENDMSG
     else
         /usr/bin/mail -s "Urgent message from the UPS" root <<-ENDMSG
             The power monitor on $HostName has generated the following message:
             $1
             ENDMSG
     fi
     Note that, in the above script, the two sets of lines between
     "/usr/bin/mail -s ... <<-ENDMSG" and up to and including the line with
     "ENDMSG" must either not be indented at all or only indented with actual tab
     characters (not blanks).  If they are not, the script will fail.
     Also, don't forget to add execute permissions to the script after you create
     it:
     su
     chmod ugo+x /etc/nut/notify
     Then, it wouldn't hurt try it out after you've got it all set up.  For
     example:
     UPSNAME=bevatron; export UPSNAME
     NOTIFYTYPE=ONLINE; export NOTIFYTYPE
     /etc/nut/notify "This is a test"
     Check that root receives the message and that the message gets logged to
     bevatron's log file.

/etc/nut/hosts.conf:

     Copy the file hosts.conf.sample.  Add all of the machines that you want to be
     able to monitor from the Web.  Also add the name of the logfile, if logged
     events will be displayed:
     MONITOR fusion-reactor@localhost "pri-host UPS"
     LOGFILE /var/log/upslog.fusion-reactor

/etc/nut/ftplogs:

     If you'd like to build a consolidated graph of all your UPS activity and have
     a centralized server where logfiles can be copied for this purpose, you
     should create the file /etc/nut/ftplogs:
     #! /bin/sh
     #
     # ftplogs - Script to ftp the UPS logs to the primary server at regular
     #           intervals.
     #
     # This script is used both by cron, to send the current UPS logs to the
     # primary server, every 15 minutes, and by logrotate, to send the freshly
     # rotated UPS logs to the primary server whenever UPS logs are rotated.
     #
     #
     # Define the log path and the boxes we're logging.
     #
     PRI_SERVER="pri-host"                   # Primary server name
     LOG_PATH="/var/log/upslog"              # Local log path
     PRI_LOG_PATH="/var/log/upslog"          # Log path on primary server
     UPS_BOXES="bevatron"
     #
     # If we were passed a logfile name, send it to the primary server directly.
     #
     if test x"$1" != x; then
         echo -e "user nut ItsASecret\\nput ${LOG_PATH}.$1 ${PRI_LOG_PATH}.$1" \
             | ftp -n $PRI_SERVER
     #
     # For all of the UPS on this system, send the logs to the primary.
     #
     else
        for LogBox in $UPS_BOXES; do
            echo -e "user nut ItsASecret\\nput ${LOG_PATH}.$LogBox \
                ${PRI_LOG_PATH}.$LogBox" | ftp -n $PRI_SERVER
        done

fi

     Note that on some machines /bin/sh is an alias for /bin/dash and that dash,
     apparently, doesn't have to follow the rules too closely for shells.  So, you
     may find that dash is broken when it comes to echo and "echo -e" doesn't
     work.  If this is the case (First of all, why do we need another half dozen
     shells, anyway?  Isn't two or three already way too many?  And, who the f**k
     gives a rat's butt about POSIX compatibility?  What I giva a f**k about is
     "working", especially old scripts, that used to work fine, "still working".
     So, nice going a**holes.), you'll probably be a lot happier with /bin/bash
     instead of /bin/sh.
     You should pick a user that is valid on the server, use the right password
     for that user and set the server name to the correct name for the central
     server (make sure this server name appears in either /etc/hosts on the local
     Mythbuntu machine or can be resolved through DNS).  Add the script to your
     cron table so that it runs at regular intervals (e.g. every 15 minutes), as
     shown below.
     Also, on that server, you should create a couple of empty log files with the
     correct permissions so that FTP can overwrite them without getting permission
     denied:
     su
     touch /var/log/upslog.bevatron /var/log/upslog.bevatron.1
     chown root:ups /var/log/upslog.bevatron
     chmod g+w /var/log/upslog.bevatron

/etc/logrotate.d/nut:

     Add the new UPS' logfile to the logrotate config file:
     /var/log/upslog.bevatron {
         notifempty
         missingok
         create 0664 root ups
         copytruncate
         postrotate
             echo HEADER: Bevatron >/var/log/upslog.bevatron
             /etc/nut/ftplogs bevatron.1
         endscript
     }

/etc/crontab:

     If you want the UPS batteries to be tested at regular intervals, you can add
     a line to crontab to do that.  Every couple of months is a good interval.
     If you care, schedule the times for the battery test on days when the other
     UPS are not also testing their batteries (you don't want all the machines
     down at once, do you).
     You should also add a line to schedule the push of the logs to a central
     server, if you want to use that feature.
     # Push the UPS logs over to the primary host every 15 minutes.
     05,20,35,50 * * * * root /etc/nut/ftplogs
     # Every two months, have the UPS check its battery.
     00 6 15 1,3,5,7,9,11 * root /bin/upscmd -u lmmonitor -p ItsASecret \
                                 fusion-reactor@localhost test.battery.start
     Note that most UPS will usually come with automatic self-test turned on and
     set to every 14 days.  This means that the UPS will run its battery test
     itself every 14 days, exactly 1209600 seconds after it is turned on.  How
     convenient is that?  If you'd rather the test was done when you decide, in
     your crontab, you should turn off this dubious feature like so:
     /bin/upsrw -s ups.test.interval=0 -u lmmonitor -p ItsASecret \
                fusion-reactor@localhost

/etc/init.d/ups-monitor:

Note that later versions of NUT name the script in init.d "nut" instead of "ups-monitor". Then, they point a symlink of "ups-monitor" at "nut". If you have one of these versions, you should update the "nut" script instead of "ups-monitor".

The installed ups-monitor script does not start logging. If you'd like to use logging, you can add the following:

     upslog_pid=${pid_dir}/upslog.pid
     upslog=/bin/upslog
          .
          .
          .
     start_stop_log () {
       case "$START_UPSLOG" in
         y|Y|yes|YES|Yes)
           case "$1" in
             start)
               timestamp=`date "+%Y/%m/%d %H:%M:%S"`
              for UPSBox in $UPSLOG_BOXES; do
                echo $timestamp EVENT: Starting UPS logging \
                    >> ${UPSLOG_PATH}.$UPSBox
                chgrp $UPSLOG_GROUP ${UPSLOG_PATH}.$UPSBox
                chmod g=rw ${UPSLOG_PATH}.$UPSBox
                $upslog ${UPSBox}@localhost ${UPSLOG_PATH}.$UPSBox \
                  $UPSLOG_INTERVAL \
                  "%TIME @Y/@m/@d @H:@M:@S% %VAR input.voltage% \
                      %VAR output.voltage% %VAR input.frequency% \
                      %VAR battery.charge% %VAR ups.load% [%VAR ups.status%] \
                      %VAR ups.temperature%" \
                  >/dev/null 2>&1
                startval=$?
                if [ $startval = 0 ] ; then
                  touch ${upslog_pid}.$UPSBox
                else
                  return $startval
                fi
              done
              ;;
            stop)
              timestamp=`date "+%Y/%m/%d %H:%M:%S"`
              for UPSBox in $UPSLOG_BOXES; do
                if [ -f /var/lock/subsys/upslog.$UPSBox ]; then
                  LogPID=`ps -eo pid,args | grep upslog | grep $UPSBox \
                      | sed -n 's/^ \([0-9]\).*/\1/p'`
                  if [ x"$LogPID" != x ]; then
                    kill -9 $LogPID
                    stopval=$?
                    echo $timestamp EVENT: Stopping UPS logging \
                        >> ${UPSLOG_PATH}.$UPSBox
                    [ $stopval = 0 ] && rm -f /var/lock/subsys/upslog.$UPSBox
                  fi
                fi
              done
              ;;
          esac
          ;;
        n|N|no|NO|No|*)
          return 1
          ;;
      esac
    }
         .
         .
         .
     case "$1" in
      start)
        log_daemon_msg "Starting $DESC"
        check_var_directory
        start_stop_server start && log_progress_msg "upsd"
        start_stop_client start && log_progress_msg "upsmon"
        start_stop_log start && log_progress_msg "upslog"
        log_end_msg 0
        ;;
      stop)
        log_daemon_msg "Stopping $DESC"
        start_stop_log stop && log_progress_msg "upslog"
        start_stop_client stop && log_progress_msg "upsmon"
        start_stop_server stop && log_progress_msg "upsd"
        log_end_msg 0
        ;;

Once you've made any changes to ups-monitor for logging, if it wasn't already installed by apt-get, install it using the dain-bramaged update-rc.d script. The following should work:

     update-rc.d nut defaults

or maybe:

     update-rc.d ups-monitor defaults

/etc/nut/nut.conf:

     In a never-ending attempt to justify the five or six config files needed by
     this package, they've added another config file (Yeah!) only this time its
     used by the startup script in init.d to tell it which other config files to
     use.  Consequently, if this file is present and is needed by the startup
     script (either nut or ups-monitor, in init.d), you should edit to get NUT
     working because the default value in it disables NUT, out of the box.
     Change MODE to either "netserver" or "standalone" (they both work the same)
     like this:
     MODE=netserver

/etc/default/nut:

     You will have to hack the default settings so that upsd and upsmon are
     started:
     START_UPSD=yes
     START_UPSMON=yes
     If you want to use the logging features added to ups-monitor (above), add
     these lines:
     # start upslog
     START_UPSLOG=yes
     # set upslog specific options. use "man upslog" for more info
     UPSLOG_OPTIONS=""
     # a list of UPS to log, separated by a space
     UPSLOG_BOXES="Bevatron"
     # logging directory (including filename prefix)
     UPSLOG_PATH="/var/log/upslog"
     # the log interval (in seconds)
     UPSLOG_INTERVAL=30
     # group to use for log files
     UPSLOG_GROUP=nut

Increasing Storage Capacity

If you chose the XFS file system for any of your video storage volumes (a wise choice) and you wish to expand these volumes to a bigger disk (e.g. you wish to replace a 640GB disk with a 1TB disk), you should follow the steps outlined immediately below. On the other hand, if you chose the ext3 file system for any of your video storage volumes (you had your reasons, I'm sure), you should follow the steps shown at the end of this section. And, if the system files and video storage directory are all on one disk (single disk system), expanding such a system's disk is covered in the next section.

Note that the duration of the copy operation that is used to expand a volume depends on the amount of data on it (duh) so you may wish to clean up all of the old stuff that you were thinking of deleting, before you proceed. On the other hand, if you could do that, you probably wouldn't need bigger disks in the first place....

Begin by getting yourself a copy of KNOPPIX (the CD works perfectly fine):

     http://knopper.net/knoppix/index-en.html

And burning the ISO image onto a CD (or DVD, if you took that route).

Next, configure the machine who's disk is to be expanded with the old disk and new disk attached and a CD/DVD drive added, if necessary. In this example, we're presuming the original drive is on SATA0 and the new drive is on SATA1, which will map to /dev/sda and /dev/sdb respectively, when KNOPPIX is booted.

Put the KNOPPIX CD into the CD/DVD drive and boot it. Once KNOPPIX comes up (you're booting from a CD, remember, so be patient), open up a console window and become super user. To do this, simply type the "su" command. There's no password (how refreshing).

Before proceeding, you should check that the original and new drives are installed where you expect them to be. You can check this with:

     /sbin/fdisk -lu /dev/sda
     /sbin/fdisk -lu /dev/sdb

The first drive should show a valid partition table with one Linux partition, type 83 (also note the drive's size to ensure that it is correct), and the second drive should show nothing. Since, we're going to be wiping out all data on the new drive in a minute, it pays to make sure you've got the right target in your sights.

You should now format the new drive using fdisk:

     su
     /sbin/fdisk /dev/sdb
       n                         (To create a new partition)
       p                         (As a primary partition)
       1                         (Partition 1)
       <cr>                      (To accept the first cylinder as the start)
       <cr>                      (To accept the last cylinder as the end)
       w                         (Write the partition table to the disk)

You can check your work with:

     /sbin/fdisk -lu /dev/sdb

You should see something like this:

     Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
     255 heads, 63 sectors/track, 121601 cylinders
     Units = cylinders of 16065 * 512 = 8225280 bytes
     Device Boot      Start         End      Blocks   Id  System
  /dev/sdb1               1      121601   976760001   83  Linux

If you have one of the advanced format hard drives (e.g. the new 1.5 or 2 TB drives from Western Digital or Samsung), you need to pay particular attention to how you create the partitions on the drive so that they are always aligned on a 4K boundary. If you don't do this, performance will suffer heavily.

Since we are only creating a single partition, fdisk defaults to creating the partition starting at sector 63 (it keeps the first 63 sectors, from 0-62, for the partiton table and boot information). In the case of advanced format hard drives, this is a very unfortunate choice. To override this default choice, partition the disk as follows:

     su
     /sbin/fdisk /dev/sdc
       u                         (All sizes are given in sectors, not cylinders.
                                   This may be the default on your version of
                                   fdisk, in which case you'll have to re-enter
                                   the 'u' command, since you just switched the
                                   mode to cylinder [its a toggle])
       n                         (To create a new partition)
       p                         (As a primary partition)
       1                         (Partition 1)
       64                        (Start the partition on a 4K boundary [i.e. 0
                                   mod 8].  Bonus point.  Newer versions of
                                   fdisk will force the partition to start at
                                   2048 which is acceptable too)
       <cr>                      (To accept the last sector as the end)
       w                         (Write the partition table to the disk)

You can check your work with:

     /sbin/fdisk -lu /dev/sdb

You should see something like this:

     Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
     255 heads, 63 sectors/track, 243201 cylinders, total 3907029168
     Units = sectors of 1 * 512 = 512 bytes
     Device Boot      Start         End      Blocks   Id  System
  /dev/sdb1              64  3907029167  1953514552   83  Linux

or maybe something like this:

     Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
     81 heads, 63 sectors/track, 765633 cylinders, total 3907029168 sectors
     Units = sectors of 1 * 512 = 512 bytes
     Sector size (logical/physical): 512 bytes / 4096 bytes
     I/O size (minimum/optimal): 4096 bytes / 4096 bytes
     Disk identifier: 0x83a7c849
     Device Boot      Start         End      Blocks   Id  System
  /dev/sdb1            2048  3907029167  1953513560   83  Linux

If the original drive contains ext2/ext3 file system, you should proceed to copy its data as outlined farther along in this section. Otherwise, verify that it does indeed contain an XFS file system with this command:

     df -T /dev/sda1

If the file system type is shown as "xfs", the data on it should now be copied to the new drive, as shown:

     xfs_copy -d /dev/sda1 /dev/sdb1

Note that, if you have one of the advanced format hard drives (e.g. the new 1.5 or 2 TB drives from Western Digital or Samsung), you should first check that the block size of the original XFS file system is a multiple of 4096. Usually, it will be because XFS chooses the page size of the OS as the block size and, under Linux, this is 4096. To check, you can dump the XFS superblock like this:

     xfs_db -c "sb 0" -c print -r /dev/sdb1

If the block size is not a multiple of 4096, there does not appear to be any way to alter it while doing xfs_copy so the only option appears to be to start from scratch with a brand new XFS file system on the target volume and copy the files with a regular copy command such as "cp" or "lftp mirror".

The copy will take quite a while, depending on the size of the original partition and how full it is (if you were smart and deleted all of the junk shows off the original partition, it will be faster). Once the copy completes, the new disk will contain a copy of the original disk and the new XFS file system will be same size as the original (bummer).

The next step requires that you mount the new file system. KNOPPIX thoughtfully provides predefined mount points in the "/media" directory for each of the attached devices that it finds. So, do:

     mount /dev/sdb1 /media/sdb1

You can check that the mounted file system looks like the original with:

     ls -l /media/sdb1

If you're happy with the new file system, you can increase its size to fill the entire partition (nice) with:

     xfs_growfs /media/sdb1

Once that's done, unmount the new file system:

     umount /media/sdb1

Shut down KNOPPIX and recable the new disk to replace the original. Boot the machine with the new disk installed and see how it works.

For ext3 file systems, you can use whatever copy method you usually use to copy a smaller disk to a larger disk. The brute force method would be to use KNOPPIX, as is described above, but when you come to the part about using xfs_copy, do the following instead. Make the file system that you wish to appear in the partition with mkfs or, to be more precise, mkfs.ext3:

     /sbin/mkfs.ext3 -j -L / -T news /dev/sdb1

If you have one of the advanced format hard drives (e.g. the new 1.5 or 2 TB drives from Western Digital or Samsung), it is extremely important that the block size chosen for the file system is a multiple of 4096. If not, there will be a severe performance hit. Thus, for mkfs.ext3, use:

     /sbin/mkfs.ext3 -b 4096 -j -L / -T news /dev/sdb1

Note that, in this example, we labeled the file system "/". You may wish to use some other label, chosen to match what's on the original drive. Be especially careful about this if your system boots with the "LABEL=" parameter in the GRUB configuration and/or mounts partitions using the "LABEL=" parameter in /etc/fstab.

The next step requires that you mount the old and new file systems. KNOPPIX thoughtfully provides predefined mount points in the "/media" directory for each of the attached devices that it finds. So, do:

     mount /dev/sda1 /media/sda1
     mount /dev/sdb1 /media/sdb1

Now, copy the original drive to the new drive:

     cp --preserve=all -R /media/sda1/* /media/sdb1

Since the file system will only hold static data, there's no real reason to have fsck check it at boot time. This is especially relevant because for the large file systems that are found on 1 or 2TB disks, checking the file system could take a very, very long time (i.e. hours and hours). If you have several large disks on your video server and all of the file systems happen to get coincidentally checked, booting your system could easily take half a day. You will most certainly want to turn off this dubious feature with:

     /sbin/tune2fs -c 0 -i 0 /dev/sdb1

Once that's done, unmount the old and new file systems:

     umount /media/sda1
     umount /media/sdb1

Shut down KNOPPIX and recable the new disk to replace the original. Boot the machine with the new disk installed and see how it works.

Since copying file systems with cp, as shown above, can be pretty slow, you may opt to copy your ext3 file system using a smart copy program like Acronis. Many of these programs know how to analyze the file system directory structure and copy the files much more quickly than cp does. A significant improvement in copy time can result.

There's only one wrinkle, though. They may not know how to set up all of the flags in the file system directory properly. So, although all of the data is copied properly, your file system will fail to pass fsck's checks when you try to boot with the new disk (this is presuming that fsck is even run against the new file system). If this happens, you can usually heal the new file system with:

     fsck /dev/sda1 -- -a

You may be doing this in single user mode, if the system fails to boot properly because the failing file system cannot be mounted.

An alternative to connecting the new disk to your running system and copying the files directly works well for expanding data-only drives. In this case, one may not wish to shut down a production system the whole time that the new drive is being set up. Instead, one can mount the new drive on a separate test or work system and copy the files using a network file copy program such as rsync or lftp.

Cable the new drive up to the test/work system and proceed with building the new partition table as described above. If you are creating an Ext2/Ext3 partition, you can format and label it as noted above. However, if the drive is a data-only drive, you'll probably be setting it up as an XFS drive. In this case, you'll need to establish the file system directly instead of depending on copy to do so for you.

The XFS format command looks like this:

     su
     /sbin/mkfs.xfs -b size=4096 -L / /dev/sdb1

For an advanced format drive that uses 4096 byte physical sectors, you'll probably want to use something like this command:

     su
     /sbin/mkfs.xfs -b size=4096 -s size=4096 -L / /dev/sdb1

If there isn't already a mount point that you can use for the new file system on your test/work system, you should create one something like this:

     su
     mkdir /mnt/sdb1mr

Then, you can mount the new file system and change to the root directory:

     su
     mount /dev/sdb1 /mnt/sdb1mr
     cd /mnt/sdb1mr

We like to use lftp to mirror the data-only partition from the production system to the new data-only file system on the test/work system. This might go something like this:

     su
     lftp -ujoeblow el-producto
     <super-secret-pw>
     mirror /mnt/sdb1 /mnt/sdb1mr

The mirror will run for a while (depending on how many gig o'bytes are to be copied). Once it is done, you can swap the new drive into the production system during a lull in the action.

There is the possibility that a file or two on the original data-only partition won't get mirrored because it is locked or otherwise being used by the production system, when the mirror is done. It ain't the end of the world. Once the new data-only drive is in production, you can just mount up the old drive on the test/work system and reverse mirror any missing files. From the el-producto system, do:

     su
     lftp -ujoeblow test-oh-mundo
     <super-secret-pw>
     mirror --only-missing /mnt/sdb1mr /mnt/sdb1

If necessary, you can set the permissions on the new file system and its contents more or less as follows (take a look at the original data-only file system for anything special but this should work):

     su
     chown -R mythtv:mythtv /mnt/sdb1
     chmod u=rwx,g=rwxs,o=rx /mnt/sdb1
     chmod ug=rw,o=r /mnt/sdb1/*
     chmod u=rwx,g=rwxs,o=rx /mnt/sdb1/music        (if applicable)
     chmod u=rwx,g=rwxs,o=rx /mnt/sdb1/recordings          ''
     chmod u=rwx,g=rwxs,o=rx /mnt/sdb1/videos              ''

It might also be a good idea to run the "cleanup" script, which can be found in the "Freeing Up Storage" section, to perform an orphan check for any files that got deleted by Myth after you mirrored the storage directory but before the system was shut down and restarted with the new data-only file system installed. This script should be run something like this:

     .../scripts/cleanup /mnt/sdb1 0 localhost root its-a-secret >cleanup.lst

Look in the cleanup.lst file for any files marked "Orphaned" and manually delete them.

Your migration to the new data-only storage disk should be complete.

Increasing the Capacity of a Single Disk System

A single disk system usually has two or more partitions on its only disk (at the very least, a swap partition and a system partition). Expanding the storage capacity of the video storage partition (or the system partition, if the videos are stored along with the system files on the system partition) is basically like expanding a single partition volume except that there are a couple of extra steps before you get started, and you must do the appropriate type of copy for each partition, not just a single partition.

The extra steps are necessitated by the fact that the single disk system must have a bootable disk and the system also needs some swap space on the disk.

To illustrate the complete steps necessary to expand a single disk system, let's take the example of a system that has three partitions, one for /boot, one for swap space, and one for root. Furthermore, let's assume that the /boot partition is formatted using ext3 and the root partition is formatted using XFS.

As we note in the previous section, the duration of the copy operation that is used to expand a volume depends on the amount of data on it (duh) so you may wish to clean up all of the old stuff that you were thinking of deleting, before you proceed. On the other hand, if you could do that, you probably wouldn't need a bigger disk in the first place....

Again, we begin by getting ourselves a copy of KNOPPIX (the CD works just swell):

     http://knopper.net/knoppix/index-en.html

And burning the ISO image onto a CD (or DVD, if you took that route).

Next, configure the single disk machine who's disk is to be expanded with the old disk and new disk attached and a CD/DVD drive added, if necessary. In this example, we're presuming the original drive is on SATA0 and the new drive is on SATA1, which will map to /dev/sda and /dev/sdb respectively, when KNOPPIX is booted.

Put the KNOPPIX CD into the CD/DVD drive and boot it. Once KNOPPIX comes up (you're booting from a CD, remember, so be patient), open up a console window and become super user. To do this, simply type the "su" command. There's no password (how refreshing).

Before proceeding, you should check that the original and new drives are installed where you expect them to be. You can do this by typing:

     /sbin/fdisk -lu /dev/sda
     /sbin/fdisk -lu /dev/sdb

The first drive should show a valid partition table that looks something like this:

     Disk /dev/sda: 640.1 GB, 640135028736 bytes
     255 heads, 63 sectors/track, 77825 cylinders, total 1250263728 sectors
     Units = sectors of 1 * 512 = 512 bytes
     Disk identifier: 0x63c6c105
     Device Boot      Start         End      Blocks   Id  System
  /dev/sda1   *          63      996029      497983+  83  Linux
  /dev/sda2          996030     4996214     2000092+  82  Linux swap / Solaris
  /dev/sda3         4996215  1250263728   622633756   83  Linux

Be sure that the original drive's size and partition information is correct to ensure that it is mounted where you think it is. Also verify that the new drive has nothing on it (or has the expected layout, if you're reusing it). Since, we're going to be wiping out all data on the new drive in a minute, it pays to make sure you've got the right target in your sights.

You can also check the various partitions to see what type of file systems are on each of them. In our example, we'd do:

     df -T /dev/sda1
     df -T /dev/sda3

We're expecting to see an ext3 file system on /dev/sda1 and an XFS file system on /dev/sda3.

If everything looks good, you can avoid all the trouble of setting up the boot sector with the boot loader by just copying the first few tracks of the source disk directly with dd:

     dd bs=512 count=63 if=/dev/hdc of=/dev/hdb

This will also copy the partition table which probably won't be correct. However, since we are expanding the disk size, usually the only required change to the copied partition table is that the last partition be expanded to fit the new disk. This can be done by deleting the last partition and adding a new partition that uses all of the available space:

     su
     /sbin/fdisk /dev/sdb
       d                         (Delete a partition)
       3                         (Partition 3)
       n                         (To create a new partition)
       p                         (As a primary partition)
       3                         (Partition 3)
       <cr>                      (Accept previous end cylinder + 1 as the start)
       <cr>                      (To accept the last cylinder as the end)
       w                         (Write the partition table to the disk)

Be sure that the appropriate partition is marked as the boot partition, if it hasn't already been marked that way.

Alternately, if you want or need to create the partition table from scratch, you should do so using fdisk like this:

     su
     /sbin/fdisk /dev/sdb
       n                         (To create a new partition)
       p                         (As a primary partition)
       1                         (Partition 1)
       <cr>                      (To accept the first cylinder as the start)
       62                        (To set cylinder 62 as the end)
       n                         (To create a new partition)
       p                         (As a primary partition)
       2                         (Partition 2)
       <cr>                      (Accept previous end cylinder + 1 as the start)
       311                       (To set cylinder 311 as the end)
       n                         (To create a new partition)
       p                         (As a primary partition)
       3                         (Partition 3)
       <cr>                      (Accept previous end cylinder + 1 as the start)
       <cr>                      (To accept the last cylinder as the end)
       t                         (To set the partition type)
       2                         (Partition 2)
       82                        (Partition type 82, swap space)
       w                         (Write the partition table to the disk)

On most modern disks, this creates a new partition layout that has approximately 500MB for the boot partition, 2GB for swap space, and the remaining disk space for the root partition. This layout has proven to work well during years of constant use.

Unfortunately, for the advanced format hard drives (e.g. the new 1.5 or 2 TB drives from Western Digital or Samsung), one can no longer continue in the same old manner, as described above. If the partitions on the drive are not laid out properly and/or the file systems not constructed carefully, you will suffer from huge performance problems. This all but mandates that you lay the partitions out by hand, set the boot loader up manually, set the file systems up ahead of time, and copy all of the files manually. No use of dd or another copy program to speed up the process.

Of course, once the disk is set up for advanced format use, the next time you do an upgrade (e.g. from the 2TB to 4TB disk), you can revert to the good old techniques but, in the meantime, begin by creating the partition table as follows:

     su
     /sbin/fdisk /dev/sdb
       u                         (All sizes are given in sectors, not cylinders)
       n                         (To create a new partition)
       p                         (As a primary partition)
       1                         (Partition 1)
       64                        (Start the partition on a 4K boundary [i.e. 0
                                   mod 8])
       1028159                   (To set block 1028159 as the end)
       n                         (To create a new partition)
       p                         (As a primary partition)
       2                         (Partition 2)
       1028160                   (To set block 1028160 as the start)
       5140799                   (To set block 5140799 as the end)
       n                         (To create a new partition)
       p                         (As a primary partition)
       3                         (Partition 3)
       5140800                   (To set block 5140800 as the start)
       <cr>                      (To accept the last cylinder as the end)
       t                         (To set the partition type)
       2                         (Partition 2)
       82                        (Partition type 82, swap space)
       w                         (Write the partition table to the disk)

As above, when creating the partitions using cylinders, this creates a new partition layout that has approximately 500MB for the boot partition, 2GB for swap space, and the remaining disk space for the root partition. Just by way of example, if you were interested in upping the swap space to 4GB from 2GB, you might use 9253439/9253440 instead of 5140799/5140800.

After you've created the new partitions, you can check your work with:

     /sbin/fdisk -lu /dev/sdb

You should see something like this:

     Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
     255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
     Units = sectors of 1 * 512 = 512 bytes
     Disk identifier: 0x0002c738
     Device Boot      Start         End      Blocks   Id  System
  /dev/sdb1   *          63      996029      497983+  83  Linux
  /dev/sdb2          996030     4996214     2000092+  82  Linux swap / Solaris
  /dev/sdb3         4996215  1953520064   974261925   83  Linux

If you laid out the partition table using sector numbers instead of cylinders, and you used numbers other than the ones given, you'll probably see some whining from fdisk about the partitions not starting on a cylinder boundary. Since all of the cylinder/sector numbers have been fake for many years and all sector addressing is done using LBAs, it doesn't much matter where the partitions start/end, as long as they all start on a sector whose address is 0 mod 8.

We have carefully chosen all of the partitions to end on a boundary that is a multiple of the magic number 128520, minus 1. This number of sectors gives a chunk that is 64MB in size. It is the lowest number that is 0 mod 8 and also 0 mod 16065 (16065 is the result of multiplying 255 x 63, which are the numbers used for the number of heads and sectors on all LBA-addressed disks). Using a multiple of 128520, minus 1, for all of your partition calculations, will ensure that they all end on a virtual cylinder boundary and fdisk will be happy.

Once all of the partitions have been created, you must install the boot loader (Mythbuntu uses GRUB) on the disk. As above, you can avoid the trouble of setting up the boot sector with the boot loader by just copying the first few tracks of the source disk directly with dd. However, since we've already set up the partition table, we must do the copy very carefully to avoid wiping it out:

     dd bs=446 count=1 if=/dev/hda of=/dev/hdb
     dd bs=2 skip=255 seek=255 count=1 if=/dev/hda of=/dev/hdb
     dd bs=512 skip=1 seek=1 count=62 if=/dev/hda of=/dev/hdb

This copies the first 446 bytes of the first sector (a.k.a. the MBR), which contains the boot loader code. It skips over the next 64 bytes, which contain the partition table. Then, it copies the two-byte magic cookie that defines it as the MBR. Finally, it copies the next 62 sectors (a.k.a. the DOS Compat Space), which contain the GRUB 1.5 code. Once that is done, you should have a bootable disk that is partitioned the way you want it.

You might want to test that the system can boot the disk (admittedly, it won't get far but you should at least see GRUB Stage 1.5 running), before you proceed any further, because now is the time to redo the partition table and go with Plan B, if it didn't work, before you copy any data to the new disk.

Plan B is used if dd wiped out the partition table or GRUB wouldn't boot into Stage 1.5. Plan B consists of installing GRUB from scratch, which is best done using the original OS installation disk, in rescue mode. To use Plan B, you must first copy the files to the /boot partition, as outlined below.

All of the ext2/ext3 file systems, that must appear in each of the partitions, should be made with mkfs. Similarly, swap space must be initialized with mkswap. However, the XFS file systems need not be created ahead of time as the copy operation will take care of that for us. Here's an example of how we'd set up one ext2 or ext3 file system and one swap space, first, using mkfs.ext2:

     mkfs.ext2 -L /boot -T news /dev/sdb1
     mkswap -v1 /dev/sdb2

or mkfs.ext3:

     mkfs.ext3 -j -L /boot -T news /dev/sdb1
     mkswap -v1 /dev/sdb2

Once you've done this, copy any files needed for the OS boot sequence to the boot partition. KNOPPIX thoughtfully provides predefined mount points in the "/media" directory for each of the attached devices that it finds (and even adds mount points for any new partitions created using fdisk) so you can do:

     mount -r /dev/sda1 /media/sda1
     mount /dev/sdb1 /media/sdb1
     cp -R --preserve=all /media/sda1/* /media/sdb1
     umount /media/sda1
     umount /media/sdb1

Now is the time, if you are going with GRUB Plan B, to set up the boot loader (as noted above, if you set up the boot sector using one of the dd methods, you can omit this step). There are so many ways of doing this that it is beyond the scope of these notes. Hopefully, you won't have to do it this way but, if you do, there are plenty of notes on the Internet that give the details. Find them and read them first. Just to make sure that you do it correctly, the basic steps should look something like this:

  1. Boot with your system's Installation CD and get into rescue mode.
  2. If you are asked if you want to look for an existing Linux installation, you can skip this step. This will get you to the console prompt a lot quicker.
  3. Once the console prompt appears, type "grub".
  4. Set GRUB's root device to the partition containing the boot directory by typing "root (hd1,0)". In our case, this would be /dev/hdb1.
  5. Write GRUB to the hard drive with "setup (hd1)".
  6. Bail out by typing "quit".

Note that you may be able to do all of this with Knoppix and skip the rescue disk, depending on how compatible your system is with the Knoppix version of GRUB.

The data on the original XFS partition should now be copied to the new drive. This is done with:

     xfs_copy -d /dev/sda3 /dev/sdb3

The copy will take quite a while, depending on the size of the original partition and how full it is (if you were smart and deleted all of the junk shows off the original partition, it will be faster). Once the copy completes, the new disk will contain an exact copy of the original disk and the new XFS file system will be same size as the original (bummer).

The next step requires that you mount the new file system, using the mount points that KNOPPIX provides in the "/media" directory:

     mount /dev/sdb3 /media/sdb3

You can check that the mounted file system looks like the original with:

     ls -l /media/sdb3

If you're happy with the new file system, you can increase its size to fill the entire partition (nice) with:

     xfs_growfs /media/sdb3

Once that's done, unmount the new file system:

     umount /media/sdb3

Shut down KNOPPIX and recable the new disk to replace the original. Boot the machine with the new disk installed and see how it works.

Performance and Tuning

If you've chosen XFS for any of your system or storage volumes, fragmentation can be a problem which noticably affects performance. Luckily, there are a couple of relatively easy steps that can be taken.

The first is to see how bad fragmentation is. This is done using the xfs_db command. For example, on a storage volume, you'd do something like this:

     sudo xfs_db -c frag -r /dev/sdb1

On a combinded system/storage volume that is contained in the third partition on your disk, you might try something like this:

     sudo xfs_db -c frag -r /dev/sda3

Its time to defrag the system if the results of the command look like this:

     actual 209967, ideal 1022, fragmentation factor 99.51%

Numbers like 30-100% will probably impact performance.

Begin by making sure xfs_fsr is installed. It is part of the xfsdump package, which can be installed with:

     sudo apt-get install xfsdump

Of course, you can certainly run the xfs_fsr command at any time you like, by hand. However, the easiest way to ensure that fragmentation does not cause problems is to add commands to your crontab to defragment regularly, at off peak times.

If all of the XFS volumes are storage only (i.e. you run the OS from a separate non-XFS volume and only use the XFS volumes to store recordings, etc.), the following lines in crontab will work well:

     # Let's defrag all of the XFS volumes in mtab.  We'll work on 'em for a
     # couple of hours per night, which should keep them in good shape, since
     # there's not THAT much activity, on a daily basis.  Hopefully, there's
     # not too much going on when we do it.
     00 3  * * *  root  /usr/sbin/xfs_fsr -t 7200 >/dev/null 2>&1

The above command will defragment all of the XFS volumes defined in /etc/mtab for two hours each night. If the defragmentation isn't done at the end of the two hours, it will pick up where it left off the next night.

It is important that you do not run xfs_fsr on your root partition (e.g. /dev/sda3 on a system/storage volume) or on the partition that contains your boot files (e.g. /dev/sda1 on the same volume). Instead, for combined system/storage volumes we use a find command to find all of the files in the MythTV directory (i.e. the directory where recordings are stored) and defrag them one at a time.

     # Since we can't defrag all of the XFS volumes because the OS is on one
     # of them, we'll defrag only the MythTV recording files.  Since the OS
     # rarely changes, this should handle the bulk of it.  Hopefully, there's
     # not too much going on when we do it.
     00 3  * * *  root  /usr/bin/find /MythTV -type f \
                        -exec /usr/sbin/xfs_fsr \{\} \; >/dev/null 2>&1

Unfortunately, there is no way to specify a time limit on this method but, after it has been done once, it should complete in a reasonable length of time, certainly less than a couple of hours.

Updates and Upgrading To A Later Release Of Mythbuntu

Generally, you do not want allow automatic updates to be applied to your system. While a good idea for a desktop or laptop system that is talking to the outside world, updates to an appliance-like system can often be bad news. The update process is not smooth enough or considerate enough of the special MythTV environment to proceed without mishap. Quite often, updates will break device drivers used for network cards, the display and the TV encoders. Any of these kinds of problems could prevent your Mythbuntu system from performing its primary role of recording programs and/or viewing them. When you want to watch the latest episode of Gossip Girl but it turns out that the system only recorded dead air because of some ill-conceived update, you won't be happy.

We suggest doing updates under controlled circumstances, all at once. If there is a block of time when the system isn't doing any work (minimum 8 hours), that's the time to schedule minor updates like patches. For major updates like version upgrades, a minimum of 48 hours is more like it. The problem of finding a window when updates can be applied is exacerbated if the system to be updated is the master backend, since any other secondary backends will rely on it for the database. However, it is very important to find a decent-sized window in which to do the work, since you don't need any time pressures when you're trying to straighten out all of the screw-ups caused by the updates.

Meanwhile, if you are doing kernel updates or a complete system upgrade, prior to beginning the process (i.e. before your update window begins), if your system needs any special network interface drivers, pre-build them, following the instructions in the "NIC Drivers" section, above. You can do this step at any time so why not get it out of the way before the time pressure begins. Since updates or upgrades frequently break the network interface, copy the drivers needed, for the new kernel or each of the intermediate Mythbuntu versions used in the upgrade, onto the system disk now so you won't have to put them on a CD later on. You should put them in the directory where your other special system drivers are stored. We use a subdirectory for each version and name them according to the Mythbuntu release that they apply to. For example:

     Ubuntu-8.10
     Ubuntu-9.04
         .
         .
         .

Incidentally, when you upgrade to Mythbuntu 11.10, the display manager is switched from GDM to LightDM. Unfortunately, although a fresh install of Mythbuntu 11.10 works, the upgrade procedure does not. Instead of making the switch to LightDM seamlessly, GDM is left partially installed, LightDM is not installed properly, and your system is left in a state whereby the display manager won't come up on the primary display. In other words, you're screwed.

What does this mean for you? Well it means that you'd better have a working NIC, that is supported by the default NIC drivers, that are included in Ubuntu-11.10. And, you'd better make sure that the network connection is going to come up automatically, all by itself.

The best way to make this happen is to set the network connection to DHCP before you begin the upgrade. And make sure that SSH is installed, configured and turned on so that you can login. And, if you've got some kind of flake-oh NIC on the motherboard, that requires a special build of the NIC device driver, you should go get a "regular" NIC and plug it in. Make sure it all works by itself, when you reboot the machine.

Because, if you don't, you're going to need to figure out how to boot the standalone Knoppix disk and repair the broken config files when you brick your system. Or, you're going to have to work out how to carry out the repairs from the console on the primary display (press <Ctrl-Alt-F2>, or <Ctrl-Alt-F3>, or <Ctrl-Alt-F4>, or F5, or F6, or whatever works). In either case, the actual steps necessary to repair the system are outlined further on but it will be a lot easier if you can login from a remote system via SSH.

The first step, when doing updates or an upgrade, should be to take a copy of the MySQL database. This database contains all of the information about when recordings should be done, what was recorded, etc., etc. If you lose this database, you are really not going to be happy. Use whatever MySQL backup procedure you feel confident with to get a copy of the "mythconverg" database from /var/lib/mysql.

For upgrades, the second step should be to make an exact copy of the Mythbuntu system's hard drive. You should use a drive that is at least as big as the original drive and copy everything over. If you wish, now would be a good time to upgrade the drive's capacity too. The upgrade should be performed on the copy, not the original. This allows you to back off all of the upgrade changes in one easy step, should the upgrade fail. Believe us, we've had to do this several times so skipping this step should not be an option. You'll be sorry if you do.

It is not possible to upgrade a release of Mythbuntu more than one step at a time. So, for example, if your system is 8.04 and you wish to upgrade to 9.04, you must first upgrade to 8.10. Sorry, that's just the way it is. This becomes an especial pain in the butt if you've waited too long to do the upgrade and the online updates are no longer available and/or you've applied special drivers (particularly the NIC driver) to your system. We'll assume that's the case (if you don't anticipate a problem with the NIC driver, you can simply do online upgrades from the Upgrade Manager under the GUI or from the command line with dpkg).

Begin by downloading the "alternate" distribution ISOs for all of the intermediate versions of Mythbuntu between your current version and the version you wish to upgrade to. You can get the distro for the final version too, if the updates for it aren't available online. Burn all of the ISOs to DVDs.

Boot Mythbuntu using the copy of the system disk that you made above. Apply all of the available online updates to your current Mythbuntu version. Once you've done this (and you reboot), your network may stop working. Don't panic.

The upgrade to the next version of Mythbuntu can be done using the "alternate" distro, despite there being no connection to the Internet. Proceed as follows:

     Insert the CD into the CD/DVD drive of the computer to be upgraded.
     A dialog will be displayed offering you the opportunity to upgrade using that
     CD.
     Follow the on-screen instructions.
     If the upgrade dialog is not displayed for any reason, you may also run the
     following command using Alt+F2:
     sudo gksu "sh /cdrom/cdromupgrade"

Note that, if you used pcsk, as described in "Keeping MythBackend Up And Running", to keep the backend up and running, you may experience a hang during the last stages of the upgrade when the install script for Myth Backend tries to start the mythtv-backend service. If this is the case, open up the console window of the install (checkbox at bottom of install window) and press "Ctrl-C". This will bail out of that step and the install will complain that it didn't work. Don't worry, be happy.

You should be able to fix up the pcsk problem by reaiming the symlink at the original mythtv-backend and the rerunning the backend reconfigure script. Try this:

     sudo rm -f /etc/init.d/mythtv-backend
     sudo ln -s /etc/init.d/mythtv-backend.orig /etc/init.d/mythtv-backend
     sudo dpkg-reconfigure mythtv-database
     sudo rm -f /etc/init.d/mythtv-backend
     sudo ln -s /etc/init.d/mythtv-backend.pcsk /etc/init.d/mythtv-backend

If this doesn't work, you should run the Myth Backend configuration (from the System menu) application and check the basic database connection information under the General menu item. Usually, the IP address of the database server will have to be reentered, if any changes are necessary. You probably should use a specific IP address instead of "localhost". The rest of the configuration information is stored in the database and should not need to be updated.

Incidentally, you may want to do a diff against mythtv-backend.pcsk and mythtv-backend.dpkg-new to see if any of the changes that the upgrade wants to make are actually important.

After you've done the upgrade and rebooted, your network may still not be working. The first step in getting it to work may be to rip out the Network Manager (again) as described in "Networking Your Way" (above) and set up the network the way you really want it. Then, apply the proper, pre-built NIC driver, as described in "NIC Drivers" (above) for the release that you are at. This should get the network working again.

As we noted above, when you upgrade to Mythbuntu 11.10, the display manager is switched from GDM to LightDM and, unfortunately, the switch does not work. When you reboot your system after the upgrade, the if the primary display comes up and flashes continuously, here's what we did to fix the problem.

Either login via SSH from a remote terminal or switch to the console on the primary display (press <Ctrl-Alt-F2>, or <Ctrl-Alt-F3>, or <Ctrl-Alt-F4>, or F5, or F6, or whatever works). Then, do the following:

     su
     stop lightdm
     ps x | grep light
     You may have to do a "kill -9" if there are any lightdm processes still
       running.
     apt-get install --reinstall lightdm
     dpkg-reconfigure lightdm
     Choose lightdm as your greeter.
     apt-get remove unity-greeter
     cd /etc/lightdm
     rm -f unit-greeter.conf
     nano lightdm.conf

When the text editor displays the lightdm.conf file, edit it to look like this:

/etc/lightdm/lightdm.conf:

     [SeatDefaults]
     autologin-guest=false
     autologin-user=AUTOLOGINUSER
     autologin-user-timeout=0
     autologin-session=lightdm-autologin
     user-session=mythbuntu
     allow-guest=false
     greeter-session=lightdm-gtk-greeter

You need to replace "AUTOLOGINUSER" to the name of the user that is normally logged in when the system starts up. This may be the "mythtv" user or it may be the user that you defined (besides root) when the system was initially installed. After you've done that, save the file and carry on. If you are really worried about GDM still starting up (it shouldn't, but you never know) you can do either (or both) of these:

     su
     update-rc.d -f gdm remove
     mv /etc/init/gdm.conf /etc/init/gdm.conf.off

Another thing you can check is that default-display-manager file in the X11 directory is set to lightdm. It should look like this:

/etc/X11/default-display-manager:

     /usr/sbin/lightdm

At this point, you should be able to start lightdm and X-Windows will come up on your primary display. You will either see the desktop or, if MythTV is set to auto start, you'll see it starting up:

     su
     start lightdm

If this doesn't work, you may still need to repair any changes made to the xorg.conf file by the system upgrade. You can begin by trying automatic configuration:

     su
     stop lightdm
     Xorg -configure
     cd /etc/X11
     mv xorg.conf xorg.conf.backup
     mv /root/xorg.conf.new .
     start lightdm

You may need to tweak the configuration file that is generated by configure but it is supposed to match your hardware. If it doesn't (usually because X-Windows cannot probe the monitor to get the EDID), LightDM may not start. A Web page that describes how to fix the problem can be found here:

     http://taggedzi.com/blog/display/ubuntu-11-and-nvidia-173-woes

If worst comes to worst, we keep a generic xorg.conf file that we can use when configure fails. This file is for NVidia graphics chipsets. It ain't much but it may get you up and running:

/etc/X11/xorg.conf.workee:

     Section "Monitor"
         Identifier      "Configured Monitor"
     EndSection
     Section "Screen"
         Identifier      "Default Screen"
         Monitor         "Configured Monitor"
         Device          "Configured Video Device"
         DefaultDepth    24
     EndSection
     Section "Module"
         Load    "glx"
     EndSection
     Section "Device"
         Identifier      "Configured Video Device"
         Driver          "nvidia"
         Option          "NoLogo"  "True"
     EndSection

If you have a different chipset, you'll need to change the video device driver name.

A cycle of all of the steps, beginning with booting Mythbuntu and applying all of the available online updates, ensues. You apply the online updates to the current release to bring it up to snuff and then upgrade it to the next release. Once you've finally arrived at the release that you're trying to get to, move on to the next step.

The upgrade process usually wipes out proprietary device drivers, etc. The NIC driver will already have been installed in the prior steps. You should also fire up the Mythbuntu Config tool (from the System menu) and install any of the recommended proprietary device drivers (e.g. NVidia). However, if you built the latest NVidia driver from scratch because you have a display that is not recognized by the regular, proprietary device driver, you will need to reinstall it because the driver will have been compiled against a kernel that is no more (see, for example, the Newest NVidia Driver section, above).

If you installed any special drivers (e.g. the saa7134-dvb driver, as described in "AVerMedia A180 Capture Card", above), you may need to reinstall them. Follow the steps outlined in the appropriate sections elsewhere. And, note that the names of the various blacklist and config files in /etc/modprobe.d may have changed. The newer versions of Mythbuntu require that the blacklist and config files (except for "options") be suffixed with ".conf". So, beware that the names of the files used to blacklist your special drivers may have changed.

Another feature of the wiping-out-drivers philosophy is that the sound control settings that you very carefully set, using alsamixer, are often wiped out too. If you experience sound problems (e.g. reduced volume) after the upgrade, see the section on "Sound Problems" (above) for tips on how to fix those sound problems.

When you upgrade to a later release of Mythbuntu (i.e. >= 9.04), you should read the section above about "Update Manager -- Not Another Good Idea". Upon upgrading to the later release of Mythbuntu, you will probably find the new behavior of the Update Manager to be a real pain in the butt and want to consult this section about how to turn it off immediately.

Since you'll probably be installing and removing packages as you go, you may want to consult the "Useful Software" and "Useless and Annoying Software" sections to at least figure out how to add the Synaptics Package Manager and remove the Ubuntu Software Center. While you're at it, you might as well install the rest of the useful packages and remove the rest of the annoying packages. All of your previous efforts, in this respect, will have been tossed away during the system upgrade.

And, speaking of butt pain, you may discover that the setup of your desktop has been altered when you upgrade to a later release of Mythbuntu. The most noticeable "feature" will be the disappearance of the desktop toolbar. If this happens, or if you notice any other little infelicities on your desktop, when you upgrade, you should see the "Desktop Problems" section, above, for notes about what to do.

Another "feature" of later releases of Mythbuntu is that the halt and shutdown commands that are invoked by the Myth frontend have been replaced by a shell script that uses dbus to tell HAL that it should shutdown or reboot the system. Too baddy that it only works some of the time. You may want to proceed to the Utilities/Setup/General menu item in the frontend and page forward to the Miscellaneous page where you can set:

     Halt Command: halt
     Reboot Command: reboot

On the other hand, if you really like the concept of using dbus to tell HAL what to do, you should upgrade these two settings for the newly upgraded system, since they will be left as is from before. The new settings are:

     Halt Command: /usr/share/mythtv/myth-halt.sh
     Reboot Command: /usr/share/mythtv/myth-reboot.sh

As with all upgrades to Mythbuntu, the LIRC setup is wiped out so your remote control will no longer work. If you are lucky, your orginal files will be preserved and suffixed with "dpkg-old" or maybe just "old". You can then delete the new files, installed by the upgrade, and replace them by the dpkg-old or old files. Here's what to look at:

     /etc/init.d/lirc
     /etc/lirc/hardware.conf
     /etc/lirc/lircd.conf

The lircd.conf file is made up on the fly by the lirc service script so you can just delete the newly-installed version. The lircd.conf.dpkg-old file can just be deleted too. Meanwhile, you should replace the /etc/init.d/lirc file with the script shown above, and the /etc/lirc/hardware.conf file with the saved one that you found under hardware.conf.old or that you saved elsewhere or that you made up according to instructions above.

Any upgrades to Mythbuntu may cause the MythWeather package to be upgraded too. If this happens, you are likely to lose any changes to the weather information extraction scripts that you made. Consequently, if you've included the Current Conditions page on your Mythbuntu weather page and the extraction script hasn't yet been fixed or if you've added any custom weather information extraction scripts, you may have to go back and reinstall the scripts, as described in the MythWeather section (above).

You should check the mythtv-database script, if you've upgraded it to run daily instead of weekly, to ensure that it is still in the /etc/cron.daily directory. Also, recheck that the upgrade has not added a copy of this script back to the /etc/cron.weekly directory where it will conflict with the running of the script on a daily basis.

If you are mounting sharepoints to support a remote video server (as described below under "Mounting Shares Under Mythbuntu"), you may find that the mounts no longer work. The upgrade will probably leave /etc/fstab as it was so that the mounts are still found in fstab but they will fail because the utilities supplied by the smbfs package will be missing. The upgrade will have removed the smbfs package. Searching for "samba" in the package manager should yield a list. If smbfs is not installed, follow the steps described in "Mounting Shares Under Mythbuntu" to install it and get the mounts working.

Also, if you have any additional drives that were formatted with the XFS file system, and the XFS file system wasn't installed on the system drive, you will probably see a message about "a serious error" upon startup, as the system tries to mount these drives. You can choose to skip the error and then mount the drives later on, with no problems, like this:

     mount /mnt/sdb1

So, what's going on? Because the system drive isn't an XFS drive, the upgrade decided that there was no need to install the xfsprogs package. This package contains the fsck.xfs program which is needed to check XFS drives. Since it was missing, when fsck tried to invoke it to check the XFS drives at startup, the check failed and fsck decided that there was a serious error. However, there's nothing really wrong with the drives, which is why you can mount them later on. The solution is to reinstall the xfsprogs package, like this:

     apt-get install xfsprogs

If you set up UPS monitoring with NUT, it will probably no longer work after a release upgrade. In all probability, any changes to the udev rules will be wiped out by the upgrade, which will disallow NUT from taking control of the UPS devices as it should. Another clever trick of release upgrades is to wipe out changes you've made to startup scripts in /etc/init.d with something "better" or "smarter". You should go over the install instructions in the UPS Monitoring with NUT section (above) to make sure that UPS monitoring is still installed and working correctly.

After you've completed your upgrade and tested everything thoroughly, you should reboot all of the other secondary backends and frontends in your network, if they depend on the upgraded machine as a primary backend. Don't ask me why this is necessary but it is. Some things will appear to be working OK, before the reboot, but others (e.g. sharing encoders across the network) will not work. The reboot seems to cure all.

Using the Latest MythTV Release

The Mythbuntu team provides a package (mythbuntu-repos) that provides a set of repositories which can be easily activated to update the software shipped with Mythbuntu to later versions and/or install additonal packages. The packaging used for the builds in these repositories is identical to that used for content in the Ubuntu archive so the use of these repositories is seamless.

The repository installed by the mythbuntu-repos package contains updates to MythTV that are automatically built each day when there are upstream fixes available. The repository also contains fixes for software written specifically for Mythbuntu such as Mythbuntu Bare, Mythexport and Mythbuntu Log Grabber.

Once the package is installed, you can control how it is deployed from the Mythbuntu Control Center. From the MCC, you can select the MythTV series that you wish to receive updates for, enable or disable updates to the Mythbuntu-specific applicatons, or even disable the use of the repository altogether, if you no longer desire to make use of it in the future.

You typically would use the repository installed by the mythbuntu-repos package if you want to install and keep up to date with a later version of MythTV than the one shipped with your version of Mythbuntu (e.g. on Mythbuntu 10.10, you wish to use MythTV 0.24), if you want to test the development version of MythTV, or if you want to upgrade to a Beta version of MythTV but not keep up with any of the later development updates.

Selecting a MythTV series from the Mythbuntu Control Center will only get you updates for that series. So, for example, if you select MythTV 0.24, you will only receive updates that upstream releases to the 0.24 series. To change to another series (such as 0.25), simply open the Mythbuntu Control Centre again, and modify the Repositories tab to the new series.

To begin, you can install the mythbuntu-repos package from the browser, on the system where it is to be installed, by surfing over to:

     http://www.mythbuntu.org/auto-builds

Once you get to that page, follow the "Install the Mythbuntu-repos package" link. After you've done that, you need to run the software updater (from the desktop/system menu) to install all of the updates that are implied by the series of MythTV that you choose during the install.

Alternately, you can do the following from the command line (in a temporary directory):

     su
     wget http://www.mythbuntu.org/files/mythbuntu-repos.deb
     dpkg -i mythbuntu-repos.deb
     apt-get update
     apt-get upgrade

In this case, when you install the repository, you'll choose the MythTV series that you want installed on your system and then, when you run the upgrade, you'll be upgraded to that series.

At a later date, you can proceed to the Mythbuntu Control Center and select a different series. If you do so, be sure to run the software updater (from the desktop/system menu) to install all of the updates that are implied by the new series of MythTV that you choose.

Caching Updates With Apt-Cacher

If you do decide to judiciously apply updates or patches to your Mythbuntu machines (see the Updates and Upgrading To A Later Release Of Mythbuntu), and you have more than one machine, and you keep all of the machines at the same distribution level, you might want to consider using apt-cacher to cache a local copy of the updates, so that all of your machines do not need to repeatedly download the updates off the Internet.

You should choose a machine which will hold the cache repository and set up apt-cacher there. We usually pick the same machine as the master backend, since it is (by default) visible to all of the other systems and must be running at all times. However, any machine with enough spare disk space to support the cache can be used.

Begin by installing the apt-cacher package thusly:

     sudo apt-get install apt-cacher

Once this is done, edit the apt-cacher configuration file (/etc/apt-cacher/apt-cacher.conf) to set up your specific options. Although you shouldn't have to change much, here are a few things for your consideration.

The default port that apt-cacher runs on is port 3142. You might want to change it if it collides with something else on your system (we can't think what, but ya never know).

By default, all hosts are allowed to use the repository cache. You probably want to lock this down so that only hosts on your local subnet can use it. For example, if your local subnet is 192.168.1, and you want to allow all machines on it and the local host to use the cache, you might set:

     allowed_hosts=192.168.1.0/24, 127.0.1.1

The traditional local host (127.0.0.1) is allowed by default so it is not necessary to add it. Apparently, on Ubuntu boxes, 127.0.1.1 is also considered to be the local host (if this is really true, nice going boneheads -- just what we need is another way of doing the same old thing differently) so, just in case somebody has a go at the cache with that IP address we allow it too.

By default, apt-cacher creates a report on a daily basis on how efficient your cache was. You might think, what's the point, who needs this? If so, you can turn it off:

     generate_reports=0

The part of the configuration that you do have to set up is the path map. This tells apt-cacher where to look for the packages that are to be fetched for its clients and stored in the cache. You'll probably want to include all of the repositories, that are going to be used by the clients, in this list.

We begin making up the list by examining the original /etc/apt/sources.list files on one or more, perhaps all, of the client machines. Here's a sample:

/etc/apt/sources.list:

     deb http://us.archive.ubuntu.com/ubuntu jaunty \
         main restricted universe multiverse
     deb http://us.archive.ubuntu.com/ubuntu jaunty-updates \
         main restricted universe multiverse
     deb http://security.ubuntu.com/ubuntu jaunty-security \
         main restricted universe multiverse
     deb http://archive.canonical.com/ubuntu jaunty partner
     deb-src http://us.archive.ubuntu.com/ubuntu jaunty-updates \
         main restricted universe multiverse
     deb-src http://us.archive.ubuntu.com/ubuntu jaunty \
         main restricted universe multiverse
     deb-src http://security.ubuntu.com/ubuntu jaunty-security \
         main restricted universe multiverse
     deb-src http://archive.canonical.com/ubuntu jaunty partner

There's a lot of commonality in the URLs that are found in this sample file. Essentially, there are three types: the Ubuntu archives; the security archives; and the archives of the bonus packages from Canonical. In the apt-cacher path list, we need to map these URLs to an alias name that the clients can use to reference those archives. The names chosen for the aliases don't matter but it is better to choose something that makes sense to you. Based on the URLs in the original /etc/apt/sources.list, we might set the path list up like this:

     path_map = ubuntu us.archive.ubuntu.com/ubuntu ; \
                security security.ubuntu.com/ubuntu ; \
                canonical archive.canonical.com/ubuntu

Normally, its OK to use the URLs that your system installation chose. But, if you are experiencing performance delays or other problems, now is a good time to choose mirrors that actually work for you. If you need help deciding which ones to use, the list can be found at:

     https://launchpad.net/ubuntu/+archivemirrors

According to the Ubuntu documentation, "if you are unsure which mirror to select the best option is [iso-country-code].archive.ubuntu.com where iso-country-code is the two character country abbreviation of a country near you. For example, if you live in the United States you could choose us.archive.ubuntu.com".

Once you've set up aliases to all of the URLs in the path list, you can access them on the client machines like this:

     repository_cache_machine:port/alias_name

So, for instance, we can access the ubuntu and security repositories through:

     http://myrepository:3142/ubuntu
     http://myrepository:3142/security

Now that we've chosen all the local options, here is a complete listing of a sample apt-cacher configuration file:

/etc/apt-cacher/apt-cacher.conf:

     #################################################################
     # This is the config file for apt-cacher. On most Debian systems
     # you can safely leave the defaults alone.
     #################################################################
     # cache_dir is used to set the location of the local cache. This can
     # become quite large, so make sure it is somewhere with plenty of space.
     cache_dir=/var/cache/apt-cacher
     # The email address of the administrator is displayed in the info page
     # and traffic reports.
     admin_email=root@localhost
     # For the daemon startup settings please edit the file
     # /etc/default/apt-cacher.
     # Daemon port setting, only useful in stand-alone mode. You need to run the
     # daemon as root to use privileged ports (<1024).
     daemon_port=3142
     # optional settings, user and group to run the daemon as. Make sure they have
     # sufficient permissions on the cache and log directories. Comment the
     # settings to run apt-cacher as the native user.
     group=www-data
     user=www-data
     # optional setting, binds the listening daemon to specified IP(s). Use IP
     # ranges for more advanced configuration, see below.
     # daemon_addr=localhost
     # If your apt-cacher machine is directly exposed to the Internet and you are
     # worried about unauthorised machines fetching packages through it, you can
     # specify a list of IPv4 addresses which are allowed to use it and another
     # list of IPv4 addresses which aren't.
     # Localhost (127.0.0.1) is always allowed. Other addresses must be matched
     # by allowed_hosts and not by denied_hosts to be permitted to use the cache.
     # Setting allowed_hosts to "*" means "allow all".
     # Otherwise the format is a comma-separated list containing addresses,
     # optionally with masks (like 10.0.0.0/22), or ranges of addresses (two
     # addresses separated by a hyphen, no masks, like '10.100.0.3-10.100.0.56').
     allowed_hosts=192.168.1.0/24, 127.0.1.1
     denied_hosts=
     # And similarly for IPv6 with allowed_hosts_6 and denied_hosts_6.
     # Note that IPv4-mapped IPv6 addresses (::ffff:w.x.y.z) are truncated to
     # w.x.y.z and are handled as IPv4.
     allowed_hosts_6=fec0::/16
     denied_hosts_6=
     # This thing can be done by Apache but is much simpler here - limit access
     # to Debian mirrors based on server names in the URLs
     #allowed_locations=ftp ftp.uni-kl.de,ftp ftp.nerim.net,debian.tu-bs.de
     # Apt-cacher can generate usage reports every 24 hours if you set this
     # directive to 1. You can view the reports in a web browser by pointing
     # to your cache machine with '/apt-cacher/report' on the end, like this:
     #      http://yourcache.example.com/apt-cacher/report
     # Generating reports is very fast even with many thousands of logfile
     # lines, so you can safely turn this on without creating much 
     # additional system load.
     generate_reports=1
     # Apt-cacher can clean up its cache directory every 24 hours if you set
     # this directive to 1. Cleaning the cache can take some time to run
     # (generally in the order of a few minutes) and removes all package
     # files that are not mentioned in any existing 'Packages' lists. This
     # has the effect of deleting packages that have been superseded by an
     # updated 'Packages' list.
     clean_cache=1
     # Apt-cacher can be used in offline mode which just uses files already
     # cached, but doesn't make any new outgoing connections by setting this to 1.
     offline_mode=0
     # The directory to use for apt-cacher access and error logs.
     # The access log records every request in the format:
     # date-time|client ip address|HIT/MISS/EXPIRED|object size|object name
     # The error log is slightly more free-form, and is also used for debug
     # messages if debug mode is turned on.
     # Note that the old 'logfile' and 'errorfile' directives are
     # deprecated: if you set them explicitly they will be honoured, but it's
     # better to just get rid of them from old config files.
     logdir=/var/log/apt-cacher
     # apt-cacher can use different methods to decide whether package lists need
     # to be updated,
     # A) looking at the age of the cached files
     # B) getting HTTP header from server and comparing that with cached data.
     # This method is more reliable and avoids desynchronisation of data and index
     # files but needs to transfer a few bytes from the server every time somebody
     # requests the files ("apt-get update")
     # Set the following value to the maximum age (in hours) for method A or to 0
     # for method B
     expire_hours=0
     # Apt-cacher can pass all its requests to an external http proxy like
     # Squid, which could be very useful if you are using an ISP that blocks
     # port 80 and requires all web traffic to go through its proxy. The
     # format is 'hostname:port', eg: 'proxy.example.com:8080'.
     #http_proxy=proxy.example.com:8080
     # Use of an external proxy can be turned on or off with this flag.
     # Value should be either 0 (off) or 1 (on).
     use_proxy=0
     # External http proxy sometimes need authentication to get full access. The
     # format is 'username:password'.
     #http_proxy_auth=proxyuser:proxypass
     # Use of external proxy authentication can be turned on or off with this
     # flag.  Value should be either 0 (off) or 1 (on).
     use_proxy_auth=0
     # This sets the interface to use for the upstream connection.
     # Specify an interface name, an IP address or a host name.
     # If unset, the default route is used.
     #interface=
     # Rate limiting sets the maximum bandwidth in bytes per second to use
     # for fetching packages. Syntax is fully defined in 'man wget'.
     # Use 'k' or 'm' to use kilobits or megabits / second: eg, 'limit=25k'.
     # Use 0 or a negative value for no rate limiting.
     limit=0
     # Debug mode makes apt-cacher spew a lot of extra debug junk to the
     # error log (whose location is defined with the 'logdir' directive).
     # Leave this off unless you need it, or your error log will get very
     # big. Acceptable values are 0 or 1.
     debug=0
     # To enable data checksumming, install libberkeleydb-perl and set this option
     # to 1. Then wait until the Packages/Sources files have been refreshed once
     # (and so the database has been built up). You can also nuke them in the
     # cache to trigger the update.  
     # checksum=1
     # Print a 410 (Gone) HTTP message with the specified text when accessed via
     # CGI. Useful to tell users to adapt their sources.list files when the
     # apt-cacher server is being relocated (via apt-get's error messages while
     # running "update")
     #cgi_advise_to_use = Please use http://cacheserver:3142/ as apt-cacher \
     #                    access URL
     #cgi_advise_to_use = Server relocated. To change sources.list, run \
     #                    perl -pe "s,/apt-cacher\??,:3142," \
     #                    -i /etc/apt/sources.list
     # Server mapping - this allows to hide real server names behind virtual paths
     # that appear in the access URL. This method is known from apt-proxy. This is
     # also the only method to use FTP access to the target hosts. The syntax is
     # simple, the part of the beginning to replace, followed by a list of mirror
     # urls, all space separated. Multiple profile are separated by semicolons
     # Note that you need to specify all target servers in the allowed_locations
     # options if you make use of it. Also note that the paths should not overlap
     # each other. FTP access method not supported yet, maybe in the future.
     # path_map = debian ftp ftp.uni-kl.de/pub/linux/debian \
     #            ftp ftp2.de.debian.org/debian ; ubuntu archive.ubuntu.com/ubuntu ; \
     #            security security.debian.org/debian-security \
     #            ftp ftp2.de.debian.org/debian-security
     path_map = ubuntu us.archive.ubuntu.com/ubuntu ; \
                security security.ubuntu.com/ubuntu ; \
                canonical archive.canonical.com/ubuntu
     # Permitted package files - this is a perl regular expression which matches
     # all package-type files (files that are uniquely identified by their
     # filename).  The default is: 
     #package_files_regexp = (?:\.deb|\.rpm|\.dsc|\.tar\.gz|\.diff\.gz|\.udeb|\
     #                       index\.db-.+\.gz|\.jigdo|\.template)$
     # Permitted Index files - this is the perl regular expression which matches
     # all index-type files (files that are uniquely identified by their full path
     # and need to be checked for freshness). 
     # The default is:
     #index_files_regexp = (?:Index|Packages\.gz|Packages\.bz2|Release|\
     #                     Release\.gpg|Sources\.gz|Sources\.bz2|\
     #                     Contents-.+\.gz|pkglist.\.bz2|release|release\..|\
     #                     srclist.*\.bz2|Translation-.+\.bz2)$

Note that, at this point in time, there is a bug that occurs with Translation files. Essentially, it is OK for the client to ask for a translation file that does not exist but when it does so and the file is not found, apt-cacher returns an error code that is incorrect. It doesn't appear to cause any real problems (and there is a fix in the works) but you will notice the errors on your repository cache client machines. You may be tempted to try and fix it by altering the index_files_regexp (in the apt-cacher configuration file) but don't bother. Its a bug in apt-cacher so you won't be able to do so.

We never could understand the reasoning behind this, but, when you install apt-cacher, it is installed deactivated. The startup script is put in the proper place in /etc/init.d and symlinks added for the right run levels. None the less, you still need to activate it manually:

/etc/default/apt-cacher:

     AUTOSTART=1

Once you've done this, you can restart apt-cacher:

     sudo /etc/init.d/apt-cacher restart

The next time you boot the system, it should come up all on its own.

After apt-cacher is successfully set up and running, its time to update all of the repository cache clients so that they will use the local cache instead of the WAN-based repositories. This is done by editing their source list so that it points to the local repository cache. And, the first candidate for this treatment might as well be the machine where the repository cache actually resides so that any packages that it requests will prime the cache.

If the sample sources list, that was shown above, is altered to use the local repository cache, it should now be changed to look something like this:

/etc/apt/sources.list:

     deb http://myrepository:3142/ubuntu jaunty \
         main restricted universe multiverse
     deb http://myrepository:3142/ubuntu jaunty-updates \
         main restricted universe multiverse
     deb http://myrepository:3142/security jaunty-security \
         main restricted universe multiverse
     deb http://myrepository:3142/canonical jaunty partner
     deb-src http://myrepository:3142/ubuntu jaunty-updates \
         main restricted universe multiverse
     deb-src http://myrepository:3142/ubuntu jaunty \
         main restricted universe multiverse
     deb-src http://myrepository:3142/security jaunty-security \
         main restricted universe multiverse
     deb-src http://myrepository:3142/canonical jaunty partner

Go through the configuration files on all of the client machines and update them in a similar fashion. Once that is done, you should be able to apply updates to them, via the local repository cache, in your usual fashion.

If you set up apt-cacher after you've already applied packages to the machine that has the repository cache on it, it is possible that it already has those package files cached in its local repository. If you wish, you can import them to the apt-cacher repository, where they will be available to everyone. One of the ancilliary scripts installed in the /usr/share/apt-cacher directory, that was created when you installed apt-cacher, is apt-cacher-import.pl, which handles this task.

In a misguided attempt at security, the writer of the script forces it to run as the user/group set in /etc/apt-cacher/apt-cacher.conf. Unfortunately, this prevents it from doing anything useful with the local repository (it wants to move all of the packages that it finds from the local repository to the cache), since all of the files in the local repository are owned by whoever installed them (typically root).

Once could change the user/group in /etc/apt-cacher/apt-cacher.conf to root/root temporarily, we suppose, but this defeats the purpose of using a separate user for the cache. If you'd like to keep the separate user/group (www-data, by default) for the cache files, just comment out the code at about line 75 that reads:

     setup_ownership($cfg);

Change it to read:

     # setup_ownership($cfg);

People go way too far overboard with security. If the guy is running as super user, he should be able to do whatever he wants. Peeling his permissions back to something less ain't going to cut it. He's just going to edit your stupid code and do what he wants. Think about that....

Anyway, once you've fixed the code, to import the package files from the system's local repository (/var/cache/apt/archives) to the apt-cacher repository, run:

     sudo /usr/share/apt-cacher/apt-cacher-import.pl /var/cache/apt/archives

The apt-cacher directory (/var/cache/apt-cacher/packages) should now be filled up with all of the packages that were in the apt local repository. At the same time, the local repository should now be empty, since apt-cacher-import.pl moves the packages that it finds to the repository cache.

If you left the directive generate_reports set to 1 in the apt-cacher config file, apt-cacher will generate a report on cache usage every day. You can view the report by pointing your Web browser at the URL:

     http://myrepository:3142/report

Where "myrepository" is the name of the machine that runs apt-cacher.

If you need to regenerate the report at any time other than when it is normally done, run:

     sudo /usr/share/apt-cacher/apt-cacher-report.pl 

Creating A DVD Library

You can create a library of DVDs that can be played by Mythbuntu. This library can be located on the Mythbuntu box itself or placed on a shared video server. See below for the shared video server setup.

To begin with, you should turn your DVDs into ISO images. This can be done with Slysoft's AnyDVD and CloneDVD software. Insert the DVD into a machine that has AnyDVD installed on it. It will remove the copy protection, region encoding and most of the other cruft on the DVD. You can then launch CloneDVD to make a copy of the DVD using the "Clone DVD" feature. Now is the time to delete any tracks you don't want, subtitles, alternate languages, etc. Have CloneDVD write an ISO image to a suitable output directory (you can have it write the ISO image directly to the Mythbuntu box or shared video server, if it is mounted on the cloning machine).

Note that you can use the "Copy DVD Titles" feature to copy only the movie itself or individual TV episodes. This removes the menu and allows the viewer to pick the movie/episode directly (a good thing, considering that the MythTV internal viewer crashes a lot when displaying DVD menus). The output should still be an ISO image (which allows movies like "Bridge on the River Kwai", that have multiple tracks, to be treated as a single file).

If you don't have the cloning program write the output directly to the Mythbuntu box or shared video server, use FTP to copy the ISO image to proper place on the Mythbuntu box or the shared video server. If you don't use the shared video server to hold your movies/episodes, the common location for video files under Mythbuntu is in /var/lib/mythtv/videos.

MythVideo can display directories that are included in the video files tree. If you have DVDs for shows or multiple movies in a series and you'd like to group them together as one logical entry in the MythVideo display, make sub-directories under the top level directory. Give each sub-directory a name that will be recognizable when you browse it with MythVideo and put all of the related ISO images under it. For example:

     /var/lib/mythtv/videos/ANewLeaf.iso
     /var/lib/mythtv/videos/BuffyTheVampireSlayer
     /var/lib/mythtv/videos/BuffyTheVampireSlayer/BVS1-1.iso
     /var/lib/mythtv/videos/BuffyTheVampireSlayer/BVS1-2.iso
     /var/lib/mythtv/videos/BuffyTheVampireSlayer/BVS2-1.iso
          .
          .
          .
     /var/lib/mythtv/videos/TheWindAndTheLion.iso

Compressing DVDs

Once you've created your DVD library and filled up all of the disks with content, you may decide that buying a new hard disk every few weeks isn't such a great idea. Compression may prove to be a more attractive option.

Bear in mind that nobody compresses video files to improve their quality. But, fortunately, most of the content that appears on DVDs is encoded with the MPEG2 algorithm, which uses much more space than the latest encoding algorithms. Re-encoding them with Xvid or H.264, for example, can often lead to a 3 to 1 compression ratio, thereby allowing you to triple your video server's capacity, obviating the need to buy more disks, with little observable degradation in quality.

The mencoder component of the MPlayer package works quite well for compressing DVDs into hiqh-quality AVI files, which can be played by Mythbuntu. You can use the version of MPlayer that comes with your system but it is better to use the latest version and build it yourself. Here are the steps that are necessary to build it.

There are a number of basic tools that are required to build MPlayer. You can install them (or make sure that they are already installed) with apt-get:

     sudo apt-get install build-essential subversion checkinstall yasm git-core

Next, all of the sound and video development libraries must be installed. These can be installed (or checked for installation) with apt-get:

     sudo apt-get install libaa1-dev libasound2-dev libcaca-dev \
       libcdparanoia-dev libdca-dev libdirectfb-dev libggi-target-fbdev \
       libenca-dev libesd0-dev libfontconfig1-dev libfreetype6-dev \
       libfribidi-dev libgif-dev libgl1-mesa-dev libjack-jackd2-dev \
       libmp3lame-dev libmpg123-dev libopenal1 libpulse-dev librtmp-dev \
       libsdl1.2-dev libsvga1-dev libvdpau-dev libxinerama-dev libxv-dev \
       libxvmc-dev libxxf86dga-dev libxxf86vm-dev

The MPlayer Web site has a single tar file that contains many of the useful codecs that make MPlayer work so well. You should download the latest file to your installation directory from:

     http://www.mplayerhq.hu/MPlayer/releases/codecs

If you have a 32-bit system, you should look for the codecs file that is named something like:

     all-20110131.tar.bz2

If you have a 64-bit system, you should look for the codecs file whose name is like:

     essential-amd64-20071007.tar.bz2

In this case, you won't get nearly as many codecs as are in the 32-bit tar file. So sad.

Whichever set of codecs you download, the next step is to extract them and install them where MPlayer can find them:

     cd mplayer-build
     tar xvjf all-20110131.tar.bz2
     su
     mkdir /usr/lib/codecs
     cp all-20110131/* /usr/lib/codecs

Most compression, these days, is done either with the Xvid or x264 (also known as H.264) codecs. If your system does not already have these codecs installed or the versions installed are out of date, you should build them from the latest source and install them separately, before you try to build MPlayer. You should especially make sure that you have the latest source for the x264 codec, if you'll be using it for high quality videos (e.g. those that you won't be watching on an iPod, tablet or laptop with a small screen), since earlier versions of this codec produced some pretty crappy results (in our opinion).

The latest source for building the Xvid codec can be downloaded from http://www.xvid.org/downloads.html. Once you have it, proceed to unpack the source. The last time we looked, the unpacked directory was given an unfortunate choice of names so we like to move the generic "xvidcore" directory to a directory that mirrors the version of the codec that is downloaded:

     cd mplayer-build
     tar -xvjf xvidcore-1.3.2.tar.bz2
     mv xvidcore xvidcore-1.3.2
     cd xvidcore-1.3.2

Now, configure and build the Xvid core, which contains the codec itself:

     cd build/generic
     ./configure --prefix=/usr
     make

To install the Xvid core, do so like this:

     su
     make install

Next, we want to make sure that the system will use the latest Xvid shared library, that you just built and installed. To check if there is an existing Xvid core dynamic library already installed, as well as to check for the newly installed library, do this:

     su
     cd /usr/lib
     ls -l libxvidcore.so.*

If you don't see a symlink to the xvidcore that you installed, that contains only the major version number, you should add it something like this:

     ln -s libxvidcore.so.4.3 libxvidcore.so.4

Before you can build the x264 codec, the newest goat rope in this respect is that the build requires yasm-1.2.0. Too baddie that the most current version of Ubuntu (for example) only includes yasm-1.1.0. Since the assembler probably hasn't changed for the last 20 years, its dubious that this requirement is indeed real but that's the way it is.

Oh, well. Its easiest enough to build. Obtain the source from: http://yasm.tortall.net/Download.html. Switch to the download directory, extract the source, and get ready to configure the build:

     cd yasm-build
     tar -xvzf yasm-1.2.0.tar.gz
     cd yasm-1.2.0

Now, configure and build the assembler:

     ./configure --prefix=/usr
     make

To install the assembler core, do so like this:

     su
     make install

The latest source for building the x264 codec can be downloaded from http://www.videolan.org/developers/x264.html. If you have trouble getting to the FTP directory or you prefer to use HTML, you can look in the snapshots directory, http://download.videolan.org/pub/videolan/x264/snapshots/. Once you have the source, proceed to unpack it:

     cd mplayer-build
     tar -xvjf x264-snapshot-20130906-2245-stable.tar.bz2
     cd x264-snapshot-20130906-2245-stable

Now, configure and build the x264 codec:

     ./configure --prefix=/usr --enable-shared
     make

To install the x264 codec, do so like this:

     su
     make install

Next, we want to make sure that the system will use the latest x264 shared library, that you just built and installed. To check if there is an existing x264 dynamic library already installed, as well as to check for the newly installed library, do this:

     su
     cd /usr/lib
     ls -l libx264.so*

If you don't see a symlink to the libx264 that you installed, that contains only the major version number, you should add it something like this:

     ln -s libx264.so.129 libx264.so

If you anticipate that you'll want live streaming media support in your version of MPlayer (i.e. you won't be just using mencoder to compress files and you may want to look at any of the online media sites), you should get the latest version of Live555, since it is used by MPlayer to handle live streams such as RTP/RTCP, RTSP and SIP. Live streaming protocols are constantly being tuned for performance, so it is always best to have the latest and greatest version.

You can find the latest Live555 source in the public directory on the Live555 Web site:

     http://www.live555.com/liveMedia/public/

The easiest way to get the latest source is to download the live555-latest.tar.gz file. This will be symlinked to the latest version, whatever it is. Once you have the Live555 source, unpack it. We like to move the generic "live" directory to a directory that mirrors the version of the software that is downloaded:

     cd mplayer-build
     tar xvzf live.2011.09.19.tar.gz
     mv live live-2011.09.19
     cd live-2011.09.19

Now, depending on whether you wish to build the 32-bit version, build the makefiles like this:

     ./genMakefiles linux

Or, for the 64-bit version, build the makefiles like this:

     ./genMakefiles linux-64bit

Then make the Live555 server and development files like this:

     make

The Live555 package doesn't include any install procedure. They suggest that you simply copy the entire build tree to /usr/lib. If you think this is a reasonable way to do things, have at it. We prefer to move only the files that are actually necessary (you know, like the way a real install works):

     su
     mkdir /usr/include/liveMedia
     install -m 644 BasicUsageEnvironment/include/.hh /usr/include/liveMedia
     install -m 644 groupsock/include/.hh /usr/include/liveMedia
     install -m 644 liveMedia/include/.hh /usr/include/liveMedia
     install -m 644 UsageEnvironment/include/.hh /usr/include/liveMedia
     install -m 644 BasicUsageEnvironment/libBasicUsageEnvironment.a /usr/lib
     install -m 644 groupsock/libgroupsock.a /usr/lib
     install -m 644 liveMedia/libliveMedia.a /usr/lib
     install -m 644 UsageEnvironment/libUsageEnvironment.a /usr/lib
     install mediaServer/live555MediaServer /usr/bin

If you ever need to do a reinstall of a newer version of Live555, you can simply delete all of the files in the "liveMedia" directory and recopy the newer files:

     su
     rm -f /usr/include/liveMedia/
     install -m 644 BasicUsageEnvironment/include/.hh /usr/include/liveMedia
          .
          .
          .
     install mediaServer/live555MediaServer /usr/bin

There is no real version numbering scheme for MPlayer. Rather, you go to the MPlayer site and download the latest stable source from the source code control system. If you go to the MPlayer site (www.mplayerhq.hu) and follow the source download links, you'll eventually end up here:

     http://www.mplayerhq.hu/MPlayer/releases/

Once in this directory, you can download either the checkout or source snapshot (we prefer the source snapshot):

     mplayer-export-snapshot.tar.bz2

After you've downloaded the snapshot, you can unpack it:

     cd mplayer-build
     tar -xvjf mplayer-export-snapshot.tar.bz2

We prefer to then rename the snapshot tar file to the same name as the directory that it unpacks to, just to keep things straight. Then we change to the extracted directory:

     mv mplayer-export-snapshot.tar.bz2 mplayer-export-2013-09-07.tar.bz2
     cd mplayer-export-2013-09-07

The next step is to configure MPlayer so that we can build it. Note that during the configure step, you will also be asked to download the FFmpeg git source. You must allow this by pressing "Enter", when you are asked if you want to do so, otherwise the configure step will not complete. Here is the configure command we use:

     ./configure --prefix=/usr --confdir=/etc/mplayer \
                 --codecsdir=/usr/lib/codecs \
                 --enable-live --extra-cflags="-I /usr/include/liveMedia"

If you didn't build Live555 or keep the system's version of Live555 (or if Live555 is still broken), you should use this configure command to disable it:

     ./configure --prefix=/usr --confdir=/etc/mplayer \
                 --codecsdir=/usr/lib/codecs --disable-live

The build is simple:

     make

Likewise, the install is simple:

     su
     make install

#>>>>>>
After
#))))))
make && \
sudo checkinstall -D --install=yes --fstrans=no --pakdir "$HOME/mplayer_build" \

     --pkgname mplayer --backup=no --deldoc=yes --deldesc=yes --delspec=yes --default \
     --pkgversion "2:1.0~svn$(LC_ALL=C svn info 2> /dev/null | \
       grep Revision | cut -d' ' -f2)" && \

make distclean

#((((((

Two pass compression:

     mencoder ISOFiles/Path/movie.iso \
       -nosub -vf pullup,softskip,harddup -nosound \
       -ovc x264 -x264encopts bitrate=2400:subq=1:frameref=1:threads=auto:pass=1 \
       -o /dev/null
     mencoder ISOFiles/Path/movie.iso \
       -nosub -vf pullup,softskip,harddup -oac copy \
       -ovc x264 -x264encopts bitrate=2400:subq=5:8x8dct:frameref=2:bframes=3: \
         b_pyramid=normal:weight_b:partitons=all:me=umh:threads=auto:pass=2 \
       -of avi -o movie.avi

#))))))

Xvid Options - VirtualDub

Filter - deinterlace

     x  interpolate using Yadif
     x  keep top field, interpolate/discard bottom field

Frame Rate

     Source Rate: No Change
     Frame Rate Conversion: Process all frames

Color Depth

     Decompression format: x  4:2:2 TCbCr (YUY2)
     Output format: x  24-bit RGB (888)

Profile (Xvid Home)

     Quantization: MPEG
     Adaptive Quantizer: off
     B-VOPs
       Max Consecutive B-VOPs: 2
       Quantizer ratio: 1.50
       Quantizer offset: 1.00
     Packed bitstream: v

Level

     720 x 576 x 25
     Max frame size (macro blocks): 1620
     Max processing rate (mbps): 40500

Video Buffer Verifier

     Max Buffer Size: 3145728
     Max Bitrate (kbps): 4854.000
     Max Bits over any 1 second interval: 8000000

Aspect Ratio

     Display aspect ratio:  x
       16:9

Encoding Type

     Twopass - 1st pass
       Filename: .\video-pass
       Discard 1st pass:  x
     Twopass - 2nd pass
       I-frame boost (%): 10
       I-frames closer than (frames): 1
         are reduced by (%): 20
       Overflow Control Strength (%): 5
       Max overflow improvement (%): 5
       Max overflow degradation (%): 5
       High bitrate scenes degrade (%): 0
       Low bitrate scenes improve (%): 0
       Target bitrate (kbps): 1200
     Quality Preset: General Purpose

Xvid Options - Mencoder

-vc xvid

For interlaced sources:

     -field-dominance 0 -vf yadif=3,mcedeint=2:1:10,framestep=2

For interlaced sources that start with the bottom frame:

     -field-dominance 1 -vf yadif=3,mcedeint=2:1:10,framestep=2

For telecined sources:

     -vf pullup,softskip,pp=lb

-passlogfile .\video.pass

-xvidencopts

     quant_type=mpeg
     me_quality=6
     noqpel
     nogmc
     notrellis
     nocartoon
     chroma_opt
     hq_ac
     vhq=3
     bvhq=1
     nolumi_mask
     max_bframes=2
     bquant_ratio=150
     bquant_offset=100
     curve_compression_high=0
     curve_compression_low=0
     overflow_control_strength=5
     max_overflow_improvement=5
     max_overflow_degradation=5
     packed
     aspect=16/9  or  autoaspect
     profile=dxnhtntsc
     threads=4
     pass=1
     pass=2
     keyframe_boost=10
     kfthreshold=1
     kfreduction=20
     vbv_bufsize=3145728
     vbv_maxrate=4854000
     bitrate=1200

#<<<<<<

Shared Video Server

You can store videos on any network-attached server that has lots of room, a high-speed network connection and a processor that will be able to keep up with the load of serving packets to the frontends. Typical DVDs average between 4 and 8 gigabytes so you can figure how big the server's disks need to be to hold your collection. For a 1TB drive, you can expect between 100 and 220 DVDs. A nicely-sized video server can be built from four 1TB drives. Even better would be a video server with four 2TB drives, which will let you hold all of your DVDs plus all the episodes of your favorite television shows.

You need to run a recent version of Samba on the server so if you don't have a copy, install it now. Older versions of Samba only support SMBFS, whereas newer versions support CIFS, which is much better. So, although you can mount the older Samba share on Mythbuntu, using smbfs, you may get unexpected I/O errors and other such problems that can cause you grief. Using a newer version of Samba and CIFS should help.

Set up a video directory (or high-level directory with mount points for multiple disks) on the server. You should have a single, top level directory that you can expose to the outside world as one mount point. You can have multiple directories below that will be handled by the MythVideo setup. If you have a video server with two disks, for example, one of which contains the root file system, you could try:

     mkdir /DVD
     mkdir /DVD/sda
     mkdir /DVD/sdb

Since the /DVD/sda directory actually resides on the same disk as the root file system, you can just copy the ISO images directly to /DVD/sda. In /etc/fstab, add a line to mount /dev/sdb to the /DVD/sdb mount point. For example:

     /dev/sdb1  /DVD/sdb  ext3  0  0

Then, mount the new partition:

     mount -a

You may then copy the ISO images to /DVD/sdb as well.

Also, you should set up a posters directory that will hold all of the DVD posters or covers that are downloaded from the Internet or made up by you (see below). This is necessary because the only copy of the database will point to this directory, so it must be accessible to all of the Mythbuntu machines that will access the DVD library. At the moment you don't need to put anything in this directory but you do need to make it:

     mkdir /DVD/posters

Adjust the Samba config file to allow the high-level video directory to be mounted by guests.

     /etc/samba/smb.conf
     Basically, all you have to do is add a share point for the DVD library:
      [DVD]
         comment = DVD Library
         path = /dvdlib
         browseable = yes
         read only = yes
         guest ok = yes
     You do not need to monkey with any of the other security settings in the
     Samba config file.
     Restart Samba to get it to export the new share.

If you run out of space and want to add another drive, install the drive in the server and then format its space using fdisk:

     su
     /sbin/fdisk /dev/sdc
       n                         (To create a new partition)
       p                         (As a primary partition)
       1                         (Partition 1)
       <cr>                      (To accept the first cylinder as the start)
       <cr>                      (To accept the last cylinder as the end)
       w                         (Write the partition table to the disk)

You can check your work with:

     /sbin/fdisk -lu /dev/sdc

You should see something like this:

     Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes
     255 heads, 63 sectors/track, 121601 cylinders
     Units = cylinders of 16065 * 512 = 8225280 bytes
     Device Boot      Start         End      Blocks   Id  System
  /dev/sdc1               1      121601   976760001   83  Linux

The next step is to make the file system, that you wish to appear in the partition, with mkfs. Usually for a video server, you should pick an ext3 file system and use mkfs.ext3:

     /sbin/mkfs.ext3 -j -L / -T news /dev/sdc1

If you have one of the advanced format hard drives (e.g. the new 1.5 or 2 TB drives from Western Digital or Samsung), you need to pay particular attention to how you create the partitions on the drive so that they are always aligned on a 4K boundary. If you don't do this, performance will suffer heavily.

If you are only creating a single partition, fdisk will default to creating the partition starting at sector 63 (it keeps the first 63 sectors, from 0-62, for the partiton table and boot information). In the case of advanced format hard drives, this is a very unfortunate choice. To override this default choice, partition the disk as follows:

     su
     /sbin/fdisk /dev/sdc
       u                         (All sizes are given in sectors, not cylinders)
       n                         (To create a new partition)
       p                         (As a primary partition)
       1                         (Partition 1)
       64                        (Start the partition on a 4K boundary [i.e. 0
                                   mod 8])
       <cr>                      (To accept the last sector as the end)
       w                         (Write the partition table to the disk)

You can check your work with:

     /sbin/fdisk -lu /dev/sdc

You should see something like this:

     Disk /dev/sdc: 2000.3 GB, 2000398934016 bytes
     255 heads, 63 sectors/track, 243201 cylinders, total 3907029168
     Units = sectors of 1 * 512 = 512 bytes
     Device Boot      Start         End      Blocks   Id  System
  /dev/sdc1              64  3907029167  1953514552   83  Linux

The next step is to make the file system, that you wish to appear in the partition, with mkfs. Usually for a video server, you should pick an ext3 file system and use mkfs.ext3. Note that it is extremely important, regardless of which file system you choose, that the block size chosen for the file system is a multiple of 4096. If not, there will be a severe performance hit. Thus, for mkfs.ext3, use:

     /sbin/mkfs.ext3 -b 4096 -j -L / -T news /dev/sdc1

Since the file system will only hold static data, there's no real reason to have fsck check it at boot time. This is especially relevant because for the large file systems that are found on 1 or 2TB disks, checking the file system could take a very, very long time (i.e. hours and hours). If you have several large disks on your video server and all of the file systems happen to get coincidentally checked, booting your system could easily take half a day. You will most certainly want to turn off this dubious feature with:

     /sbin/tune2fs -c 0 -i 0 /dev/sdc1

To hook the new disk up to your video server, add another subdirectory to the high-level directory that contains the mount points for the multiple disks on the server:

     mkdir /DVD/sdc

In /etc/fstab, add a line to mount /dev/sdc to the /DVD/sdc mount point. For example:

     /dev/sdc1  /DVD/sdc  ext3  0  0

Then, mount the new partition:

     mount -a

You may then copy the ISO images to /DVD/sdc as well. If you are into housekeeping, you may want to delete the superfluous lost+found directory:

     rm -rf /DVD/sdc/lost+found

Proceed to the steps below on setting up the new shared video directory under Mythbuntu.

Mounting Shares Under Mythbuntu

To begin with, make sure that the appropriate Samba components are installed on the system. Normally, only the Samba server is installed but to mount CIFS or SMBFS share points additional packages are required. You may wish to include the utility commands installed with the Samba client package (smbclient) to aid you diagnosing problems, etc. However, all that is really necessary (on later systems, at least) is either the smbfs package or the cifs-utils package. Searching for "samba" and or "cifs" in the package manager should yield a list. Be sure to install the same version of the client and utilities as the version of Samba that is already installed on your system. If you are brave and you don't want to use the package manager to check what you're installing, you can try:

     sudo apt-get install smbclient cifs-utils

Note that the smbfs package is supposed to be superseded by the cifs-utils package but that some people experience problems with CIFS. If you are one of them, you may have to revert to SMBFS. To do this, install the smbfs package, which requires cifs-utils as one of its prerequisites:

     sudo apt-get install smbfs

Once the appropriate packages are installed, you should be able to do:

     man mount.cifs

and optionally:

     man mount.smbfs

Share points need to be mounted in the Mythbuntu file system somewhere. Usually, the top-level directory /mnt is used for this. We like to keep things organized so we create a second-level directory named after the machine we're mounting from and a third-level directory named after the share name. So, for example:

     sudo mkdir /mnt/videoserv
     sudo mkdir /mnt/videoserv/DVD

You can mount the shared video directory on a one-time-basis (good for testing) or permanently. To do it on a one time basis, use:

     sudo mount -t cifs //192.168.1.10/DVD /mnt/videoserv/DVD --verbose -o
       ro,guest,user=guest,sec=none,iocharset=utf8

If you have problems mounting shares from an older version of Samba, you may be able to change "cifs" to "smbfs" (after you install smbfs, per the instructions above) but you should really upgrade your older Samba to a later version. Under the latest kernels, "smbfs" may not be supported.

To mount the share permanently, edit /etc/fstab with your favorite editor and add a line to mount the share:

     sudo emacs /etc/fstab
     /etc/fstab
     #Samba shares
     //192.168.1.10/DVD  /mnt/videoserv/DVD  cifs  \
         ro,noauto,guest,user=guest,sec=none,iocharset=utf8  0  0

You should test that you can mount the share now with:

     sudo mount /mnt/videoserv/DVD

If the mount does not succeed, you can usually find out what happened by doing:

     sudo dmesg | tail

Some other options that you may wish to consider for your fstab entry are:

     password=itsasecret,noserverinfo,file_mode=0555,dir_mode=0555

These specify the password for the user on the video server (if any), that the video server's inode numbers should not be used on the local system (the default, but it never hurts to specify the defaults), and the mode for files and directories (if the video server doesn't support the CIFS Unix extensions).

Once you are sure that the mount will work, edit /etc/rc.local to automatically mount the share, after everything is up and running (the mount cannot be done directly in fstab, since Samba will not be up and running when the mounts are done -- besides, this allows for the video server to be down and not stop the system from booting):

     sudo emacs /etc/rc.local
     /etc/rc.local

.

.

# Bring up the Samba shares, once everything is up and running. #
# Note that the same fracking geniuses who screwed up the way system tasks # are started apparently had a crack at rc.local too. It no longer waits # until all tasks have started before it runs. So, we must force an # artificial delay to allow the network to come up before we try the Samba # mounts.
sleep 10
mount /mnt/videoserv/DVD

         .
         .
         .

The share will come up mounted when next you reboot.

Note that, for MythVideo to work, all of the video files must be readable as part of the local filesystem. This means if you have a separate frontends and backends, they must all mount the directories themselves. Consequently, you must perform this step for each of your frontends/backends.

Also, since the full path names to all the videos are stored in the shared database, you must mount the video directories under exactly the same path on each of the systems that will view them. This restriction applies, even though you get to supply the list of directories (below, via the "Directories that hold videos" field). Perhaps the path names stored in the database should have been relative to the path names given in the "Directories that hold videos" field but, so far, this is not the case.

MythVideo Setup

From the MythTV frontend, choose Utilities/Setup from the main menu, then Setup, Media Settings, Videos Settings, and General Settings from the menu tree. Navigate to the first field named "Directories that hold videos". Here, you can enter your video directories as a colon separated list. You would typically use the directories that you mounted (see above) or a local directory. For example:

     /mnt/videoserv/DVD/sda:/mnt/videoserv/DVD/sdb

You should change the field named "Directory that holds movie posters" to point to the shared posters directory that you created on the video server. For example:

     /mnt/videoserv/DVD/posters

Under the field named "Default view", I prefer to pick "Listings".

On the second page, choose all of the items in the list. You may set "Video tree remembers last selected position" item to whatever your preference is. There is nothing that needs setting on pages 3 thru 7 but you must navigate through them all to save your choices.

Exit the setup screens, all the way back to top-level "Utilities/Setup" screen and then pick "Video Manager". You should see a list of all of the videos that are available in the directories that you set, above.

Scroll down to the first video and hit the memu button on your remote or the "M" key on the keyboard. A menu should pop up. Pick the "Manually Enter Video #" choice. A box will pop up that says, "Enter IMDB #".

Note that under Mythbuntu 9.04 (MythTV 0.21), the manual entering of IMDB numbers is broken because somebody made a typo when naming the IMDB menu. If it is broken, you will see the "Enter IMDB #" menu as soon as you fire up the Video Manager and you will not be able to enter IMDB numbers at any point. The fix is to run the following command from the command line, as root:

     find /usr/share/mythtv/themes/ -name "video-ui.xml" -print |
       xargs sed -i 's/enterimdb/entertmdb/g'

Or, if you didn't change the root password and are still using the sudo method to do all of your maintenance, try this:

     find /usr/share/mythtv/themes/ -name "video-ui.xml" -print |
       xargs sudo sed -i 's/enterimdb/entertmdb/g'

Note that there won't be any fixes for this problem for MythTV version 0.21, since the geeks have all moved on to yet another way of doing things that's way more better (Yeah, like we haven't heard that before) and they aren't interested in fixing the old stuff.

You will need to surf over to www.imdb.com on the Internet, using another computer and the Web browser. Look up the name of the movie in the search box and pick the correct movie from the search list (you're usually looking for the item that says "Media from ..."). The link to the movie will include a number that looks something like "tt0073906". You want the significant digits of that number. Enter the number (e.g. 73906) into the pop up box that says, "Enter IMDB #".

MythVideo will look up the appropriate movie poster for the movie, cache it in the directory chosen above and fill in the database with all of the relevant information about the movie (e.g. director, year, run time) from IMDB. When you browse through the movies later on, you'll see all of this info.

That's all there is to it. Set up all of the movies that you've loaded into the DVD repository in the same manner.

Finally, just in case you want to know more about MythVideo, you can find a comprehensive HowTo at: http://www.mythtv.org/wiki/index.php/MythVideo.

Adding Your Own MythVideo Metadata

Unfortunately, the Myth UI for the video metadata leaves a lot to be desired. You can only edit some of the data, not all of it. If you can find your movie in IMDB, most of the information is filled in automatically. However, if you can't find your movie in IMDB or its information is wrong or missing, you can't change it.

Not to fear. We'll hack the MySQL database directly. What fun. Begin by firming up the MySQL command processor:

     MySQL -uroot -pItsASecret mythconverg

The first thing to do is list the movie you're trying to update. You can try something like this:

     select * from videometadata where title like 'A%';

The above would show all movies beginning with the letter 'A', for example.

Once you find the movie you want to update, you can try the following:

     update videometadata set director='Joe Blow' where intid=nn;
     update videometadata set year=2009 where intid=nn;
     update videometadata set length=105 where intid=nn;
     update videometadata set coverfile='/mnt/videoserv/DVD/posters/MyPoster.jpg'
       where intid=nn;

The first example would be used to set the director's name. You can use multiple names, separated by commas but don't go nuts. The second example would set the movie release year to 2009. The third example would set the movie run time to 105 minutes. In all of the examples, nn is the actual internal ID that you determined by selecting the movie you're interested in (above).

And, the fourth example sets the cover file (which is displayed when you surf through the list of movies) to something of your choosing.

If IMDB doesn't have a cover for your movie (or you hate their choice), you can scan the cover of your legally-purchased copy of the DVD (you do have one of those, don't you) and turn it into a cover that MythVideo can use. Crop the scanned image so that it is roughly 3" wide and 4.5" high. Make sure the dots per inch are set to 72. Save it in medium resolution as a JPEG. The place to save it is the posters directory on your video server. Once you've done that, aim the metadata at the poster (still at the MySQL command prompt):

     update videometadata set coverfile='/mnt/videoserv/DVD/posters/BVSSexy.jpg'
       where intid=nn;

Here, we're aiming the cover file at our own version of the Buffy The Vampire Slayer cover, with the sexy (not for general consumption) image of S.M.G. and A.H. You can't get that off of IMDB.

If you want to hack other columns in the videometadata table, this gets you a list of all of the columns:

     show columns for videometadata;

You might want to look at what's already there before you start blasting. Oh, yeah. Before we start, let's (as Norm would say) talk about shop safety. Always wear safety glasses and ear protection, when blasting. And, always make a backup of the database beforehand. Otherwise, you may be looking at a blank screen where all you back episodes of Lost used to be. In other words, they will be truly lost. Whaaa!

Automatically Updating MythVideo Metadata

You can automatically update your MythVideo Metadata using the Perl script mythvideo-scanner.pl, which can be scheduled to run automatically, at regular intervals, by cron. This script makes a good faith effort to figure out all of the relevant Web sites that may have information associated with each of the video files in the MythVideo storage tree, and download it. The information is blended into a consistent metadata record which is written to the database. Information about actors is also added.

This script may be run on any machine that has a network connection to the master backend. It does not have to be run on the master backend itself. We prefer to run it on the video server instead of the master backend, since this allows us to mount the posters, artwork and/or banners directory (along with the MythVideo storage tree) as read-only on all of the Mythbuntu boxes that access the video server, thereby minimizing the chance of accidents.

Meanwhile, the metadata updating is done directly on the video server, where the posters, artwork and/or banners directories can be accessed directly, thereby allowing new posters, artwork, etc. to be downloaded and stored. This also offloads the MythVideo work to the video server, thus freeing the master backend to do other, recording-related work unimpeded.

Begin by downloading the mythvideo-scanner install file from:

     http://code.google.com/p/mythvideo-scanner/

Uncompress the install file:

     cd /rpm/mythvideo-scanner
     tar xzf mythvideo-scanner.3.1.tar.gz

To install the mythvideo-scanner, you can try the installing it via the makefile, like this:

     cd mythvideo-scanner
     make upgrade
     su
     make PREFIX=/usr install

We prefer putting it in our own directory, by hand, like this:

     su
     mkdir /usr/local/mythvideo
     mkdir /usr/local/mythvideo/modules
     mkdir /usr/local/mythvideo/grabbers
     cp modules/ /usr/local/mythvideo/modules/
     chmod u=rw,go=r /usr/local/mythvideo/modules/
     cp grabbers/ /usr/local/mythvideo/grabbers/
     chmod u=rw,go=r /usr/local/mythvideo/grabbers/
     cp .pl /usr/local/mythvideo
     chmod u=rwx,go=rx /usr/local/mythvideo/.pl

This allows code in the Perl scripts to set the current directory into the include directory list and always find the modules and grabbers, regardless of which version of Mythbuntu (or not) that you are using.

Make sure that you have all of the prerequisite Perl modules installed from CPAN. We have found (on CentOS) that all of the necessary modules were already installed except HTML::TreeBuilder and Text::Levenshtein. On Mythbuntu, many people have reported that Text::Levenshtein is the only module that needs to be installed. The full list of required modules is:

     File::Spec;
     Getopt::Long;
     HTML::Parser;
     HTML::TreeBuilder;
     HTML::Entities;
     LWP::Simple;
     LWP::UserAgent;
     Text::Levenshtein qw(distance);

You can install them like this, for example:

     su
     perl -MCPAN -e shell
     install HTML::TreeBuilder
     install Text::Levenshtein
     quit

If you won't be running mythvideo-scanner on the master backend or one of your Mythbuntu frontends, get a copy of the MythTV MySQL configuration text file from one of your Mythbuntu boxes. It is preferrable to use mysql.txt from a frontend, since it is a little closer to what we want to use for a system that will access the MythTV database remotely. We like to put it in the /etc/mythtv directory but you can do a find to see if it is already installed elsewhere. Here is a sample of a typical mysql.txt file:

/etc/mythtv/mysql.txt:

     # Database server host name (master backend).
     DBHostName=192.168.1.99
     # By default, Myth tries to ping the DB host to see if it exists.
     # If your DB host or network doesn't accept pings, set this to "no".
     #DBHostPing=no
     # Database connection information.
     DBUserName=mythtv
     DBName=mythconverg
     DBType=QMYSQL3
     DBPassword=123abc987

You might want to set the ownership and permissions of this file to root, read/write, so that it is free from prying eyes (it does contain your database password, after all), like this:

     su
     chown root:root /etc/mythtv/mysql.txt
     chmod u=rw,go= /etc/mythtv/mysql.txt

>>>>>>
add the host's info to the mythconverg prefs table. <<<<<<

You can now try running the mythvideo-scanner like this:

     /usr/local/mythvideo/mythvideo-scanner.pl --dryrun --status --verbose

If run gets an error like this:

     -bash: /usr/local/mythvideo/mythvideo-scanner.pl: /usr/bin/perl^M: bad
       interpreter: No such file or directory

You need to remove all of the carriage returns off the ends of the lines. This is easily accomplished with these commands:

     su
     cd /usr/local/mythvideo
     find . -type f -exec dos2unix -o \{\} \;

>>>>>>
You need to be superuser to run, if you removed permissions from the mysql.txt file

     /usr/local/mythvideo/mythvideo-scanner.pl --dryrun --verbose

<<<<<<

Downloading Podcasts

Audio programs (such as podcasts or streams) can be automatically captured and added to the MythTV music directory, where they can be played at your convenience. For podcasts, we can use a program called gPodder to periodically fetch the latest podcast of your favorite programs.

We'll begin by installing gPodder so that podcasts can be periodically captured. Information about how to download and install gPodder is found on the download page at:

     http://gpodder.org/downloads.html

However, downloading is not strictly necessary. For the latest versions of Mythbuntu, you can simply install gPodder in the usual manner with the package manager:

     sudo apt-get install gpodder

Even for earlier versions of Mythbuntu, the easiest way to install gPodder was to use the gPodder PPA from Launchpad:

     https://launchpad.net/~thp/+archive/gpodder

To install the PPA, proceed to the PPA's overview page in Launchpad and find and click the link that reads "Technical details about this PPA". Select your version of Ubuntu from the "Display sources.list entries for" dropdown list. Copy the lines that appear in the text box that look something like this:

     deb http://ppa.launchpad.net/thp/gpodder/ubuntu jaunty main
     deb-src http://ppa.launchpad.net/thp/gpodder/ubuntu jaunty main

Fire up your favorite text editor and edit the apt sources.list file. Add the lines that you copied to the bottom of the file:

/etc/apt/sources.list:

.

       .

deb http://ppa.launchpad.net/thp/gpodder/ubuntu jaunty main deb-src http://ppa.launchpad.net/thp/gpodder/ubuntu jaunty main

From the PPA's page, you'll find a signing key that looks something like:

     1024R/89617F48 (What is this?) 

Copy the portion after the slash and add it as one of the keys that apt can use to verify downloads:

     sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 89617F48

Ask apt to update the list of packages in the system's archive:

     sudo apt-get update

Now, you can install gPodder from the PPA:

     sudo apt-get install gpodder

Before you begin using gPodder, you may want to change the gPodder download folder to something that you prefer. For some versions of gPodder, you cannot change the download folder using gPodder's GUI (see bug 566), but you can always do so manually with the steps shown here.

Begin by shutting down gPodder, if it is running. Then, open the file ~/.config/gpodder/gpodder.conf (under the logged-in userid) with a text editor. Search for the line starting with "download_dir" and change the value to the directory you want:

~/.config/gpodder/gpodder.conf:

.

       .

download_dir = /Podcasts

Fire up gPodder from the GUI and add all of the feeds that you want to download. You can do this using URLs or via the gPodder search facilities. You may want to set the episode retention time for each feed, as you add them, or you can set the overall episode retention time from the Preferences menu. The default retention time is 7 days.

>>>>>>
Once you've installed gPodder and subscribed to all of the podcasts that you are interested in, you can automate the downloading of podcasts with this simple script (its more documentation than commands). Schedule it at regular intervals in your crontab:

     #!/bin/sh
     #
     # Shell script to update and download all podcasts that are subscribed to by
     # gPodder.
     #
     # This script should be scheduled out of crontab to run at regular intervals
     # sometime after the podcasts are scheduled to be available.  It will invoke
     # gPodder to update the list of podcasts which are currently available and
     # then invoke it again to download them.
     #
     # The reason for scheduling it at regular intervals is to spread out the
     # downloads over time so as to not overload the system at one particular
     # time.  Also, the podcasts are retrieved, throughout the day, as they
     # become available.  Note that the userid used to run this script should be
     # the one that is to be used to capture podcasts to the podcast directory.
     # For example:
     #
     #      30 1,8,10,14,16,19 * * *  mythuser  /my/scripts/PodcastUpdate
     #
     #
     # Where things are stored.
     #
     PodcastDir=/Podcasts
     ##############################################################################
     #
     # Update the podcast availability list and download the ones that are no
     # available.
     #
     /usr/bin/gpo update
     /usr/bin/gpo download

Older versions of gPodder maintained playlists for each podcast feed, if the "create_m3u_playlists" option was set to "True". With the later versions of gPodder, this feature has been dropped. <<<<<<

Note that the command line interface to gPodder doesn't do any episode cleanup. Consequently, you'll need to visit the GUI periodically to mark all of the episodes that have been downloaded as played and expire them according to the retention time you have chosen for each feed.

Capturing Audio Streams

Even if a podcast isn't available, an MP3 stream (or shoutcast) of the audio program may be available from one or more Internet radio sources. In that case, we can use a program called streamripper to capture the stream and turn it into the equivalent of a podcast. Alternately, for the popular Adobe Flash streams, we can use mplayer, the latest ffmpeg, and lame to capture them and turn them into an MP3 as well. A third option may be to copy the MP3 file directly from a fixed URL, where it is placed every day, at the same time.

Installing streamripper is even easier than installing gPodder (above), since it is available via the standard Ubuntu distribution mechanism:

     sudo apt-get install streamripper

To use streamripper, you need to find the actual MP3 stream source for the program that you wish to rip. You can often find a link to the source from the Web page of the broadcaster. A good starting point is the Public Radio Fan Web site, which lists many public radio broadcasters from around the world who broadcast on the Internet:

     http://www.publicradiofan.com/

To use the Web site, begin by choosing the "Set preferences" link from the lefthand menu of the home page. Choose "Time display preferences" and set your time zone. Then, choose "Audio format preferences". Deselect all types of streams except MP3 (streamripper only works with MP3 streams).

You can look for programs by choosing the "Schedule grid" link from the lefthand menu of the home page. Once on the schedule grid page, you can select what is displayed by clicking the "Change time interval and other grid options" link.

Peruse the listings to find the programs you’re interested in recording. Right click on the lightning-bolt icon (the Winamp logo) next to the program's source (you should see a URL ending with ".m3u" or ".pls") and choose “Save Link As...” to save the link to a temporary local file.

Open up the saved file and take a look at it. If it is a ".m3u" file, it will look something like this (example from CBC Radio 3):

     http://shoutcast1.cbcradio3.com/

If it is a ".pls" file, it will look something like this (example from CJRT Radio, JAZZ FM 91):

     [playlist]
     NumberOfEntries=1
     Title1=JAZZ.FM91 - Canada's Premier Jazz Station
     File1=http://streamerepsilon.jazz.fm:8000

Upon inspection, its pretty obvious what the URL to use for the source's streamcast is. Using the URL, you can now make up a streamripper command to capture the stream. Try this:

     streamripper http://shoutcast1.cbcradio3.com/ -a test.mp3 -s -l 120

You should get an mp3 file that contains a couple of minutes captured from the stream that you've chosen.

Quite a number of radio stations stream their broadcasts in real time using the Flash player format (flv) from Adobe. If you have a later version of Mythbuntu (e.g. 10.04), you can capture these streams with mplayer and the ffmpeg codec library libavformat. Note, however, that this doesn't work on earlier versions of Mythbuntu (e.g. 9.04) because the libavformat library doesn't support the "10" or "a" level of flv streams. If you see messages that look like this when you run mplayer, you're out of luck:

     libavformat file format detected.
     Stream not seekable!
     [flv @ 0x883ec08]Unsupported audio codec (a)

On earlier versions of Mythbuntu (e.g. 9.04), mplayer uses a built-in version of ffmpeg which cannot be replaced. Consequently, even if you upgrade ffmpeg or rebuild it from source, you won't be able to capture such streams because mplayer will still be using the old ffmpeg. On the 9.10 version of Mythbuntu, mplayer may just work or you may be able to upgrade the system's ffmpeg codec libraries such that mplayer will be able to capture the stream. On Mythbuntu 10.04 and up, it should just work.

There are notes at:

     http://ubuntuforums.org/showthread.php?t=1117283

Which describe how to upgrade your ffmpeg with the unstripped or extra libraries. It also points out how to compile ffmpeg, if you'd like to take that route, instead. This may come in handy the next time Adobe upgrades the Flash stream to level 11 or 12 or whatever. The whole ffmpeg story is at:

     http://www.ffmpeg.org/

Once you have a working version of mplayer, the basic method for capturing a Flash stream is simple. You run mplayer like this:

     mplayer http://123.234.2.3:80/WCMFFMAAC -ao pcm:file=/tmp/mpstream.wav \
       -vc dummy -vo null

This will create a wav file that lasts for as long as you let mplayer run.

The next step is to use lame to convert the wav file that is captured by mplayer into an MP3 file. This can be loaded into Myth or copied onto your portable MP3 player.

Normally, lame isn't installed on Mythbuntu so the first thing is to install it. Do this:

     sudo apt-get install lame

Answer the prompts and you're in business. That was easy.

The basic method for converting the wav file to MP3 is also pretty simple. You run lame like this:

     lame -m s /tmp/mpstream.wav -o /tmp/mpstream.mp3

After lame completes, you should have an MP3 file that can be played with any MP3 player (like vlc). If you wish, you can delete the wav file:

     rm -f /tmp/mpstream.wav

There is one more step that you may wish to take, although it isn't at all necessary. It is more like icing on the cake.

You can use the program id3v2 to add ID3, version 2 tags to the newly-created MP3 file so that any MP3 player that tries to play it will know what its all about. If you wish to take this step, you first need to install id3v2, since it isn't normally installed on Mythbuntu:

     sudo apt-get install id3v2

Once the install completes, you can use id3v2 to tag the MP3 file like this:

     id3v2 -a WCMF -A "WCMF Stream from 10 Aug 27 at 09:00" -g 78 \
       -t "WCMF Stream from 10 Aug 27 at 09:00" -T 1/1 -y 2010

You can just set the genre number to 255 (Podcast), if you don't actually care about the genre, or you list all of the genre numbers that you can use like this:

     id3v2 -L

Many of the available Flash audio streams are now supplied by a company called StreamTheWorld. This company is responsible for all of the online feeds of the various CBS Radio stations throughout the United States, for example. The feed URL used by StreamTheWorld is dynamic so that you cannot simply grab it once and use it forever. Instead, you need to go through the lookup process provided by their Web servers every time you which to capture one of the streams fed by StreamTheWorld.

Dan McGee has written a script that makes it a lot easier to play StreamTheWorld radio streams from the command line. You can find it at this URL:

     http://www.toofishes.net/blog/streamtheworld-streams-command-line/

We'll alter this script so that, instead of playing the stream directly, it simply outputs the dynamic URL where the stream can be found. This can then be used in a shell script to run mplayer and capture an hour or two of the stream at a time determined by a crontab entry. Here's the modified script:

streamtheworld.py:

     #!/usr/bin/env python
     from random import choice
     import os
     import sys
     import urllib2
     import xml.dom.minidom as minidom
     def validate_callsign(cs):
       '''
       Normal callsign format is 'WWWWFFAAA', where 'WWWW' is the radio station
       callsign, 'FF' is either 'AM' or 'FM', and 'AAA' is always 'AAC'.
       For this function, we expect the 'WWWWFF' part as input.
       '''
       if not cs or not isinstance(cs, str):
         raise ValueError('callsign \'%s\' is not a string.' % cs)
       if len(cs) < 6:
         raise ValueError('callsign \'%s\' is too short.' % cs)
       if not cs.endswith('AAC'):
         cs = cs + 'AAC'
       band = cs[-5:-3]
       if band != 'AM' and band != 'FM':
         raise ValueError('callsign \'%s\' is missing \'FM\' or \'AM\'.' % cs)
       return cs
     def make_request(callsign):
       host = 'playerservices.streamtheworld.com'
       req = urllib2.Request(
         'http://%s/api/livestream?version=1.2&mount=%s&lang=en' %
         (host, callsign))
       req.add_header('User-Agent', 'Mozilla/5.0')
       return req
     ## Example XML document we are parsing follows, as the minidom code is so
     ## beautiful to follow
     #
     #<?xml version="1.0" encoding="UTF-8" standalone="yes"?>        
     #<live_stream_config version="1" \
     #    xmlns="http://provisioning.streamtheworld.com/player/livestream-1.2">
     #  <mountpoints>
     #    <mountpoint>
     #      <status>
     #        <status-code>200</status-code>
     #        <status-message>OK</status-message>
     #      </status>
     #      <servers>
     #        <server sid="5203">
     #          <ip>77.67.109.167</ip>
     #          <ports>
     #            <port>80</port>
     #            <port>443</port>
     #            <port>3690</port>
     #          </ports>
     #        </server>
     #        <!-- multiple server elements usually present -->
     #      </servers>
     #      <mount>WXYTFMAAC</mount>
     #      <format>FLV</format>
     #      <bitrate>64000</bitrate>
     #      <authentication>0</authentication>
     #      <timeout>0</timeout>
     #    </mountpoint>
     #  </mountpoints>
     #</live_stream_config>
     def t(element):
       '''get the text of a DOM element'''
       return element.firstChild.data
     def check_status(ele):
       # should only be one status element inside a mountpoint
       status = ele.getElementsByTagName('status')[0]
       if t(status.getElementsByTagName('status-code')[0]) != '200':
         msg = t(status.getElementsByTagName('status-message')[0])
         raise Exception('Error locating stream: ' + msg)
     def create_stream_urls(srcfile):
       doc = minidom.parse(srcfile)
       mp = doc.getElementsByTagName('mountpoint')[0]
       check_status(mp)
       mt = t(mp.getElementsByTagName('mount')[0])
       allurls = []
       for s in mp.getElementsByTagName('server'):
         # a thing of beauty, right?
         ip = t(s.getElementsByTagName('ip')[0])
         ports = [t(p) for p in s.getElementsByTagName('port')]
         # yes, it is always HTTP. We see ports 80, 443, and 3690 usually
         urls = ['http://%s:%s/%s' % (ip, p, mt) for p in ports]
         allurls.extend(urls)
       return allurls
     if __name__ == '__main__':
       if len(sys.argv) < 2:
         print 'usage: station callsign must be the first argument'
         sys.exit(1)
     callsign = validate_callsign(sys.argv[1])
     req = make_request(callsign)
     result = urllib2.urlopen(req)
     urls = create_stream_urls(result)
     if len(urls) > 0:
       u = choice(urls)
       print u
       sys.exit(0)
     sys.exit(1)

Once you create the script, don't forget to give it execute permissions:

     chmod ugo+x streamtheworld.py

To test this script out, you can run it from the comand line like this:

     python streamtheworld.py WCMFFM

It will simply output the dynamic URL like this:

     http://208.80.52.50:443/WCMFFMAAC

For the next step, we'd like to be able to schedule a stream capture out of crontab and have it run for a predefined length of time (e.g. 1 hour). We can now do this with a simple, little shell script:

swcapture:

     #!/bin/bash
     # Get the stream URL and fire up mplayer in the background.
     StreamAddr=`python streamtheworld.py WCMFFM`
     mplayer $StreamAddr -ao pcm:file=/tmp/mpstream.wav -vc dummy -vo null \
         </dev/null >/dev/null 2>&1 &
     # Sleep for however long we want to capture the stream.
     sleep 30s
     # Kill the most recently backgrounded job.
     kill $!

Give this script execute permissions:

     chmod ugo+x swcapture

Now, we can run this script and it should capture 30 seconds worth of the stream in the /tmp directory:

     ./swcapture

Check it with:

     ls -l /tmp/mpsteam.wav

In order to have one stop shopping, we can combine everything into a single script that will: 1) directly copy MP3 files that have no RSS feed but are always in a fixed location (e.g. AIR News); 2) capture MP3 streams with streamripper; 3) capture flv streams from StreamTheWorld using mplayer and the steamtheworld script (above).

Here's a script that we use to capture AIR News, Jazz Decades, Morning Edition and Little Steven's Underground Garage (representing all three stream types). This capture script that can be added to your crontab to capture the audio streams of these programs at the appropriate times:

StreamCapture:

     #!/bin/sh
     #
     # Shell script to capture streamed radio broadcasts and save them as mp3
     # files.  This script can be used to create podcasts out of streams when
     # the radio station of interest doesn't offer a podcast, only a live
     # broadcast (e.g. NPR's Morning Edition).
     #
     # This script should be scheduled out of crontab to run at the appropriate
     # time, when the program is supposed to start.  Note that the userid used to
     # run this script sould be the one that is normally used to capture podcasts
     # to the regular podcast directory.  For example:
     #
     #      00 5 * * 1-5  mythuser  /my/scripts/StreamCapture MorningEdition
     #
     # In addition to capturing realtime streams, this script will retrieve mp3
     # files from download sites.  This can be used to assist sites that don't
     # offer an RSS feed but do offer downloadable files.  To use this feature,
     # schedule the script to run at some point after the download file normally
     # becomes available:
     #
     #      00 5 * * 1-5  mythuser  /my/scripts/StreamCapture AIRMiddayNews
     #
     # The list of programs that can be captured are:
     #
     #      AIRMiddayNews   - Downloads the Midday News from AIR.  Should be
     #                        scheduled to run sometime after 13:00 IST
     #                        (GMT+5:30), Monday thru Friday.
     #
     #      BigBandShow     - Records five hours of Glen Woodcock's Big Band Show
     #                        off of CJRT.  Should be scheduled to run at 17:00
     #                        EST (GMT-4:00) or EDT (GMT-5:00) on Sunday.
     #
     #      JazzDecades     - Records one hour of the late Raybo Smith's Jazz
     #                        Decades off of WGBH.  Should be scheduled to run
     #                        at 19:00 EST (GMT-4:00) or EDT (GMT-5:00) on Sunday,
     #                        as long as WGBH keeps rebroadcasting the old
     #                        episodes.
     #
     #      LittleSteven    - Records two hours of Little Steven's Underground
     #                        Garage, the weekly radio show of Steven Van Zandt
     #                        that plays rock 'n' roll and garage rock.  This
     #                        captures the WCMF FM flv stream from StreamTheWorld
     #                        and should be scheduled to run at 22:00 EST
     #                        (GMT-4:00) or EDT (GMT-5:00) on Sunday.
     #
     #                        Note that the streamtheworld.py helper script must
     #                        be installed at the location pointed to by the
     #                        SWHelper variable.
     #
     #      MorningEdition  - Records two hours of NPR's Morning Edition from
     #                        WBUR.  Should be scheduled to run at 05:00 EST
     #                        (GMT-4:00) or EDT (GMT-5:00), Monday thru Friday.
     #
     #
     # Where things are stored.
     #
     PodcastDir=/Podcasts
     SWHelper=/etc/podcast/streamtheworld.py
     #############################################################################
     BuildPlaylist()
     {
     #
     # Begin the playlist.
     #
     echo Build playlist for ${PodcastDir}/${1}
     echo "#EXTM3U" >${PodcastDir}/${1}.m3u
     #
     # Add all of the pod files in the target directory to the playlist.
     #
     OrigDir=`pwd`
     cd ${PodcastDir}/${1}
     for PodFile in `ls -t *.mp3`; do
         #
         # Get this file's date.
         #
         PodDate=`echo ${PodFile} | \
             /bin/grep -e "_[0-9]\{4\}_[0-9]\{2\}_[0-9]\{2\}" -o`
      PodYear=${PodDate%_[0-9][0-9][0-9][0-9]}
      PodYear=${PodYear}
      PodDate=${PodDate_[0-9][0-9][0-9][0-9]}
      PodMonth=${PodDate%_[0-9][0-9]}
      PodMonth=${PodMonth#_}
      PodMDay=${PodDate[0-9][0-9]}
      PodMDay=${PodMDay}
      PodWDay=`date -d ${PodYear}/${PodMonth}/${PodMDay} +%A`
      #
      # Pick up the title, if there is one.
      #
      if [ x"${2}" = x ]; then
          PodTitle=${1}
      else
          PodTitle=${2}
      fi
      #
      # Add the program and date info to the playlist.
      
      echo Adding "${PodFile} - ${PodYear}/${PodMonth}/${PodMDay} (${PodWDay})"
      echo "EXTINF:0,${PodTitle} - ${PodMDay}/${PodMonth}/${PodYear} \
          (${PodWDay})" \
          >>${PodcastDir}/${1}.m3u
      echo "${1}/${PodFile}" >>${PodcastDir}/${1}.m3u

done
#
# Put things back the way they used to was. #
cd ${OrigDir}
}

     #############################################################################
     #
     # Stupidity check.
     #
     if [ x"$1" = x ]; then
         echo Stream to capture not specified
         exit 1
     fi
     #
     # We need an air date and year, for tagging the MP3 file and possibly for
     # making up the stored file name.
     #
     AirDate=`date +%Y_%m_%d`
     AirYear=`date +%Y`
     #
     # Copy the Midday News from All India Radio.  Clean up the old broadcasts and
     # then build an up-to-date playlist.
     #
     if [ "$1" = AIRMiddayNews ]; then
         if [ ! -d ${PodcastDir}/AIRMiddayNews ]; then
             mkdir -p ${PodcastDir}/AIRMiddayNews
             chmod ug=rwx,o=rx ${PodcastDir}/AIRMiddayNews
         fi
         #
         # Use lftp to get the latest MP3 file.
         #
         /usr/bin/lftp -e "get -c -O ${PodcastDir}/AIRMiddayNews \
             \"/writereaddata/broadcast/English-Midday News-Bulletins-619.mp3\" \
             -o AIRMiddayNews_${AirDate}.mp3; quit" \
             http://www.newsonair.com
         #
         # Despite the fact that the pulled file is already an MP3, AIR doesn't
         # apply any tags so we'll tag it with the author, etc.
         #
         id3v2 -a "All India Radio" -A "AIR Midday News, ${AirDate}" \
             -g 255 -t "AIR Midday News, ${AirDate}" -T 1/1 -y $AirYear \
             ${PodcastDir}/AIRMiddayNews/AIRMiddayNews_${AirDate}.mp3
         #
         # Clean up the old files and build the playlist.
         #
         /usr/bin/find ${PodcastDir}/AIRMiddayNews/ -type f -mtime +7 \
             -exec rm -rf \{\} \;
         BuildPlaylist AIRMiddayNews "All India Radio - Midday News"
     fi
     #
     # Capture The Big Band Show from CJRT.  Clean up the old broadcasts and then
     # build an up-to-date playlist.
     #
     if [ "$1" = BigBandShow ]; then
         if [ ! -d ${PodcastDir}/BigBandShow ]; then
             mkdir -p ${PodcastDir}/BigBandShow
             chmod ug=rwx,o=rx ${PodcastDir}/BigBandShow
         fi
         #
         # Capture the stream with streamripper.
         #
         /usr/bin/streamripper http://streamerepsilon.jazz.fm:8000/ \
             -a ${PodcastDir}/BigBandShow/BigBandShow_%d.mp3 -s -l 18000 \
             -o always
         #
         # Tag the MP3 with the author, etc.
         #
         id3v2 -a "Glen Woodcock" -A "The Big Band Show, ${AirDate}" \
             -g 255 -t "The Big Band Show, ${AirDate}" -T 1/1 -y $AirYear \
             ${PodcastDir}/BigBandShow/BigBandShow_${AirDate}.mp3
         #
         # Clean up the old files and build the playlist.
         #
         rm -f ${PodcastDir}/BigBandShow/.cue
         /usr/bin/find ${PodcastDir}/BigBandShow/ -type f -mtime +31 \
             -exec rm -rf \{\} \;
         BuildPlaylist BigBandShow "Glen Woodcock - The Big Band Show"
     fi
     #
     # Capture Jazz Decades from WGBH.  Clean up the old broadcasts and then build
     # an up-to-date playlist.
     #
     if [ "$1" = JazzDecades ]; then
         if [ ! -d ${PodcastDir}/JazzDecades ]; then
             mkdir -p ${PodcastDir}/JazzDecades
             chmod ug=rwx,o=rx ${PodcastDir}/JazzDecades
         fi
         #
         # Capture the stream with streamripper.
         #
         /usr/bin/streamripper http://streams.wgbh.org:8000 \
             -a ${PodcastDir}/JazzDecades/JazzDecades_%d.mp3 -s -l 3600 -o always
         #
         # Tag the MP3 with the author, etc.
         #
         id3v2 -a "Ray Smith" -A "Jazz Decades, ${AirDate}" \
             -g 8 -t "Jazz Decades, ${AirDate}" -T 1/1 -y $AirYear \
             ${PodcastDir}/JazzDecades/JazzDecades_${AirDate}.mp3
         #
         # Clean up the old files and build the playlist.
         #
         rm -f ${PodcastDir}/JazzDecades/.cue
         /usr/bin/find ${PodcastDir}/JazzDecades/ -type f -mtime +730 \
             -exec rm -rf \{\} \;
         BuildPlaylist JazzDecades "Jazz Decades"
     fi
     #
     # Capture Little Steven's Underground Garage from WCMF FM.  Clean up the old
     # broadcasts and then build an up-to-date playlist.
     #
     if [ "$1" = LittleSteven ]; then
         if [ ! -d ${PodcastDir}/LittleSteven ]; then
             mkdir -p ${PodcastDir}/LittleSteven
             chmod ug=rwx,o=rx ${PodcastDir}/LittleSteven
         fi
         #
         # Get the stream URL and fire up mplayer in the background.
         #
         StreamAddr=`python $SWHelper WCMFFM`
         mplayer $StreamAddr -ao \
             pcm:file=${PodcastDir}/LittleSteven/LittleSteven_${AirDate}.wav \
             -vc dummy -vo null </dev/null >/dev/null 2>&1 &
         #
         # Sleep for the two hours while we capture the stream then kill the most
         # recently backgrounded job.
         #
         sleep 7200s
         kill $!
         #
         # Convert the file to an MP3 with lame.  Tag it with the author, etc.
         # Note that we cannot tag the MP3 file with the actual title because it
         # contains an apostrophe.  This fails so we leave it out.
         #
         lame -m s ${PodcastDir}/LittleSteven/LittleSteven_${AirDate}.wav \
             -o ${PodcastDir}/LittleSteven/LittleSteven_${AirDate}.mp3 \
             >/dev/null 2>&1
         id3v2 -a "Steven Van Zandt" \
             -A "Little Stevens Underground Garage, ${AirDate}" \
             -g 78 -t "Little Stevens Underground Garage, ${AirDate}" \
             -T 1/1 -y $AirYear \
             ${PodcastDir}/LittleSteven/LittleSteven_${AirDate}.mp3
         #
         # Clean up the old files and build the playlist.
         #
         rm -f ${PodcastDir}/LittleSteven/LittleSteven_${AirDate}.wav
         /usr/bin/find ${PodcastDir}/LittleSteven/ -type f -mtime +730 \
             -exec rm -rf \{\} \;
         BuildPlaylist LittleSteven "Little Steven's Underground Garage"
     fi
     #
     # Capture Morining Edition from WBUR.  Clean up the old broadcasts and then
     # build an up-to-date playlist.
     #
     if [ "$1" = MorningEdition ]; then
         if [ ! -d ${PodcastDir}/MorningEdition ]; then
             mkdir -p ${PodcastDir}/MorningEdition
             chmod ug=rwx,o=rx ${PodcastDir}/MorningEdition
         fi
         #
         # Capture the stream with streamripper.
         #
         /usr/bin/streamripper http://wbur-sc.streamguys.com:80/ \
             -a ${PodcastDir}/MorningEdition/MorningEdition_%d.mp3 -s -l 7200 \
             -o always
         #
         # Tag the MP3 with the author, etc.
         #
         id3v2 -a "National Public Radio" -A "NPR Morning Edition, ${AirDate}" \
             -g 255 -t "NPR Morning Edition, ${AirDate}" -T 1/1 -y $AirYear \
             ${PodcastDir}/MorningEdition/MorningEdition_${AirDate}.mp3
         #
         # Clean up the old files and build the playlist.
         #
         rm -f ${PodcastDir}/MorningEdition/.cue
         /usr/bin/find ${PodcastDir}/MorningEdition/ -type f -mtime +7 \
             -exec rm -rf \{\} \;
         BuildPlaylist MorningEdition "National Public Radio - Morning Edition"
     fi

MythNetTV

>>>>>>
MythNetTV is an add-on program that uses RSS to download video podcasts (vodcasts), webtv
broadcasts and movie trailers to a local storage directory on your Myth box, whereupon it updates the database such that the downloaded videos end up as recordings on the Watch Recordings page. You can then watch them as if they had be recorded by MythBackend. You can subscribe to any video feed that you want, provided its format is supported.

Note that MythNetTV is a command-line-only program which works but is somewhat difficult to use with subscriptions such as the TED Talks, where a lot of video podcasts appear in the RSS feed. If you like a GUI or want to pick and choose what you get, you might want to consider Miro and MiroBridge (see below), instead. But, beware that MiroBridge does not work on Myth 0.21 (e.g. Mythbuntu 9.04) and it does suffer from dain bramage of its own. On the other hand, it is probably the wave of the future so take that into consideration, if you care.
<<<<<<

MythNetTV can be downloaded from the Mythbuntu repository and istalled as follows (here, we are using /var/lib/mythtv/mythnettv as the storage directory):

>>>>>>

     sudo apt-get install mythnettv
     sudo mkdir /var/lib/mythtv/mythnettv
     sudo chown mythtv:mythtv /var/lib/mythtv/mythnettv
     sudo chmod g+ws /var/lib/mythtv/mythnettv
     mythnettv --datadir=/var/lib/mythtv/mythnettv

<<<<<<

If you'll be downloading programs via bittorrent, you will also need to install bittornado, which you can do as follows:

     sudo apt-get install bittornado

On the other hand, if you are planning to just download regular vodcasts that consist of MP4 or x264 files, and the like, you don't need to install bittornado at all. MythNetTV will work perfectly fine without it.

Before subscribing to any feeds, you may want to set up a storage group on the Mythbuntu machine where you'll run MythNetTV. This allows you to direct where MythNetTV places the downloaded vodcasts and programs, instead of just letting it pick the first directory it finds under the "Default" storage group (the concept of "first" that MythNetTV has may not be the same concept that you have).

If you want to do this, set up a "MythNetTV" storage group on the machine where MythNetTV will be run. You can do this from the MythTV backend setup application (mythtv-setup) that can be run from the desktop System menu. The new storage group is added from the Storage Groups menu of this application.

You can subscribe to a feed in this manner (here, we subscribe to the TED Talks):

     mythnettv subscribe "http://feeds.feedburner.com/TedtalksHD?format=xml" \
       "TEDTalks"

Note that the name you use to subscribe to the feed should not include any spaces (despite its being quoted) or it will break things. For example, do not be tempted to call your subscription "TED Talks".

Once you've subscribed to one or more feeds, you can update the list and download the content like this:

     mythnettv update
     mythnettv download 1 "TEDTalks"

The default action upon download is to queue a commercial flagging job for all of the downloaded material (one job per vodcast). If you'd rather not have this done (i.e. most vodcasts don't have commercials), you can run the download like this:

     mythnettv --nocommflag download 1 "TEDTalks"

If you subscribe to a new feed, there may be lots of older items in the feed and you may not want to see all of them. If that's the case, you can review each of them and mark them as already downloaded (so that they won't be downloaded again) with this command:

     mythnettv markread 1000 "TEDTalks"

You'll be prompted for each item that is currently in the feed which has not yet been downloaded. If you answer "yes" to the question, it will be marked as downloaded. If you answer "no" to the question, it will be left in the queue for downloading. Alternately, you can try turning them all off with this SQL command:

     update mythnettv_programs set download_finished=1, imported=1 \
       where title='TEDTalks'

When you're happy with the results, you can automate things by putting the update and download into your cron table at some suitable time in the middle of the night (say 02:00).

After the feeds are downloaded, you can surf over to the Watch Recordings page and you should see them all there. For example, the TED talks should appear in the list under "TEDTalks".

Here is a list of some useful RSS feeds:

     ABC News          http://abcnews.go.com/Site/page?id=3520115 (select feed
                         from list)
     ABC US News       http://feeds.abcnews.com/abcnews/usvideos
     ABC World News    http://feeds.abcnews.com/abcnews/internationalvideos
     ABC Tech News     http://feeds.abcnews.com/abcnews/technologyvideos
     ABC 7:30 Report   http://www.abc.net.au/7.30/xml/730_vodcast_m4v.xml
     ABC Lateline      http://www.abc.net.au/lateline/xml/ll_vodcast.xml
     Ben Heck Show     http://revision3.com/tbhs/feed/MP4-hd30
     CBC National      http://www.cbc.ca/podcasting/includes/\
                         thenational-video-podcast.xml
     Chandra in HD     http://chandra.harvard.edu/resources/podcasts/hd/\
                         podcasts.xml
     CNET (RSS home)   http://www.cnet.com/podcasts/
     CNET Always On (HD)  http://feeds.feedburner.com/AlwaysOnhd?format=xml
     CNET News (HD)    http://feeds.feedburner.com/cnet/cnetnewshd?format=xml
     CNET Update (HD)  http://feeds.feedburner.com/CNETUpdateHD?format=xml
     CNET Podcasts     http://feeds2.feedburner.com/cnet/allhdpodcast?format=xml
     CNN Daily         http://rss.cnn.com/services/podcasting/cnnnewsroom/rss.xml
     Discovery News    http://feeds.feedburner.com/DiscoveryNews-Top-Stories?\
                         format=xml
     ESOcast           http://feeds.feedburner.com/ESOcast?format=xml
     Frontline World   http://feeds.pbs.org/pbs/frontlineworld
     GeekBeat          http://revision3.com/geekbeattv/feed/MP4-hd30
     Hidden Universe   http://www.spitzer.caltech.edu/resource_list/\
                         6-Hidden-Universe-NASA-s-Spitzer-Space-Telescope?\
                         def=hi&format=xml
     Hubblecast        http://feeds.feedburner.com/hubblecast?format=xml
     i on NIH          http://www.nih.gov/news/vodcast/nihvodcast.xml
     NASAcast          http://www.nasa.gov/rss/NASAcast_vodcast.rss
     Nova              http://feeds.pbs.org/pbs/wgbh/nova-video
     PBS Podcasts      http://www.pbs.org/podcasts/ (select feed from list)
     Philharmoia       http://www.philharmonia.co.uk/thesoundexchange/projects/\
                         podcasts/podcast.xml
     Reuters           http://www.reuters.com/tools/rss (select feed from list)
     Reuters Business  http://feeds.reuters.com/reuters/USVideoBusiness?format=xml
     Reuters Tech      http://feeds.reuters.com/reuters/USVideoTechnology?\
                         format=xml
     Reuters Top News  http://feeds.reuters.com/reuters/USVideoTopNews?format=xml
     Revision 3 shows  http://revision3.com/shows
     Scam School       http://revision3.com/scamschool/feed/MP4-hd30
     Royal Society     http://downloads.royalsociety.org/rss/video.xml
     TED Talks         http://feeds.feedburner.com/TedtalksHD?format=xml
     Wood Whisperer    http://feeds.feedburner.com/TheWoodWhisperer?format=xml

If you ever want to see what feeds you are subscribed to, you can use this command:

     mythnettv list

To unsubscribe from from a feed, you can use the unsubscribe command, like this:

     mythnettv unsubscribe "http://feeds.feedburner.com/TedtalksHD?format=xml" \
       "TEDTalks"

However, this simply marks the feed as inactive, in the MySQL database, and marks all of the files in the feed's list as downloaded. If you really want to purge things from the database, after doing the unsubscribe command, these SQL commands should work:

     delete from mythnettv_programs where title='TEDTalks';
     delete from mythnettv_subscriptions where title='TEDTalks';

Also note that, if you add a feed with a URL that gets an error (the error will only show up once you do "mythnettv update"), the feed will be marked inactive and you will not be able to unsubscribe from it. This will be too baddy, if you then try to add the feed with the correct URL. To fix this up, you'll want to delete the feed with this SQL command:

     delete from mythnettv_programs where title='BadFeed';

To automate downloading of vodcasts in the feeds that you've subscribed to with MythNetTV, you can create a script that can be run at regular intervals and schedule it to do so in crontab:

     #!/bin/sh
     #
     # Shell script to download video podcasts (vodcasts) and load them into
     # MythTV.  This script works in conjunction with vodcasts that are
     # subscribed to by MythNetTV.
     #
     # This script should be scheduled out of crontab to run at the appropriate
     # time, when the vodcasts are supposed to be available.  For some vodcasts
     # (e.g. the large ones) you may want to schedule them at off-peak times.
     # The names of one or more vodcast subscriptions, that are to be downloaded,
     # may be passed on the command line to control what is downloaded.  If no
     # name is passed all available subscribed vodcasts will be downloaded.  This
     # mode can be used at the off-peak time to sweep up everything that didn't
     # get downloaded (for whatever reason) in prior downloads.
     #
     # Note that the userid used to run this script, by cron, should be the one
     # that is normally used to run MythTV.  This is because the vodcasts will be
     # loaded into the Myth storage directory with this userid and the use of the
     # wrong userid will prevent MythTV from being able to delete the video file,
     # when the user asks to delete it.  An example of some typical cron entries
     # might be:
     #
     #      00 10 * * 1-5  mythuser  /my/scripts/VodcastUpdate ABCReport
     #      00 15 * * *    mythuser  /my/scripts/VodcastUpdate GeekBeat CNETNews
     #      00 19 * * 1-5  mythuser  /my/scripts/VodcastUpdate CBCNational
     #      30 2  * * *    mythuser  /my/scripts/VodcastUpdate
     #
     # The list of programs that can be captured are any that you have previously
     # subscribed to with "mythnettv subscribe".  The program names are the
     # actual titles that you used to do the subscribe.
     #
     #
     # Where MythNetTV can be found.
     #
     MythNetTV=/usr/bin/mythnettv
     #
     # Where things are stored.
     #
     PodcastDir=/Podcasts
     #############################################################################
     #
     # See if we should just download everything.
     #
     # MythNetTV craps out if we don't tell it how many vodcasts to download.
     # Hopefully, 1000 should do it.  If that's not enough, the link will
     # probably croak from the load, anyway.  So, 1000 is probably a good
     # thing (tm).
     #
     if [ x"$1" = x ]; then
         echo Downloading the whole enchilada
         $MythNetTV update
         $MythNetTV --nocommflag download 1000
         exit 0
     fi
     #
     # Download all of the titles that we were asked to do.
     #
     while [ "$1" ]; do
         echo Downloading only $1
         $MythNetTV update "$1"
         $MythNetTV --nocommflag download 1000 "$1"
         shift
     done

Miro

Video programs (such as vodcasts) can be automatically captured and added to the MythTV recordings directory, where they can be played at your convenience, using a program called miro to periodically fetch the latest vodcast or torrent of your favorite programs. But, beware that Miro (or more specifically mirobridge) will only work with Mythbuntu 9.10 or greater, although it does appear to be the direction video downloading will take in the future (there's a plug-in for mirobridge built in to the 10.04 Mythbuntu setup menu, for example).

We'll begin by installing miro so that podcasts/torrents can be downloaded. Information about how to download and install it is found on the download page at:

     http://www.getmiro.com/download/

However, downloading is not strictly necessary. The easiest way to install miro under Mythbuntu is to use the miro PPA from Launchpad:

     https://launchpad.net/~pcf/+archive/miro-releases

To install the PPA, proceed to the PPA's overview page in Launchpad and find and click the link that reads "Technical details about this PPA". Select your version of Ubuntu from the "Display sources.list entries for" dropdown list. Copy the lines that appear in the text box that look something like this:

     deb http://ppa.launchpad.net/pcf/miro-releases/ubuntu lucid main
     deb-src http://ppa.launchpad.net/pcf/miro-releases/ubuntu lucid main

Fire up your favorite text editor and edit the apt sources.list file. Add the lines that you copied to the bottom of the file:

/etc/apt/sources.list:

.

       .

deb http://ppa.launchpad.net/pcf/miro-releases/ubuntu lucid main deb-src http://ppa.launchpad.net/pcf/miro-releases/ubuntu lucid main

From the PPA's page, you'll find a signing key that looks something like:

     1024R/2D75E850 (What is this?) 

Copy the portion after the slash and add it as one of the keys that apt can use to verify downloads:

     sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 2D75E850

Ask apt to update the list of packages in the system's archive:

     sudo apt-get update

Now, you can install miro from the PPA:

     sudo apt-get install miro

There are a some formats such as certain Windows formats, Real Player, and Apple Quicktime which do not have native codecs under Linux. To work around this issue, external binary codecs that can be used to play these formats are obtained by Medibuntu from the MPlayer website, codecs directory (located at http://www.mplayerhq.hu/MPlayer/releases/codecs/) and distributed in the non-free component of the Medibuntu repository.

If you wish to download and play these formats, you may want to install the optional codecs package from the Medibuntu repository. Note that there is no PPA for this repository since the rules of PPA prohibit the inclusion of non-free code in any repository. Hence, you'll have to do the install directly:

     For i386, the package is called w32codecs:
     wget -c http://packages.medibuntu.org/pool/non-free/w/w32codecs/\
       w32codecs_20071007-0medibuntu2.1_i386.deb
     sudo dpkg -i w32codecs_20071007-0medibuntu2.1_i386.deb
     For amd64, the package is called w64codecs:
     wget -c http://packages.medibuntu.org/pool/non-free/w/w64codecs/\
       w64codecs_20071007-0medibuntu1_amd64.deb
     sudo dpkg -i w64codecs_20071007-0medibuntu1_amd64.deb

>>>>>>
<<<<<<