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

[Benton Roberts]

(part one - the zero-file-length issue)

Hello, all.

I built my first MythTV box about three weeks ago, and have it working
pretty well. In fact, my only significant problems at this stage are
with the firewire capture from the two Scientific Atlanta 3250HD cable
decoders I rent from Time Warner Cable in Manhattan. This is the first
of three emails I will post to this list describing the problems I've
overcome, and those I've failed to overcome (so far). Though I am quite
new to the MythTV community, I've been reading the mailing list and
combing its archives these last few weeks, so I'm pretty sure that the
information I have to share here will be of value to other MythTV users
with similar problems. There's certainly alot of discussion of this
cable box going on here all the time.

This first email will talk about the "zero file length" capture problem
that plagues so many users of this decoder. The second email will
present a peculiar problem with a two-decoder setup which involves
recording from the higher-numbered firewire node only. And finally, the
last email will describe my experiences setting up independent channel
control of the two decoders. Also in the third email will be a summary
of the hardware and software details of the system on which these
results were produced.

Now, on to the "zero file length" problem. A thorough search of this
mailing list's archives will show that most SA3250HD users encounter
this problem a lot at first, then gradually learn to minimize, and
sometimes eliminate the problem of receiving a zero-byte recording from
this decoder's the firewire port. On the other hand, it seems many users
give up and go back to analog input instead. Most users report that
their SA3250HDs go in and out of the "no-data state" on an infrequent
basis; that is, it works for days at a time, and then stops working
until manual intervention is required to fix the problem. My experience
has so far been this exactly. Through trial and error, I've found a
software-only process to restore the decoder to working condition about
95% of the time. But about one time in twenty, this process will fail,
and a reboot of the cable box is required (press and hold the power
button for 5 seconds).

Before I describe the almost-fix that I've been using, let me first list
the conditions known to cause this zero-byte stream problem:
#1) Tuning the 3250 to a 5C-encrypted channel. Some users report that
after doing this, they have to reset the cable box. But with my system,
I just have to tune to a clear channel and reset the bus; and sometimes
even the bus reset isn't required -- I just tune back to a clear channel
and the stream is restored.
#2) Tuning to a channel which you have not subscribed to, encrypted or
not. If I do this, I always have to go through my software-only fixing
process, and sometimes I have to reboot the cable box first.  :(

Now, here is the process that restores either of my SA3250s to working
condition about 95% of the time...

First, a test to determine whether a firewire bus reset is required. I
use the excellent firewire_tester program, compiled from
/usr/share/doc/mythtv-0.20/contrib, according to its README. I invoke it
like this:
    firewire_tester -vp -P [port] -n [node] -r 4
On my setup, if this command fails after the tuner has been stable for
about 2 seconds, there's a 100% chance I'll get a zero-length file from
that device using test-mpeg2, and that Mythbackend will report "No input
after 15 seconds". Conversely, if the above command succeeds, I've
gotten good data from the decoder about 95% of the time (sample size is
still <100 recordings, though). So that's the test that works best for me.

The second thing that's needed is a way to (sometimes) get rid of this
problematic condition. Once again following the advice of those who have
gone before, I tried tuning to a known "Clear Channel" (use a broadcast
network) and then resetting the firewire bus in question. For me, the
reset command is:
   firewire_tester -v -P [port] -n [node] -R
This command always reports success, but works to restore input only
about 75% of the time. However, that means if I do it several times
until the preceding test is passed (with a small delay in between
resets), I can get rid of the problem within "a few" tries "most of the
time" (like my math?). So my channel-changing logic is:
    * Test the connection with the tester. If it works, just tune to the
desired channel
	* If it doesn't work, tune to the known clear channel, then reset the
bus until it does
	* However, give up after N bus-reset attempts (currently set at 3).

And here's my channel-changing script, which expresses the that logic.
As mentioned above, it depends on the presence of the firewire_tester
program. For my setup, it also depends on a slightly-enhanced version of
the sa3250ch channel-changing program from Myth CVS -- basically I just
added support for -p [port] and -n [node], so that I could control my
two decoders independently.

* Source code for the modified sa3250ch channel changer:
http://bentonroberts.com/personal/media-server/code/sa3250ch-BR.c

* Tuner shell script invoked from MythTV, which calls sa3250ch with the
-p parameter:
http://bentonroberts.com/personal/media-server/code/mySA3250change.sh

* Here's a similar script, which tries to find working channels on a
SA3250HD, using the same algorithm:
http://bentonroberts.com/personal/media-server/code/walkSA3250channels.sh
	
While directly monitoring the output signal from my SA3250HD as this
list third script runs, and examining the script's output, I learned
alot about which channels I can get in the clear. The unexpectedly happy
answer: everything that I've paid for (though that's basic cable only),
including HD. However, I've been unable to record at least one of the HD
channels at all through MythTV (Discovery HD Theater), even though I've
recorded two straight minutes of this channel using the above
walkSA3250channels script. I will report more data on this issue in a
future "Time-Warner Manhattan" thread.

So, that's how I got "pretty reliable" firewire output from ONE of my
two SA3250s. Your comments, questions, and advice are welcome.
Especially since, unlike the next two emails in this thread, the
problems raised in this message are so far unresolved. Particularly
valuable would be any suggestions on debugging methodology. I've made a
spreadsheet to track failed recordings by time, channel, previous
channel, encoder, and a few other fields, but no obvious correlations
have jumped out at me yet. Anyone here ever apply a firewire protocol
analyzer, or some other reverse-engineering tool, to this problem?
Thanks in advance for your collective wisdom.

Next up in "SA3250HD Firewire -- A New User's Findings": my problems
with adding the second decoder.

- benton