FireWire

From MythTV Official Wiki
Revision as of 08:10, 7 May 2006 by SlicerDicer (talk | contribs) (Daisy chain setup: Removed tasty but not so useful bloat.)

Jump to: navigation, search


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.

Dependencies

  • '--enable-firewire' when building mythbackend.
  • libraw1394
  • libavc1394
  • libiec61883

Advised kernel setup

To eliminate any potential issues with modprobe, it is recommend to compile 1394 functionality monolithically into the kernel, not as modules.

  • Location of Firewire Support in the Kernel in 2.6.15.1 vanilla-sources
> device drivers > IEEE 1394 (FireWire) support
  │ │ ---   Subsystem Options                                             │ │
  │ │ [ ]   Excessive debugging output                                    │ │
  │ │ [ ]   OUI Database built-in                                         │ │
  │ │ ---   Build in extra config rom entries for certain functionality   │ │
  │ │ ---     IP-1394 Entry                                               │ │
  │ │ [*]   Export all symbols of ieee1394's API                          │ │
  │ │ ---   Device Drivers                                                │ │
  │ │ ---   Texas Instruments PCILynx requires I2C                        │ │
  │ │ <*>   OHCI-1394 support                                             │ │
  │ │ ---   Protocol Drivers                                              │ │
  │ │ <*>   OHCI-1394 Video support                                       │ │
  │ │ < >   SBP-2 support (Harddisks etc.)                                │ │
  │ │ <*>   Ethernet over 1394                                            │ │
  │ │ <*>   OHCI-DV I/O support                                           │ │
  │ │ <*>   Raw IEEE1394 I/O support                                      │ │
  │ │ < >   IEC61883-1 Plug support                                       │ │
  │ │ < >     IEC61883-6 (Audio transmission) support                     │ │

Modules needed to be loaded if compiling support in kernel is not your thing.

> 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.

Plugreport

  • Below is my plugreport

As evidenced below plugreport can give bogus and deceptive information. To identify what nodes are bogus look at the data_rate. It is identified by data_rate=0 for the bogus connections.

Host Adapter 0
==============

Node 0 GUID 0x00023c0091014e9e
------------------------------
oMPR n_plugs=2, data_rate=0, bcast_channel=63
oPCR[0] online=0, bcast_connection=0, n_p2p_connections=0
        channel=0, data_rate=0, overhead_id=0, payload=0
oPCR[1] online=0, bcast_connection=0, n_p2p_connections=0
        channel=0, data_rate=0, overhead_id=0, payload=0
iMPR n_plugs=0, data_rate=0

Node 1 GUID 0x00159afffeccac5f
------------------------------
oMPR n_plugs=1, data_rate=2, bcast_channel=63
oPCR[0] online=1, bcast_connection=0, n_p2p_connections=1
        channel=0, data_rate=2, overhead_id=0, payload=376
iMPR n_plugs=0, data_rate=2

Node 2 GUID 0x00159afffeccbf56
------------------------------
oMPR n_plugs=1, data_rate=2, bcast_channel=63
oPCR[0] online=1, bcast_connection=0, n_p2p_connections=1
        channel=1, data_rate=2, overhead_id=0, payload=376
iMPR n_plugs=0, data_rate=2

Plugctl

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.

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. Below shows examples of how to do this.

Single STB setup

> plugctl -n 1 oPCR[0].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. Make sure each device is assigned to a unique channel

> plugctl -n 1 oPCR[0].channel=0
> plugctl -n 1 oPCR[0].n_p2p_connections=1
> plugctl -n 2 oPCR[0].channel=1
> plugctl -n 2 oPCR[0].n_p2p_connections=1

This gives me a very reliable and stable connection. When running a daisy chain I cannot stress this hard enough but things are required to be done in a special order, unique channel first followed by point2point. 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.

Broadcast setup

  • Note: Only advised if all else fails.

If you are having issues with using the p2p method you can always attempt the bcast method. This is not reccommended for daisy chain. I found this to be trouble I was unable to set the settings to bcast and have it remain reliable. Also with the daisy chain bcast is a bad idea from what I experimented with. If you wish to use this method you can with the below commands.

> plugctl -n 1 oPCR[0].channel=63  
> plugctl -n 1 oPCR[0].bcast_connection=1  

This should conclude the plugctl configuration and you can chose how you wish to do it, cron did not work in several cases I attempted. The ideal place to add the plugctl settings would be to the mythbackend start up script.

Test-mpeg2

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 on your part 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

Mythtv-setup

When running mythtv setup you will to set your capture device to firewire. Once you do this you should notice the options you can set. It should be pretty self explaining in regards to this. It seems that the default host adapter settings are 0 and node is set to 2. You will want to modify this to match your plugreport settings. Once modified you should have a working firewire system that should be very reliable.

Raw1394 udev

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"

DCT62xx Channel Changes

There are currently two methods known for changing channels on the Motorola DCT62xx series cable boxes. One is employed by MythTV's internal tuning code, the other requires use of the 6200ch program in the contrib/ folder of the MythTV source. If the internal tuning does not work well set MythTV to use 6200ch in mythtv-setup. 6200ch has a few options,

Usage: 6200ch [-v] [-s] [-n NODE] [-p PORT] <channel_num>
-v        print additional verbose output
-s        use single packet method
-n NODE   node to start device scanning on (default:1)
-p PORT   port/adapter to use              (default:0)

make sure to put the correct Node and Port(Host) for the box you wish to control. The -s option is the second tuning method to try.

5C DTCP

DTCP defines a cryptographic protocol for protecting audio/video entertainment content from illegal copying, intercepting and tampering as it traverses digital interfaces such as IEEE 1394... For further reading inquire [1] Here

The point is, most cable company's use 5C to "protect their content", so don't expect to be able to tune in to many if any channels using this method. However, by law, the cable company must not override any 5C flags for local OTA HD rebroadcasts from local commercial network and educational TV stations[2] under the Electronic Code of Federal Regulations.


How to check if DTCP 5C is enabled on Motorola DCT62xx

  • Tune to the channel you are checking for DTCP/5C use.
  • Turn the STB to Standby/Off and press OK/SELECT on the remote within 2 seconds to enter the Diagnostic Main Menu.
  • Use DOWN ARROW and then OK/SELECT to select the "d11 INTERFACE STATUS" option.
  • Look at "5C IMPLEMENTATION". A "0" indicates DTCP/5C is not being used, a "1" indicates DTCP/5C is being used.
  • Press OK/SELECT to go back to the Diagnostic Main Menu.
  • Press Power to exit the Diagnostic Main Menu and Power again to turn the STB back on.[3]

Troubleshooting

If tuning a 5C=0 station and MythTV is not consistant 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)

Closing notes

Setting up firewire to work with mythtv can be very complex if things are not done on a special order. Some people seem to hit the order just properly and do not have problems at all, then others will rip their head off to try to figure out what to do. I created this to help and hope it does, If needed help can be found in #mythtv-users.