NOTE: SIGNIFICANT CHANGES HAVE BEEN MADE TO HOW FIREWIRE IS HANDLED IN THE NEW UBUNTU/MYTHBUNTU VERSION .21 MYTHTV PACKAGES INCLUDED IN MYTHBUNTU 8.04 AND BACKPORTS. THE INFORMATION IN THIS GUIDE IS BEING REVISED AND IS ** NOT ** ENTIRELY ACCURATE FOR .21 AS MANY STEPS ARE NO LONGER REQUIRED. INFORMATION REMAINS ACCURATE FOR OLDER (V.20) MYTHTV PACKAGES AS OF 9 April 2008. THIS NOTICE WILL BE REMOVED WHEN THIS GUIDE IS ACCURATE FOR ALL VERSIONS.

Watching and Recording Cable TV over Firewire

MythTV can interface with a number of firewire-enabled set-top boxes (STB), including Motorola and the Scientific Atlanta brand STBs. A firewire connection will allow you to directly interface with your STB via a firewire cable to receive the mpeg2 transport stream and change the channels.

Note that you will not have direct access to any pay-per-view or special content, encrypted channels or content that is recorded and stored on the STB- only the live TV stream from the STB tuner. For further information, see: Firewire Notes

Notes on Terminal and Editing:

  • The examples here use Gedit when editing files, but you can feel free to use the editor of your preference.
  • Unless otherwise specified, all terminal actions are assumed to take place in the user's home directory and the user is assumed to have sudo ability.

MythTV version .21

Tuning and recording from firewire has been greatly simplified starting with Ubuntu/mythbuntu 8.04 and the MythTV .21 packages. Most of the tedious steps previously required- such as permissions, determining port, node and priming method, etc.- are now taken care of automatically. Very little, if any, user intervention should be required once the firewire tuner is properly configured in mythtv-setup.

mythprime

Firewire priming functions are now handled by a single primer, mythprime, which is installed by default. Significant changes and enhancements have been made, in order to simplify mythbuntu firewire to the greatest possible extent.

Features of mythprime include:

  • powers on the STB before attempting priming
  • no longer requires port and node options
  • supports multiple firewire cards with multiple connections
  • supports multiple STBs
  • automatic detection of all devices on the firewire bus
  • primes only STBs and ignores non-STB devices
  • includes both broadcast and p2p priming functions
  • makes multiple attempts at priming upon failure of a single STB or multiple STBs, should any fail to prime
  • added verbose mode (-v) for detailed output to help troubleshoot priming and connection issues

mythprime is still beta, as it has not been widely tested with non-Motorola STBs. As changes are made, the most current binaries for mythprime will always be posted here for downloading. You can check to make sure you are running the most current version by:

$ mythprime -V

(Note that this is a capital V. A lowercase v will run mythprime in verbose mode and interrupt recordings!)

This will only return the version number and will not run the priming functions, so you can check it at any time with no concern of interrupting a recording. If no version number is returned, you are running a very old version of mythprime and should upgrade immediately.

Unless you are experiencing firewire issues, it is not necessary to always be running the most current version. However, it is a good idea to check the included changelog to see if any critical bugs have been fixed or if additions have been made that might benefit your system.

to be continued...

mythprime binaries

Current mythprime version .55b

Download the binary appropriate for your system. Open a terminal and change directory to the location of the downloaded file.

For safety, make a backup of your current mythprime:

$ cp /usr/bin/mythprime mythprime.bak

Then, copy (as sudo) the downloaded binary to /usr/bin/ (changing its name to mythprime in the process) and then make sure it is executable, in case permissions might have changed during download:

$ sudo cp <binary.name> /usr/bin/mythprime
$ sudo chmod a+x /usr/bin/mythprime

For example, for the i386 version, the command would be:

$ sudo cp mythprime.i386 /usr/bin/mythprime
$ sudo chmod a+x /usr/bin/mythprime

The latest version should now be installed. You can double check it to be sure:

$ mythprime -V

If for some reason you need to restore your backed-up mythprime, you can do so by:

$ sudo cp mythprime.bak /usr/bin/mythprime

Testing mythprime

including the possibility of needing a channel changer

to be continued...

Configuring MythTV .21

to be continued...

Editing the Backend Init Script

Since mythprime is currently beta, a conditional check exists in the MythTV backend init script as a temporary safeguard. Until mythprime is validated as stable and a permanent change is made, you will need to edit the backend init script to remove the conditional check or mythprime will not run.

To make the needed changes:

$ sudo gedit /etc/init.d/mythtv-backend

very near the top, you will see the prime_firewire() function:

prime_firewire()
{
    if [ "$ENABLE_FIREWIRE" = "TRUE" ]; then
        log_daemon_msg "Priming Firewire "
        su - $USER -c "/usr/bin/mythprime"
        log_end_msg $?
    fi
}

Remove the conditional check entirely, so it looks like this:

prime_firewire()
{
        log_daemon_msg "Priming Firewire "
        su - $USER -c "/usr/bin/mythprime"
        log_end_msg $?
}

For the change to take effect, you need to restart the backend server:

$ sudo /etc/init.d/mythtv-backend restart

to be continued...

MythTV version .20

The information from here forward is relevant only to MythTV versions .20 and earlier.

Check Out Your Connection

If your STB has more than one firewire port, you need to determine if both are active. The original author's 62xx STB has two ports, but only one is active- the port on the right, as you look at it from the back.

NOTE: It is a good idea to have the computer powered off when connecting/disconnecting the firewire cable between the computer and STB. There is no harm of damage- but hot-plugging the cable resulted in unstable connections during testing.

After connecting the firewire cable between the computer and STB, make sure there are no other firewire devices connected, power on and open a terminal. First, check to see if there's a good connection:

$ sudo plugreport
  • Note: if plugreport is not installed, do:
    • $ sudo apt-get install libiec61883-dev

If you have a good connection, you will see something like this:

  • Host Adapter 0
    ==============
    
    Node 0 GUID 0xf4bff0b7b7f0bff4
    ------------------------------
    libiec61883 error: error reading oMPR
    libiec61883 error: error reading iMPR
    
    Node 1 GUID 0x000e5cfffed64625
    ------------------------------
    oMPR n_plugs=1, data_rate=2, bcast_channel=63
    oPCR[0] online=1, bcast_connection=0, n_p2p_connections=0
            channel=1, data_rate=1, overhead_id=0, payload=376
    iMPR n_plugs=0, data_rate=2'''
    
    Node 2 GUID 0x0090e6051800238f
    ------------------------------
    libiec61883 error: error reading oMPR
    libiec61883 error: error reading iMPR

This shows an adapter with 3 nodes, of which one- Adapter (port) 0, Node 1- is active. Your connection may be on a different port and/or or node; just make note of it. All instructions in this guide will work with the examples port 0 and node 1, so be sure to substitute your port and node where necessary.

If you do not see an active connection and you have another port on the STB, (power down) switch the cable and try that one.

On the 62xx STB, you can check for an active connection through the diagnostic mode. Make sure the firewire cable is connected and power on the STB and the TV attached to it. Press the Power button to power off the STB and then quickly press and hold OK/SELECT on the STB remote. A diagnostic screen will appear. Using the STB remote, arrow-down to D11 Interface Status" and press OK. There you will see the status of the firewire port (labeled "1394 ports") and whether or not it is active ("1"). If it shows "0", power the computer down, switch the firewire cable to the other port on the STB and try it again.

To exit the diagnostic screen, power off the STB.

If you still can't get an active connection, contact customer service of your cable service provider and complain- if you are in the US, the law requires the port be active!

firewire_tester.c

MythTV can communicate with the STB using one of two protocols: broadcast or point-to-point (p2p). There does not seem to be a guarantee of which protocol the 62xx STBs prefer- they have been reported as working with both broadcast and p2p, others one and not the other. The SAxx STBs work p2p.

It is best to test to determine the connection your STB prefers. To begin, get any dependencies you may not have:

$ sudo apt-get install build-essential libraw1394-dev libiec61883-dev wget

Next,you need the source code for the excellent firewire tester written by Jim Westfall:

$ wget  "http://cvs.mythtv.org/trac/browser/trunk/mythtv/contrib/development/firewire_tester/firewire_tester.c?format=txt" -O firewire_tester.c

then compile it:

$ gcc -Wall -o firewire_tester firewire_tester.c -liec61883 -lraw1394

When the compile is finished, try out a p2p connection. Substitute your port for -P 0 and node for -n 1 if necessary:

$ sudo ./firewire_tester -p -P 0 -n 1 -r 5
  • Action: Test P2P connection 5 times, node 0, channel 0
    P2P: Testing...Failed
    P2P: Testing...Failed
    P2P: Testing...Success, 42 packets received
    P2P: Testing...Success, 96 packets received
    P2P: Testing...Failed

In this example, only 2 out of 5 p2p connections succeeded, which is not good. If you got 3 or more good connections, run the same command a few more times. If you consistently get 3 or more good connections out of 5, then p2p is probably a good option- try substituting -r 15 to see how many consecutive good connections you can get out of 15 tries. If you get 6 or more consecutive good connections, p2p is likely a good option.

If p2p didn't work so well for you, try to stabilize a broadcast connection using the B option:

$ sudo ./firewire_tester -B -P 0 -n 1
  • Action: Attempt to fix broadcast connection 1 times, node 1
    Broadcast: Testing...Failed
    P2P: Testing...Failed
    P2P: Testing...Success, 70 packets received
    Broadcast: Testing...Failed
    P2P: Testing...Failed
    P2P: Testing...Failed
    P2P: Testing...Success, 66 packets received
    Broadcast: Testing...Success, 102 packets
    Broadcast: Testing...Success, 60 packets
    Broadcast: Testing...Success, 42 packets
    Broadcast: Testing...Success, 96 packets
    Broadcast: Testing...Success, 108 packets
    Broadcast Fix: Success

This seems to have stabilized a broadcast connection, so test it a few more times:

$ sudo ./firewire_tester -b -P 0 -n 1 -r 5
  • Action: Test broadcast 5 times, node  1, channel 63
    Broadcast: Testing...Success, 58 packets
    Broadcast: Testing...Success, 116 packets
    Broadcast: Testing...Success, 36 packets
    Broadcast: Testing...Success, 72 packets
    Broadcast: Testing...Success, 102 packets

From this test, I would choose a broadcast connection, as it seems the most stable. You should run a number of p2p, broadcast fix and broadcast tests to help you determine which one is most suitable.

MythTV Configuration

If you are in the process of installing MythTV, you now need to return to the setup guide and continue the installation and configuration. When you come to the step where you set up capture cards, you can either follow the link back here or print this page for the correct settings.

If you are adding firewire capability to an existing MythTV installation, you need to run mythtv-setup and add a firewire capture card and configure it.

Adding Firewire Capture

fwcapcard2_2.png

Card Type: Firewire cable box

Select the model of your box from the drop-down lists- if your STB is not on the list, you can try an existing setting or select Other.

Connection Type should be set to broadcast or p2p; and Port and Node should reflect the results of your testing.

Speed: The 62xx series STBs are confirmed to work at 100 and 200Mbps- 200 is a safe setting. The SAxx STBs are confirmed to work at 200 and 400Mbps.

Default type is always MPEG2TS and is not changeable.

AFTER you have completed step 3 of mythtv-setup and added your video sources, you can complete step 4. Select the firewire capture card you just added and then connect and configure the source:

connectsource2_2.png

Display Name: give this input an easily-identifiable name such as dTV, Firewire, etc.

Video Source: this should be the name you gave your video source in step 3 of mythtv-setup

External channel change command: Enter the name of an external channel changer if you are using one. If you are using the 62xx or SAxx STB the channel changer is built-in and you can leave this blank.

Preset tuner to: unless you have an additional tuner connected to the STB or another firewire-capable recorder, leave this blank.

Scan for channels does not work for firewire connections. Select Fetch channels from listing source to retrieve the list of your configured channels from your service provider- this may take a minute or few... be patient!

Starting Channel: is the initial channel MythTV will tune the STB to when it starts for the first time. It is very important that you set this to a known good, unencrypted channel or starting the backend for the first time will fail. If you are unsure, set this to the channel number of a local station.

Input Priority: If you have multiple tuners, you can give one tuner priority over the other. If firewire is your only tuner, leave this set to 0. If you have other tuners and want to set priorities, you need to determine this setting for yourself. Setting this incorrectly can lead to missed recordings, so be careful if you don't know what you are doing! (Leaving it set to zero hurts nothing.)

If you are adding firewire to an existing server setup, skip forward to Init Script and Firewire Primers.

If this is a new installation, complete channel editing in step 5 if necessary.

Upon exit from mythtv-setup, you will given an instruction to fill the database with channel and program information-- It is critical to do this now:

$ mythfilldatabase

Depending on the number of channels in your profile, the speed of your internet connection and the time of day, it might take a few minutes to fill; so go grab a drink or a sandwich or something.

Once the database has filled, it will complain about the backend not being found running- ignore this and continue...

Init Script and Firewire Primers

Now that you have installed MythTV, you can focus on making sure that you will have a reliable firewire connection every time you start MythTV. You will need to make a few changes to your MythTV init script, /etc/init.d/mythtv-backend, and also add a primer for it to call before it starts the backend server. This guide will take you step-by-step through the process. The complete init script and primers are available for downloading at the end of this guide for the faint of heart- or to help you troubleshoot if you think you might have made a mistake and are unable to find it.

You are discouraged from downloading and using these files without taking the time to follow along with this guide-- there are changes that may need to be made to them. They are not to be considered out-of-the-box functional.

When you ran the firewire_tester earlier, you no doubt noticed that it can be a bit of a trick to establish a reliable firewire connection. Each STB has its own idiosyncrasies, even among the same models. You might need to experiment a little with the following scripts to get the best configuration for your STB. Both of the firewire primers presented here have proven effective on the STBs they were developed for and are clearly commented in the sections you may need to tweak- so feel free to play with the settings for the best result.

You will also add facilities for writing the results of the new functions to the MythTV backend log for troubleshooting and sake of completeness.

Now, stop the backend server:

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

Add Firewire Ownership to MythTV Init Script

The first thing you need to do is to give the firewire ownership to MythTV when it starts. By default, firewire is "owned" by root- which is why you had to sudo when using firewire_tester. MythTV also needs permission to access it- and for best results- own it. Like anything Linux, there are any number of ways this can be accomplished. The one presented here is the preferred method of the author, as it proved to remain the most stable during testing of different methods- you may choose to use a different method later.

To edit the MythTV's init script, open it in the editor of your choice:

$ gksudo gedit /etc/init.d/mythtv-backend

At the head of the file, look for this:

  • PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    DAEMON=/usr/bin/mythbackend
    NAME="mythbackend"
    DESC="MythTV server"

and add this after it:

FIREWIRE=/dev/raw1394                   # the firewire access
STAMP=$(/bin/date +%F\ %T)              # time stamp for mythtv log
MLOG=/var/log/mythtv/mythbackend.log    # the log itself

so that the result is:

  • PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    DAEMON=/usr/bin/mythbackend
    NAME="mythbackend"
    DESC="MythTV server"
    
    FIREWIRE=/dev/raw1394                   # the firewire access
    STAMP=$(/bin/date +%F\ %T)              # time stamp for mythtv log
    MLOG=/var/log/mythtv/mythbackend.log    # the log itself

In the next block of the script:

  • test -x $DAEMON || exit 0
    set -e
    
    USER=mythtv
    RUNDIR=/var/run/mythtv
    ARGS="--daemon --logfile /var/log/mythtv/mythbackend.log --pidfile $RUNDIR/$NAME.pid"
    EXTRA_ARGS=""
    NICE=0

the set-e interferes with our priming scripts, so you will need to comment it out (put a hash before it):

  • test -x $DAEMON || exit 0
    #set -e
    
    USER=mythtv
    RUNDIR=/var/run/mythtv
    ARGS="--daemon --logfile /var/log/mythtv/mythbackend.log --pidfile $RUNDIR/$NAME.pid"
    EXTRA_ARGS=""
    NICE=0

You can now add the two permission functions right after NICE=0:

#
# take firewire ownership and echo the action to the log
#
own_firewire() {
  chown $USER:$USER $FIREWIRE
  echo $STAMP '    firewire ownership acquired' >> $MLOG   # write it to the log
  return
}

#
# release firewire ownership and echo the action to the log
#
rls_firewire() {
  chown root:disk $FIREWIRE
  echo $STAMP '    firewire ownership released' >> $MLOG   # write it to the log
  return
}

Now, you need to call those functions. Scroll down in the init file, looking for:

  • case "$1" in
      start)
            if test -e $RUNDIR/$NAME.pid ; then
                    echo "mythbackend already running, use restart instead."
            else

Directly after the else, add:

# take ownership of firewire
                own_firewire

Now that you have it set to take ownership, it's a good idea to release ownership when the backend is not running.

To do this, scroll down until you find:

  •   stop)
            echo -n "Stopping $DESC: $NAME "
            start-stop-daemon --stop --oknodo --pidfile $RUNDIR/$NAME.pid \
                    --chuid $USER --exec $DAEMON -- $ARGS
            test -e $RUNDIR/$NAME.pid && rm $RUNDIR/$NAME.pid
            echo "."

and then add the call to the release function immediately after it:

# release firewire ownership back to root
        rls_firewire

Make sure the ;; following the echo "." command suvives your addition.

That block, with both additions, should now look like:

  • case "$1" in
      start)
            if test -e $RUNDIR/$NAME.pid ; then
                    echo "mythbackend already running, use restart instead."
            else
    
    # take ownership of firewire
                    own_firewire
    
                    echo -n "Starting $DESC: $NAME"
                    start-stop-daemon --start --pidfile $RUNDIR/$NAME.pid \
                            --chuid $USER --nicelevel $NICE --exec $DAEMON -- $ARGS
                    echo "... STARTED"
            fi
            ;;
    
      stop)
            echo -n "Stopping $DESC: $NAME"
            start-stop-daemon --stop --oknodo --pidfile $RUNDIR/$NAME.pid \
                    --chuid $USER --exec $DAEMON -- $ARGS
            test -e $RUNDIR/$NAME.pid && rm $RUNDIR/$NAME.pid
            echo "... STOPPED"
    
    # release firewire ownership back to root
            rls_firewire
            ;;

Save the result, and start the backend server to check if the changes work:

$ sudo /etc/init.d/mythtv-backend start

First, see if MythTV got the ownership:

$ ls -l /dev/raw1394

should return:

  • crw-rw---- 1 mythtv mythtv 171, 0 2007-03-05 00:05 /dev/raw1394
                 ^^^^^^ ^^^^^^
                     correct!

and then stop the server and check it again:

$ sudo /etc/init.d/mythtv-backend stop
$ ls -l /dev/raw1394

It should return:

  • crw-rw---- 1 root root 171, 0 2007-03-05 00:05 /dev/raw1394
                 ^^^^ ^^^^
                 yup, root owns it!

which clearly shows if the change of ownership is working.

Next, check to see that the actions are being echoed to the log as they should:

$ tail -n 40 /var/log/mythtv/mythbackend.log

trace back through the log and you should see where the ownership changed at start and stop (the easiest way is by time, obviously).

In my case, it looked like this:

  • 2007-03-05 00:12:18     firewire ownership acquired   <<<=======### server started here
    2007-03-05 00:12:18.999 Using runtime prefix = /usr
    2007-03-05 00:12:19.041 New DB connection, total: 1
    2007-03-05 00:12:19.048 Connected to database 'mythconverg' at host: localhost
    2007-03-05 00:12:19.071 Current Schema Version: 1160
    Starting up as the master server.
    2007-03-05 00:12:19.094 New DB connection, total: 2
    2007-03-05 00:12:19.109 Connected to database 'mythconverg' at host: localhost
    2007-03-05 00:12:19.112 EITHelper: localtime offset -6:00:00
    2007-03-05 00:12:19.116 New DB connection, total: 3
    2007-03-05 00:12:19.117 Connected to database 'mythconverg' at host: localhost
    2007-03-05 00:12:19.160 EITHelper: localtime offset -6:00:00
    2007-03-05 00:12:20.707 New DB scheduler connection
    2007-03-05 00:12:20.708 Connected to database 'mythconverg' at host: localhost
    2007-03-05 00:12:20.710 Main::Starting HttpServer
    2007-03-05 00:12:20.714 Main::Registering HttpStatus Extension
    2007-03-05 00:12:20.726 mythbackend version: 0.20.20060828-3 www.mythtv.org
    2007-03-05 00:12:20.727 Enabled verbose msgs:  important general
    2007-03-05 00:12:20.727 AutoExpire: Found 2 recorders w/max rate of 210 MiB/min
    2007-03-05 00:12:20.728 AutoExpire: Required Free Space: 181.6 GB w/freq: 5 min
    2007-03-05 00:12:22.722 Reschedule requested for id -1.
    2007-03-05 00:12:23.061 Scheduled 33 items in 0.3 = 0.09 match + 0.25 place
    2007-03-05 00:12:23.064 Seem to be woken up by USER
    2007-03-05 00:12:24.074 I'm idle now... shutdown will occur in 600 seconds.
    2007-03-05 00:12:26     firewire ownership released   <<<=======### and stopped here

If these two tests are not giving you similar results, go back and check for errors you might have made.

This method will give total ownership of firewire to the MythTV user and group as long as the backend server is running. If, for some reason, you need to use other firewire devices while the backend is running, you can try adding that user to the mythtv group- untested-[MI]

Adding the Priming Function

The last set of changes that you need to make to the init script is to add the priming function and make sure it is called before the backend server starts.

Open it for editing:

$ gksudo gedit /etc/init.d/mythtv-backend

Then add this right after the rls_firewire function that you added:

#
# attempt to prime and stabilize the firewire connection
# and echo the result to the log
#
prime_firewire() {

  echo $STAMP '    priming firewire...' >> $MLOG

# call the primer as user mythtv -- IMPORTANT!
  su - $USER -c "myth_prime"

# store the return code for testing
  FWERR=$?

        case $FWERR in
               0)
                echo   $STAMP '    SUCCESS! firewire is primed' >> $MLOG ;;
               1)
                echo   $STAMP '    FAILED! unable to get firewire handle' >> $MLOG ;;
               2)
                echo   $STAMP '    FAILED! unable to prime firewire' >> $MLOG ;;
               *)
                echo   $STAMP '    BAD ERROR RETURNED? -- FIXME!!' >> $MLOG ;;
        esac
  return
}

so that the result looks like this:

  • #
    # release firewire ownership and echo the action to the log
    #
    rls_firewire() {
      chown root:disk $FIREWIRE
      echo $STAMP '    firewire ownership released' >> $MLOG
      return
    }
    #
    # attempt to prime and stabilize the firewire connection
    # and echo the result to the log
    #
    prime_firewire() {
    
      echo $STAMP '    priming firewire...' >> $MLOG
    
    # call the primer as user mythtv -- IMPORTANT!
      su - $USER -c "/usr/bin/myth_prime"
    
    # store the return code for testing
      FWERR=$?
    
            case $FWERR in
                   0)
                    echo   $STAMP '    SUCCESS! firewire is primed' >> $MLOG ;;
                   1)
                    echo   $STAMP '    FAILED! unable to get firewire handle' >> $MLOG ;;
                   2)
                    echo   $STAMP '    FAILED! unable to prime firewire' >> $MLOG ;;
                   *)
                    echo   $STAMP '    BAD ERROR RETURNED? -- FIXME!!' >> $MLOG ;;
            esac
      return
    }

Now you can add the start instructions right before the server is started. Scroll down to where you added the call to the firewire ownership function and add:

# then prime it
                prime_firewire

so the result is:

  • case "$1" in
      start)
            if test -e $RUNDIR/$NAME.pid ; then
                    echo "mythbackend already running, use restart instead."
            else
    
    # take ownership of firewire
                    own_firewire
    
    # then prime it
                    prime_firewire

Just to cover all the bases, you should also add both the firewire ownership and priming functions to the restart/force-reload section of this script. Scroll down to:

  •   restart|force-reload)
            echo -n "Restarting $DESC: $NAME"
            start-stop-daemon --stop --oknodo --pidfile $RUNDIR/$NAME.pid \
                    --chuid $USER --exec $DAEMON -- $ARGS
            echo -n "... STOPPED"
            sleep

and add:

# take ownership and prime firewire, just in case either have changed
        own_firewire
        prime_firewire

so the final code is:

  •   restart|force-reload)
            echo -n "Restarting $DESC: $NAME"
            start-stop-daemon --stop --oknodo --pidfile $RUNDIR/$NAME.pid \
                    --chuid $USER --exec $DAEMON -- $ARGS
            echo -n "... STOPPED"
            sleep 3
    
    # take ownership and prime firewire, just in case either have changed
            own_firewire
            prime_firewire
    
            start-stop-daemon --start --pidfile $RUNDIR/$NAME.pid \
                      --chuid $USER --nicelevel $NICE --exec $DAEMON -- $ARGS

Save the changes you have made- this is all you need to do with this script.

All that is left to do before the final MythTV configuration is to add the primer itself. Skip ahead to the section for the STB you are using. Each of these primers has been tested and confirmed to work.

If you are working with a STB that is not listed, but you could get a good connection with the earlier tests, use the:

  • 62xx Firewire Primer if your STB works best with broadcast connections
  • SAxx Firewire Primer if your STB works best with p2p connections

or try both (one at a time) if your STB seems to work either way. You may need to tweak the test parameters for optimum priming performance. There is no guarantee that even though you could get a good connection with the firewire_tester that you will be able to get it working with MythTV- but it's sure worth a try.

62xx Firewire Primer

The 62xx series STB has been reported to work with both broadcast and p2p connections- but research seemed to show that not all STBs would work p2p, while all apparently work with broadcast connections once they are properly primed. If you were able to “repair” the broadcast connection in earlier testing, then this is the primer you want to use. If you were unable to “repair” a broadcast connection, but could establish a p2p connection, you might need to use the SAxx script- but it it recommended you try this primer first. [The author's 6212III works fantastically with broadcast and would grudgingly prime with the SAxx script.]

Download myth_prime.c

This primer is a modified version of the firewire_tester that has been adapted to establish a working firewire connection without fail. To that end, it will attempt the fix three times before returning error. In more than three months of daily use, it has not failed to establish a good connection in the author's backend server (which boots sometimes 3 or 4 times a day).

If your STB runs on node 0, port 1 (which seems to be the default node choice for this box), then you only need to compile the primer. If you need to change the port or node for your system, the two locations are clearly commented in main() at the tail of the file myth_prime.c:

  • int main(void) {
    
        raw1394handle_t handle;     // our firewire handle...
        int port = 0;               // port 0
        int node = 1;               // node 1 is default for 62xx (?)
    ...

Save your changes (if necessary) and then compile it:

$ gcc -Wall myth_prime.c -o myth_prime -liec61883 -lraw1394

and copy the object file to /usr/bin, where the init script will look for it:

$ sudo cp myth_prime /usr/bin/

Now you can move forward to Testing the Primer.

SAxx Firewire Primer

The SAxx primer uses a BASH script to call firewire_tester and is configured to prime port 1, node 1. If you need to use a different port or node, you can change them at the head of the bash script:

  • PORT=1          # firewire port
    NODE=1          # node to prime

Download myth_prime_p2p_r2

If you need to make changes to it, make them and then save it. The script will need to be made executable and then both files will need to be copied to /usr/bin:

$ chmod +x myth_prime_p2p_r2
$ sudo cp firewire_tester /usr/bin/
$ sudo cp myth_prime_p2p_r2 /usr/bin/myth_prime

Note that we changed the name of the script to match the name that the firewire primer function from /etc/init.d/mythtv-backend calls.

Testing the Primer

Make sure the backend server is stopped:

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

To make this easier for yourself, clear your backend log. If you feel the need (it's really not that important), back it up first- but remember to use sudo when you copy!

Clear it by echoing a null string- this will erase the entire log since we are not appending to it:

$ sudo echo "" > /var/log/mythtv/mythbackend.log

Now start the server:

$ sudo /etc/init.d/mythtv-backend start

You may notice that it takes a little extra time for the server to start- especially if you are using the SAxx STB. This is normal behavior, since the backend server waits for the firewire to be primed before starting.

Once it is started, restart it:

$ sudo /etc/init.d/mythtv-backend restart

Now check the backend log to see if everything went as planned:

$ gedit /var/log/mythtv/mythbackend.log

You should see something like this at the head of the log:

  • 2007-03-06 16:38:38     firewire ownership acquired    <<---## started
    2007-03-06 16:38:38     priming firewire...            <<---## the attempt
    2007-03-06 16:38:38     SUCCESS! firewire is primed    <<---## BINGO!
    2007-03-06 16:38:43.753 Using runtime prefix = /usr
    2007-03-06 16:38:43.876 New DB connection, total: 1
    2007-03-06 16:38:43.902 Connected to database 'mythconverg' at host: localhost
    2007-03-06 16:38:43.941 Current Schema Version: 1160
    Starting up as the master server.
    2007-03-06 16:38:43.989 New DB connection, total: 2
    2007-03-06 16:38:43.991 Connected to database 'mythconverg' at host: localhost
    2007-03-06 16:38:44.024 EITHelper: localtime offset -6:00:00
    2007-03-06 16:38:44.088 New DB connection, total: 3
    2007-03-06 16:38:44.131 Connected to database 'mythconverg' at host: localhost
    2007-03-06 16:38:44.209 EITHelper: localtime offset -6:00:00
    2007-03-06 16:38:45.755 New DB scheduler connection
    2007-03-06 16:38:45.756 Connected to database 'mythconverg' at host: localhost
    2007-03-06 16:38:45.759 Main::Starting HttpServer
    2007-03-06 16:38:45.766 Main::Registering HttpStatus Extension
    2007-03-06 16:38:45.785 mythbackend version: 0.20.20060828-3 www.mythtv.org
    2007-03-06 16:38:45.786 Enabled verbose msgs:  important general
    2007-03-06 16:38:45.787 AutoExpire: Found 2 recorders w/max rate of 210 MiB/min
    2007-03-06 16:38:45.789 AutoExpire: Required Free Space: 181.6 GB w/freq: 5 min
    2007-03-06 16:38:47.770 Reschedule requested for id -1.
    2007-03-06 16:38:48.848 Scheduled 33 items in 1.1 = 0.85 match + 0.23 place
    2007-03-06 16:38:48.853 Seem to be woken up by USER
    2007-03-06 16:38:49.858 I'm idle now... shutdown will occur in 600 seconds.
    2007-03-06 16:38:58.895 590 secs left to system shutdown!
    2007-03-06 16:39:08.936 580 secs left to system shutdown!
    2007-03-06 16:39:09     firewire ownership acquired         <<---## re-started
    2007-03-06 16:39:09     priming firewire...
    2007-03-06 16:39:09     SUCCESS! firewire is primed
    2007-03-06 16:39:17.115 Using runtime prefix = /usr
    2007-03-06 16:39:17.148 New DB connection, total: 1
    2007-03-06 16:39:17.155 Connected to database 'mythconverg' at host: localhost
    2007-03-06 16:39:17.171 Current Schema Version: 1160
    Starting up as the master server.

If your results are similar, CONGRATULATIONS- You have just taken control of your cable box with MythTV!

So, fire it up already and enjoy channel surfing!


If you receive a priming error, here are the likely causes:

  • FAILED! unable to get firewire handle: You are most likely to get this error if you are trying to use the wrong port or node. Run plugreport again to be sure the STB is still on the node and plug you think it is. You are certain to get this error if the firewire permision change failed for some reason- which should be obvious in the log. You may also get this error if you are trying to prime from an encrypted or invalid channel... read on:

  • FAILED! unable to prime firewire: The most likely cause of this error is trying to prime when the STB is tuned to an encrypted or invalid channel. Tune the STB to a known good, unencrypted channel (best bet is a local station) and try again. If priming still fails, please see Tips on Priming.

  • BAD ERROR RETURNED? -- FIXME!!: This is a troubleshooting error. In the (hopefully) unlikely event you receive this error, please PM majoridiot on the Ubuntu Forums.

Tips on Priming

  • If firewire primes with the tester but will not prime or gives strange errors when starting the backend, try downloading the mythtv-setup script if you edited it for yourself- you might have made errors.
    • The primers provided are rather stringent in order to (hopefully) guarantee a successful firewire connection every time MythTV starts. If, during your testing, you find that your STB is not particularly difficult to prime, you can adjust the parameters of the primers to speed the priming process.
  • If a channel "hangs" and firewire stops working- which can happen frequently on poorly-broadcast HD channels in particular- it may be necessary to manually change the STB to a known good channel (which is the channel the system will use to prime itself), stop the backend, enter mythtv-setup and re-set the start channel for firewire in the tuner setup to a known good channel (doesn't have to be the same as what you set the STB to).
  • For unknown reasons, the 62xx STB may occasionally become unstable and refuse to prime. If this happens:
    • Make sure no frontend is using firewire and that no recordings are taking place
    • Power off (power button) the STB for a few seconds and then power it back on
    • Tune the STB to a known good channel
    • Manually prime the firewire with the appropriate firewire_tester command or restart the backend
  • If the connection "jumps nodes" e.g. from node 1 to node 0 on the 62xx series STB, the best way to remedy it is:
    • Shut off the backend server
    • Unplug the power from the STB for 30 seconds

    • Restore power to the STB, turn it on and wait for it to fully boot
    • Restore power to the backend server
    • you should now be back on the default node

General Firewire Notes

  • You will not have access to content recorded and stored on your STB via MythTV, so get used to recording with MythTV instead of your STB.
  • You will not have access to Pay-Per-View or other "On-Demand" programming via MythTV.
  • You will not be able to access any 5c encrypted channels. Encryption is generally used for only "premium-content" channels, but varies by cable provider. If you are using the 62xx STB, you can check whether or not a channel is encrypted. Power on the STB and the TV attached to it. Tune to the channel in question. Press the Power button to power off the STB and then quickly press OK/SELECT on the STB remote. A diagnostic screen will appear. Using the STB remote, arrow-down to "D11 Interface Status" and press OK. If the channel the STB was tuned to when it was powered off is encrypted, the entry 5c Implementation will be 1. A 0 indicates it is not encrypted.

  • Some cable companies are setting the CCI broadcast flag on many channels to 0x02 which is "copy once". This interferes with proper firewire transmission as it requires an authenticated session with the STB. If you are unable to tune a channel and 5c encryption is not set on that channel, check the CCI broadcast flag in the STB diagnostic as described above. The CCI flag will be found under the menu item D6 and will be located either at the bottom of page one or two. If the CCI flag is set to anything other than 0x00, you will not be able to stream this channel over firewire. For further information, private message majoridiot on the Ubuntu Forums.

  • If your STB is a dual-tuner model, you will not have access to the second tuner or be able to use it for pip function with MythTV. This is due to the way the transport stream is exposed to firewire internally in the STB. [True for the 62xx. others?]-MI On the plus side, you can still watch LiveTV via firewire in MythTV on the first tuner while recording from the second tuner to the hard drive in the STB... but catch-22, see note 1. Wink ;)

  • For dual-tuner DVRs, it is a good idea to always leave the DVR powered on to avoid recording conflicts. By doing this, the STB thinks tuner 1 is watching tv and will automatically use the second tuner if it needs to record a program. This allows MythTV to use tuner 1 as needed. The only potential conflict may arise if the DVR needs to record 2 programs simulataneously and MythTV needs to record at the same time.

Channel Scanner

A scanner to help identify encrypted channels is in development and is available for testing. At this time, only Motorola STBs are supported. A Scientific Atlanta scanner is in development and should be available for testing very soon.

The scanner and related inforamation can be found HERE

The Scripts

These scripts are only applicable to mythtv versions .20

Download myth_prime.c (need to be compiled as described above)

Both of the following scripts should be downloaded and made executable with:

  • $ chmod +x <scriptname>

Download myth_prime_p2p_r2
Download mythtv-backend


MythTV_Firewire (last edited 2009-04-30 03:05:38 by fooka)