FireWire (an Apple trademark, also known by Sony's trademarked name, i.Link, or the generic IEEE 1394) is a personal computer and digital video serial bus interface standard offering high-speed communications and isochronous real-time data services. Up to 63 devices can be daisy-chained to one FireWire port.
FireWire works very well in connecting a MythTV backend to certain cable boxes including the Motorola DCT-6200. Here is how to get a fully working FireWire setup going either with a single set top box, or several boxes by daisy chaining.
- 1 Firewire stacks, old vs. new
- 2 Dependencies for the old stack (ieee1394)
- 3 Migrating from the old stack to the new stack
- 4 Plugreport
- 5 Plugctl
- 6 Test-mpeg2
- 7 firewire_tester
- 8 /dev/raw1394 permissions
- 9 Adding To MythTV
- 10 Changing Channels via Firewire
- 11 Sending Commands via Firewire
- 12 Troubleshooting
- 13 Troubleshooting (Unconfirmed)
- 14 List of Firewire Cards
- 15 FCC regulations
- 16 Further Reading
Firewire stacks, old vs. new
There are two firewire stacks in existence. The older stack "ieee1394", and the newer stack "juju". Depending on the Linux distribution and version used, you may wish to use one stack or the other. It is not recommended to have both stacks operating simultaneously.
You can confirm you are using the old firewire stack with the following command (as root):
lsmod | grep 1394
You can confirm you are using the new firewire stack with the following command (as root):
lsmod | grep firewire
If you get a non-empty list of results, it means you are using the specified firewire stack.
Regardless of which stack you use; once you have it working, the 'plugreport' and 'firewire_tester' commands described in later sections should function as described.
Dependencies for the old stack (ieee1394)
- libraw1394 (version must be <=1.2.1, 1.3.0 is BROKEN!)
Note to newbies: if you see "firewire support: no" -- then you probably don't have the three dependency libs installed. The first and third can be found at http://ieee1394.wiki.kernel.org/, and the second (libavc1394) probably comes with your distribution.
For Ubuntu users, these are available via apt (sudo apt-get install build-essential libraw1394-dev libiec61883-dev libavc1394-dev). However, to obtain test-mpeg2, libiec61883 needs to be compiled (but not installed):
$ sudo ./configure $ sudo make copy the resulting test-mpeg to your /usr/local/bin
For Fedora 12 users and earlier, these are available via yum (sudo yum install libraw1394 libavc1394 libiec61883 libiec61883-utils ), and installation will complete most of the configuration. Also, the mythtv rpms from ATrpms or RPMFusion do come pre-compiled with FireWire support, but does not include these 3 dependencies for full FireWire support.
For Fedora 13 users (and later?), the newer "Juju" Firewire stack which is included with distro has been found to function correctly with MythTV-0.24. This eliminates the need to revert back to the older stack given above. In fact, for those using precompiled rpms, the older stack is no longer available from ATrpms for Fedora 13 and later.
For Mandrake/Mandriva users, the development packages are required in addition to the library packages and are available via urpmi (sudo urpmi libraw1394-devel libiec61883-devel libavc1394-devel).
Migrating from the old stack to the new stack
If you were previously using the old stack, you may have blacklisted the new stack's modules in the past. Look in the following locations for files which blacklist juju modules:
Delete or comment out (prefix with a # symbol) any lines which blacklist the firewire-core and firewire-ohci modules.
The program plugreport lists all FireWire devices (on all buses):
Host Adapter 0 ============== Node 1 GUID 0x000e5cfffed720aa ------------------------------ oMPR n_plugs=1, data_rate=2, bcast_channel=63 oPCR online=1, bcast_connection=0, n_p2p_connections=0 channel=63, data_rate=2, overhead_id=0, payload=376 iMPR n_plugs=0, data_rate=2
Node and adapter should be apparent. If not, plugreport often outputs oMPR/iMPR errors for the adaptor, and it is usually (but not always) node 0.
To explain what the switches do for plugctl, -n will allow you to specify your node and -p will allow you to specify your host adapter. If you are using host adapter 0 then there is no need to use the -p switch. Gaining information to use with plugctl is done by using plugreport.
For the most reliable FireWire operation, use Point2Point/p2p. By default your n_p2p_connections will be set to '0'. This mode presented unreliable operation with dct6200's for recording and watching. Set p2p to 1.
Single STB (Set-Top Box) setup
plugctl -n 1 "oPCR.n_p2p_connections=1"
This will allow setting it so you maintain a stable connection by setting the Point2Point "Active".
Daisy chain setup
If you intend to use multiple STBs, daisy chain the FireWire connections. To daisy chain the dct6200 just plug the FireWire cable into the back of one port and into the computer then the second free FireWire port plug from one set top box to the other. Make sure each device is assigned to a unique channel
plugctl -n 1 "oPCR.channel=0" plugctl -n 1 "oPCR.n_p2p_connections=1" plugctl -n 2 "oPCR.channel=1" plugctl -n 2 "oPCR.n_p2p_connections=1"
It is important to set the unique channel first, followed by the p2p. Missing this step will cause it to be non functional.
Example commands to enable broadcast setup:
plugctl -n 1 "oPCR.channel=63" plugctl -n 1 "oPCR.bcast_connection=1"
The ideal place to add the plugctl settings for any of the above methods would be to the mythbackend start up script.
This tool is very simple to use and at first glance is never a good idea to assume things are working. As said above with plugctl you can have your n_p2p_connections=0 set and it may work the first 3-5 tries but then it will start to fail. It would be a good idea to test it at least 10 times. I tested it myself 50 times total to verify it was reliable. test-mpeg2 is only able to test P2P connections.
How to get test-mpeg2
If test-mpeg2 doesn't come with your system, you may be able to find it in the libiec61883/examples directory. If you don't have that directory (i.e. you didn't have to download and make libiec61883 in the first place), then look above in the Dependencies section for the url to the source. Gentoo users should emerge libiec61883 with USE="examples".
To download and compile,
wget http://www.kernel.org/pub/linux/libs/ieee1394/libiec61883-1.2.0.tar.gz tar -xzvf libiec61883-1.2.0.tar.gz cd libiec61883-1.2.0/examples gcc -Wall -o test-mpeg2 test-mpeg2.c -liec61883 -lraw1394
test-mpeg2 -r <node> > test.mpg
firewire_tester will help determine which connection type one should use with mythtv as well as being able to stabilize broadcast connections.
- Compile firewire_tester.
In order to use the program you will need to compile the program. You will need the libraw1394 and libiec61883 headers installed. On Fedora, simply execute this command:
> yum install libraw1394-devel libiec61883-devel
Compile the program as follows:
> gcc -Wall -o firewire_tester firewire_tester.c -liec61883 -lraw1394
On some systems, you may have to add the following line to the top of firewire_tester.c
> #include <getopt.h>
You will probably want to copy the executable to /usr/local/bin.
- Test P2P Connection.
In the example below, 2 of the 5 tests failed. This indicates this STB isn't going to be stable using a P2P connection with mythtv. If all came back successful you should be able to setup mythtv to use P2P.
> $ firewire_tester -p -n 2 -r 5 > Action: Test P2P connection 5 times, node 2, channel 2 > P2P: Testing...Failed > P2P: Testing...Success, 138 packets received > P2P: Testing...Failed > P2P: Testing...Success, 416 packets received > P2P: Testing...Success, 232 packets received
- Stablize Broadcast Connection.
If P2P isn't working, next step is to attempt to stabilize broadcast connections as seen below. If it comes back as being successful then setup mythtv to use a broadcast connection. It will be required to re-run this command if the STB or mythbackend server are ever rebooted to restabilize it.
> $ firewire_tester -B -n 2 > Action: Attempt to fix broadcast connection 1 times, node 2 > Broadcast: Testing...Failed > P2P: Testing...Failed > P2P: Testing...Failed > P2P: Testing...Failed > P2P: Testing...Success, 227 packets received > Broadcast: Testing...Failed > P2P: Testing...Failed > P2P: Testing...Success, 326 packets received > Broadcast: Testing...Failed > P2P: Testing...Failed > P2P: Testing...Success, 265 packets received > Broadcast: Testing...Failed > P2P: Testing...Failed > P2P: Testing...Success, 356 packets received > Broadcast: Testing...Success, 422 packets > Broadcast: Testing...Success, 382 packets > Broadcast: Testing...Success, 449 packets > Broadcast: Testing...Success, 419 packets > Broadcast: Testing...Success, 460 packets > Broadcast Fix: Success
- Test Broadcast Connection
> $ firewire_tester -b -n 2 -r 5 > Action: Test broadcast 5 times, node 2, channel 61 > Broadcast: Testing...Success, 189 packets > Broadcast: Testing...Success, 253 packets > Broadcast: Testing...Success, 258 packets > Broadcast: Testing...Success, 194 packets > Broadcast: Testing...Success, 298 packets
Always make sure to check permissions on /dev/raw1394. Here are a few ways to fix this, depending on your distribution and type of mythtv setup.
You should check the permissions on your device node with ls:
> $ ls -l /dev/raw1394 > crw-rw---- 1 root video 171, 0 Aug 11 21:08 /dev/raw1394
The following techniques are a long-term replacement for using chmod 666 after every reboot and then restarting the back-end.
Method 1: Change group access
Using ls determine group membership of the firewire device. You should then include the mythtv user in that group.
> $ gpasswd -a mythtv <GROUP_NAME>
Method 2: modify udev rules
The following changes permissions
- Open a terminal and do the following
> nano /etc/udev/rules.d/10-raw.rules
- Then enter the following information into the file being creating.
> KERNEL=="raw[0-9]*", NAME="%k", GROUP="mythtv", MODE="0666" OWNER="mythtv"
This rule makes the device node read/write by anyone so it shouldn't matter who the owner and group is at that point. Some may consider the udev technique 'hackish', but it shouldn't matter on a dedicated mythtv box
Adding To MythTV
Run mythtv-setup. Select "Capture Cards". Select (New Capture Card) from the list. The type should be "Firewire."
For the settings you want to tell it to use the port you're plugged into. (Systems with multiple FireWire interfaces (such as on board and add-in cards) have multiple host adapters/ports) The node should be the node you got from plugreport. This is also the same as what you pass to the -n argument for plugctl and -r for test-mpeg2. For most people you'll want to use a p2p connection. If you can't get p2p working select broadcast.
The default speed of 100mpbs should be fine, but some combinations of boxes and FireWire cards need 400mbps. For example, my 6200 with a Agere Systems FW323 card requires that 400mbps be used for the highest reliability.
Once you have setup your capture card, be sure to pair it with a Video Source under the Input Connections menu.
Also note that the port and node settings in mythtv-setup are among those that only kick in after mythbackend is restarted.
Changing Channels via Firewire
FireWire channel changing always works, regardless of the encryption status of the channels themselves. MythTV's FireWire tuner functionality changes channels internally. External utilities for changing channels via Firewire are also available. For Motorola boxes, this is called 6200ch. The 'README' should be able to guide you through the process, but here is an overview as well.
- Create a file 6200ch.c and paste the contents of 6200ch.c into the file.
- Compile the file
- cc -std=gnu99 -o 6200ch 6200ch.c -lavc1394 -lrom1394 -lraw1394
- Test changing to channel 20
- ./6200ch -v 20
- If your box is on a different node than the default #1, you'll need to provide it as an argument to 6200ch.
- First, find out the node (if it says "libiec61883 error: error reading oMPR", that means there's no box on that node)
- Now use that node number for 6200ch:
- ./6200ch -n [node number] -v 20
- Copy the file to the bin directory
- sudo cp 6200ch /usr/bin
- Now add 6200ch to mythtv-setup
- Go to "Input Connections"
- Select your input
- For "External channel change command:" enter "6200ch"
- Click "Next", "Finish", then press escape to exit. Run mythfilldatabase if you want to, not sure if it's needed.
- run mythfrontend and check that channel changing works.
There are other scripts available. Major Idiot's mythchanger works for SA4240HDC boxes. If you use a script that requires arguments, enter other arguments first and end with the one that specifies the channel, as MythTV appends the channel number to whatever is entered in "External channel change command." For example to call mythcnager with a forced box designator enter "mythchanger -f 4 -c "
Sending Commands via Firewire
In addition to using the channel changers above, commands can be sent to some Set-Top-Boxes (STB) to simulate remote control or front panel key presses. This is more deterministic than using IR since the firewire/ieee1394 commands offer success/fail feedback.
The built in firewire capabilities of myth as well as certain channel changers use one of these commands (power on). A much more extensive set of commands has been implemented in Stb-command which can be used for power control/status, eliminating the "Press the MENU key to continue" idle screens seen on some STBs, or simply creating web services controls or even myth event controls to manage the STB.
If tuning a 5C=0 station and MythTV is not consistent in grabbing the MPEG stream try shutting down the computer and unplugging the cable box power and disconnect the FireWire cable from one end. Once both are powered down turn them all back on and reconnect the FireWire cable. This should reset/clear any FireWire plug settings and allow MythTV to properly set them.
- Note: The above can be caused by not setting to bcast or p2p before tuning as stated above.
Finally, there is a bug in the Linux kernel that causes some FireWire chips/doitdonsetups (?) to overflow their buffer and cause excessively high CPU usage. There was a bug in MythTV itself but I believe it has been patched(?). The bug though will cause dropped data in the mpeg stream resulting in many errors during playback.
If you encounter stream errors playing back LiveTV from the firewire while testing, ensure you haven't reniced mythfrontend below 0. When I use nice -n -2 mythfrontend, I cannot properly playback from my firewire capture card. --mmead 18:26, 27 April 2006 (UTC)
For information relating to 5C check source here 
It seems that some FireWire cards are not 100% reliable in mythtv, even when they are reliable using test-mpeg2. If test-mpeg2 works but you can't watch LiveTV, try the following.
- With mythbackend running, try test-mpeg2 and see if you get data. With my copy of libiec61883 (1.0.0) you must redirect test-mpeg2 to a file. Let it run 10-30 seconds and ^C the program. ls -l the file and see if there's any data there. If there is no data, unplug your FireWire cable and plug it in again. Try test-mpeg2 a couple times to see if you get data now. If not, unplug your FireWire cable, remove power from your cable box, plug your cable box back in and give it enough time to start up again, and plug in your FireWire cable. Run plugreport to ensure your node hasn't changed. Run test-mpeg2 and see if you get data. If you still don't get data go over your kernel setup again and make sure everything is setup properly and you have the proper permissions.
If you have the problem I do where firewire isn't reliable, it looks like you need to use a different FireWire card.
- Another solution is to test the results of test-mpeg2 for a non-zero result
- because the next capture typically works. There is a script - Firewire Priming
- that can be used to test the firewire connection before each channel change.
If test-mpeg2 seems to work however LiveTV will not get a full signal lock and mythbackend creates only 0 byte files, your STB is likely not sending a proper PAT and/or PMT in the transport stream. Although this can be regenerated to allow mythbackend to acquire "signal lock" (code not yet in SVN), I have not gotten around playback problems on some channels, my only observation is that mplayer is much more tolerant of these problems in the transport stream than mythfrontend. It may be best to try a different STB to get a proper transport stream.
- Observed a problem with the kernel (2.6.20 - standard IEEE-1394 Stack) locking up when I accidentally set two ports on the same PCI-E Firewire card to different bandwidths. Setting both ports to the same bandwidth resolved this.
List of Firewire Cards
|Firewire Manufacturer||Chipset #||Tuner Make and Model #||Comments|
|Belkin F5U008||NEC D72870BGM||Verizon/Motorola QIP6200-2||Channel changing seems to work well enough, but capture would hang the entire system. What little capturing I could do required broadcast mode. The bus often reset and once it decided to quit capturing, no amount of priming with firewire_tester would resurrect it.|
|Rosewill RC-501||VIA VT6306||Verizon/Motorola QIP6200-2||Channel changing works using 6200ch. I set peer-to-peer mode in my system startup scripts (I use runit) and use 100M connection in mythtv-setup with Generic for set-top-box and--very important to my success--I turn off the firewire bus reset. I increased the tuning and signal timeouts and scheduled recordings are near 100% successful. Under 0.21-fixes live tv did not seem to work reliably, but 0.22-fixes seems ok. I use the firewire priming script (adapted for my situation). I need to power cycle the QIP6200-2 if I try to tune an encrypted channel, but otherwise things are nice and stable.|
|VIA Technologies||VT6306||Motorola DCT6412||Channel change and capture work, but require "priming" the port with p2p=1, channel=63, bcast=0 and a short capture with test-mpeg2 to get it started. Some channels don't work (encrypted?). If firewire is replugged quickly, port can change to 0 or 1. Unsuccessful getting the second firewire port to work.|
|VIA Technologies (Asus onboard)||VT6306||Motorola DCT6200||Unable to get reliable channel changing or recording. Port number can change after physical resets.|
|NEC||D72874GC||Motorola DCT6412||Capture would hang firewire subsystem. Required hard reset to get working again.|
|LSI / Agere Systems||FW323 (rev 61)||Motorola DCT6200|| Channel change is reliable. Capture is not. Seems that test-mpeg2 always works but sometimes data doesn't start flowing until after myth's timeout, resulting in missed recordings and flakey livetv.
Similar setup - Attempted both P2P and Broadcast, same results - reliable channel changing, but very unreliable capture. Priming/soft reseting did not help - requires disconnecting the FireWire cable and physically resetting to get a reliable capture.
|Creative Audigy||??? (rev ?)||Motorola DCT6200|| Channel change and capture is reliable in broadcast mode if primed before running frontend. DCT6200 will occasionally "move" to node 1 instead of node 0 depending on poweron sequence.. A firewire_tester -R seems to reset it.
Similar setup - P2P consistently unreliable. Priming/soft reseting did not help. Forced to use broadcast
|LSI / Agere Systems||FW323 (rev 61)||Two Motorola DCT6200 daisy chained with broadcast and 200mbps||With a cron script that primes unused boxes every 15 minutes, FireWire has been 100% reliable for years. I use the internal channel tuner.|
|Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller & Creative Labs SB Audigy FireWire Port||(rev 01) TI & (rev 04) Audigy||Handles 6200, 3214, 6416 daisychained (Via P2P with seperate channels)||As above states firewire_tester I did not prefer it that much over my own script. I will see about getting it into the contrib as it does P2P vs bcast and seems far more reliable. As for being reliable I never missed a beat once I got my script done with either of the firewire controllers. However I am now in a area that has partial 5C. Now I use the external channel changer and hauppauge + firewire capture so it is no longer daisychain.|
|Adaptec PCI||NEC uPD72874 (rev 01)||Motorola DCT6200|| Works most of the time with a priming script, but not 100% reliable - sometimes it misses channel changes (using 6200ch), sometimes it times out before it's able to recieve data. "Good enough" for live tv viewing, but not really stable enough to rely on for timed recordings (it will miss about 25% of them).
Same computer, same setup, moved the PCI card to a different PCI slot, now is very stable, no priming script needed ~
|Adaptec PCI||NEC uPD72874 (rev 01)||2xDCT6200||These 2 DCT6200s are only stable doing broadcast connections. Requires using firewire_tester to stabilize the broadcast connection if the server or a STB is rebooted. Internal channel changer works 100%|
|LSI / Agere Systems||FW323 (rev 61)||1xDCT6200||This STB is stable with both P2P and broadcast connections.|
|Texas Instruments on an Intel DG33BU motherboard and Texas Instruments on a Gigabyte GA-G33-DS2R motherboard||TSB43AB22/A (Intel MB) and TSB43AB23 (Gigabyte MB)||Motorola DHC3200||Capture works with by stabilizing with firewire_tester with both P2P (not completely reliable) and broadcast mode. Comcast SF Bay Area no channels were 5C'd initially, and now most premium channels (HBO, Encore, etc.) are encrypted as well as the local CBS affiliate (KPIX).|
|LSI / Agere Systems||FW323 (rev 61)||DCT6200&DCT6214||STB is stable in P2P and broadcast. test-mpeg2 doesn't work but "firewire_tester -n 0 -B" primes fine and channel changes are %100.|
|LSI / Agere Systems||FW323 (rev 05)||DCH3416||Agere Systems|
|VIA Technologies||Not sure||DCH6200||Linux 126.96.36.199. Works fine with broadcast only. STB from TimeWarnerCable San Diego.|
|VIA Technologies (Sunix PCI FW3010C)||VT6306||Motorola DCT6416||Linux 188.8.131.52-69. Works in broadcast mode only.|
|LSI / Agere Systems||FW323 (rev 04)||Motorola QIP7100-1||Linux 2.6.27-9. Works for changing channels, not sure about video.|
|ST Lab F-152 PCI 3+1Port1394a||NEC uPD72874||Pace RNG110||Fedora 11. Works using P2P, stable @ 400Mbps. Use 6200ch changer.|
|Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller||?||Motorola DCT-6416, Motorola DCT-6200||Fedora 12 (older firewire stack); Fedora 13 (Juju firewire stack). Works only in broadcast mode.|
|Syba SD-COMBO-02||VIA VT6307||Pace RNG110||PCI USB2 and FW400 card. Tested in Mythbuntu 10.04 & 10.10 64-bit. Video and sound are garbled and unwatchable.|
|Unknown||NEC PD72874||Pace RNG110||PCI FW400 card. Tested in Mythbuntu 10.04 & 10.10 64-bit. Works perfectly. Set up as a DCT-6200, Point-to-Point, 400Mbps.|
|Texas Instruments||TSB43AB23||Motorola DCH3200||Onboard GIGABYTE motherboard. Tested in Mythbuntu 10.04 & 10.10 32-bit. Works perfectly.|
|Agere||unknown||Motorola DCH3200||Works initially, but is unreliable. Best solution I've found is to power cycle the DCH3200 at least every 24 hours.|
|VIA||VT6308P||Motorola DCH3200||Works initially, but is unreliable. Best solution I've found is to power cycle the DCH3200 at least every 24 hours.|
|(Please add your example Hardware stats here! Also see Firewire Cablebox Compatability)|
The FCC has passed a regulation that if you are in the United States, and you have a HD subscription and a HD cable box, they have to on your request replace or upgrade your cable box with working FireWire.
Page 50, section 4
- (4) Cable operators shall:
- (i) Effective April 1, 2004, upon request of a customer, replace any leased high definition set-top box, which does not include a functional IEEE 1394 interface, with one that includes a functional IEEE 1394 interface or upgrade the customer's set-top box by download or other means to ensure that the IEEE 1394 interface is functional.
If you are having troubles with your local cable provider, you have a couple of choices
- File a complaint
- Take them to small claims court
- Vote with your wallet
- Submit complaint to Attorney General
Be aware that the above has been diluted by Congress granting numerous "waivers" to companies that argue, for example, that the FCC regulations are unfair for competition in their area. In that case the only choice is to pick a different provider...