FireWire (also known as i.Link or IEEE 1394) is a personal computer and digital video serial bus interface standard offering high-speed communications and isochronous real-time data services. FireWire can be considered a successor technology to the obsolescent SCSI Parallel Interface. 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). MythTV 0.18 and up contains built-in support for changing channels on the DCT-6200 (generally reliable, although occasionally digits get dropped, however I have not noticed this with 0.19). Here is how to get a fully working firewire setup going either with a single set top box, or several boxes by daisy chaining.
- '--enable-firewire' when building mythbackend.
Note to newbies: if --enable-firewire doesn't "take" when running the configure script in the build process -- i.e. you see "firewire support: no" -- then you probably don't have the three dependancy libs installed. The first and third can be found at http://www.linux1394.org/, and the second (libavc1394) probably comes with your distribution.
Needed kernel modules
> mythbox:~# lsmod|grep 1394 > dv1394 20728 0 > raw1394 25120 2 > eth1394 19856 0 > ohci1394 32716 1 dv1394 > ieee1394 353144 4 dv1394,raw1394,eth1394,ohci1394
Usually to have modules load automatically the file resides in /etc/modules/autoload.d/kernel-2.6 or similar. This is distribution dependent.
> Host Adapter 0 > ============== > Node 2 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.
To explain what the switch's 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 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.
- Note: Only advised if all else fails attempt the bcast method, this is not reccommended for daisy chain as it is very unreliable.
> 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 trys 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.
- If it is needed to use test-mpeg2, invoke the command I find it makes it easier to use it with .mpg vs .ts
> test-mpeg2 -r 1 > test.mpg
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.
I ran into permissions issues with raw1394 and adding read permissions was just not enough. I had to specify that /dev/raw1394 be owned by mythtv:mythtv. To do this I did a custom udev rule.
- 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"
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. (For me this always seems to be port 0, has anyone ever had to use a port that wasn't 0? --zwhite) 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.
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.
List of Firewire Cards
|Firewire Manufacturer||Chipset #||Tuner Make and Model #||Comments|
|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.|
|NEC||D72874GC||Motorola DCT6412||Capture would hang firewire subsystem. Required hard reset to get working again.|
|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.|
|Agere Systems||FW323 (rev 61)||Two Motorola DCT6200 daisy chained with broadcast|| I use 6200ch (without the -s switch) to change the channel. It is generally reliable but fails silently (so the channel stays the same as the previous) once every 20-30 changes.
With the following lines in /etc/rc.d/rc.local, FireWire connections other than the channel changing, as noted above, are 100% reliable. Note that both 6200ch and firewire_tester are in the doc/contrib directory of the tarball (or its equivalent in prepackaged binaries).
echo "Jumpstarting FireWire" /usr/local/bin/firewire_tester -v -b -n 1 # 'plugreport' says one box is on node 1 /usr/local/bin/firewire_tester -v -B -n 1 /usr/local/bin/firewire_tester -v -b -n 3 # The other is on node 3 /usr/local/bin/firewire_tester -v -B -n 3
|(Please add your example Hardware stats here!)|