[mythtv-users] SA3250HD Firewire -- A New User's Findings

Benton Roberts benton at panix.com
Sat Apr 28 21:07:42 UTC 2007

(part two - a tale of crossed signals)

Hello again, everyone.

This follow-up to my initial post in this thread describes two
possibly-related conditions which initially prevented me from recording
from my second cable box, whether simultaneously or not. The first
condition is when both boxes are on the same firewire bus (same port,
different nodes), and the second is when they're on different firewire
buses (different ports, same node).

First, the setup with both SA3250HDs on the same firewire bus,
designated port 0. One decoder is assigned to node 0, and the other is
node 1. For some reason, the firewire bus on my Asus M2NPV motherboard
assigns the node IDs starting from the device that's *farthest* from the
motherboard on the chain. This means that if I attach one just cable
box, it gets assigned node 0, but if I then loop my second cable box off
the first, the IDs get reassigned so that the second cable box takes
over node 0, and the first cable box becomes node 1. This can really
mess you up when you're debugging, or when the backend is running. The
moral of the story? Don't do that!   ;)

In fact, I have been completely unable to get a good stream from the
second SA3250 in this configuration. Why? I think it's because the command
    plugctl -n 1 oPCR[0].channel=1
Does not seem to have any effect on either of my cable boxes. Based on
the firewire pages in the Myth Wiki, I'm pretty sure this command is
required to get different decoders working on the same bus, so that
their packet streams don't get mixed up. Right after I run the above
'set' command, I can run the equivalent 'get' command, and verify that
the setting has not taken:
[root at media ~]# plugctl -n 0 oPCR[0].channel
It's still on channel zero! I can't seem to set either node to any
channel other than zero. The result is that when trying to record from
node 1 with "mpeg2-test -r 1 > file.mpg", the file gets filled with a
broken-up version of the packet stream from node 0. It sometimes plays
in mplayer, sometimes doesn't, but what little you can see is clearly
coming from node 0, not node 1. I'm pretty sure the overlapping channel
is responsible for this, but have no idea how to correct this. Anyone?

Finally, I don't think chaining SA3250s this way is a good idea anyway,
because in my experience (see previous email) you have to reset the
entire firewire bus periodically, just to fix one box. So when a bus
reset is required for a non-working box while the the *working* box is
recording, bad things happen to the recording.  :(

OK, on to the second setup, then. Here I use the two decoders on two
different firewire buses, port 0 and port 1 (both cable boxes take node
number 0 in this configuration). In my backend system, the first port is
on the motherboard and the second is an add-in PCI card (see next email
for specs). This configuration fails the test-mpeg2 test, but works fine
with MythTV in practice. It seems there's a command-line processing bug
in test-mpeg2...

When I issue the command
    test-mpeg2 -p 1 -r 0
the system reads data from my PCs firewire port 0, instead of firewire
port 1 as requested. Every time, a perfect capture, exactly as if I had
    test-mpeg2 -p 0 -r 0
instead. If I turn off the cable box attached to port 0, the capture
fails, naturally. Here's some further evidence for non-standard
command-line processing code in test-mpeg2: while the command
"test-mpeg2 -p 0 -r 0" works fine, the equally-valid command "test-mpeg2
-r 0 -p 0" fails, with an arguments error. Bleh!

Anyway, the bottom line is this: my advice to anyone using twin SA3250s
is to put them on separate firewire buses! I hope this will save someone
the vexing hours I spent acquiring this information. Once again, your
input and experiences are gratefully appreciated...

- benton

P.S. Next up, the third and final episode in the now-much-hated series
of rants, "SA3250HD Firewire -- A New User's Findings"

More information about the mythtv-users mailing list