[mythtv-users] FireWire user? Read me. It's worth it.

Yeechang Lee ylee at pobox.com
Wed Feb 4 06:01:22 UTC 2009


Anyone who's read -users for more than a week knows that FireWire is a
popular subject, almost always for the wrong reasons. Not a week goes
by, it seems, without someone complaining about how a working
connection between mythbackend and his cable box mysterious dies,
requiring various voodoo incantations to revive it. Over the years
there's been lots of talk about faulty PC chipsets (I think it was the
very first -users thread I participated in, way back in December
2005), numerous variants on "pump-priming" scripts, how to use
firewire_tester, etc., etc.

Me? I've always been pretty lucky. Yes, I've had to manually run the
occasional pump-priming script, but a combination of 1) a crontab
entry and 2) a custom channel changer (mythchanger; search for it)
fixes 99% of my lost-connectivity issues before another recording's
attempted on the affected box. I know this isn't the case for many,
many people, though.

I do have one significant issue with FireWire connectivity, which I
recently raised at
<URL:http://www.gossamer-threads.com/lists/mythtv/users/369263#369263>.
Sam's final question at the end of his reply got me thinking. What if
we've all been approaching the FireWire question the wrong way? As I
discuss in the thread, in my case an intentionally-crippled (for
bandwidth reasons, no doubt) analog cable signal leads to a FireWire
connection dropping in a way that mythbackend doesn't notice. The drop
also puts the box into a state where it needs pump priming with
firewire_tester; I'm not sure if it's the drop itself, or
mythbackend's inability to detect the drop, that kills the box.

Note my words above: *A crippled cable signal.* This matters, because
my cable company does *not* alter digital channels' quality. All my
over-the-air HD channels come through at the full OTA bitrates over
cable (~7.5MB for 1080i, for example). Same for HDNet/HDNet
Movies. HBO, Showtime, and other premium-movie channels come in at
about 65% of this, but I think that's the way my provider receives
them in the first place. Bottom line: My provider doesn't
bandwidth-throttle digital channels, *and I don't have a problem with
digital channels killing FireWire*.

What if the reason why so many peoples' FireWire connections die so
often is because so many (Most?) cable companies do, in fact, throttle
their OTA and other digital cable channels? Is there a bug in the
DCT-6200 and other cable boxes' software that randomly interrupts
FireWire connections when the current channel's signal (whether analog
or digital) is below a certain quality threshold?

If so, there are two conclusions:

A) The FireWire signal drops, then quickly returns; the FireWire
   recorder within mythbackend just needs to be more lenient, perhaps
   by increasing a timeout or something. This in turn prevents the
   cable box from seizing up.
Or,
B) There's nothing can be done on the mythbackend side because it's a
   bug on the cable box-software side that causes the box to seize up
   until reprimed.

I am hopeful A) is the case but fear, based on available evidence,
that B) is more likely. If B), then it can theoretically be
accomodated to some degree by incorporating firewire_tester's priming
functionality into mythbackend,[1] but it will a) guarantee a few
seconds of lost signal and b) require as prerequisite better
connection-loss detection by mythbackend, which I don't know the
feasibility of.  The best solution is a software fix by Motorola and
other cable-box makers, but I wouldn't hold my breath.

[1] mythtv-setup's setting to permit mythbackend to reset the FireWire
bus if a box doesn't respond isn't ideal because doing so interrupts
all ongoing connections, which poses a problem for those like me with
more than one FireWire cable box.

-- 
Yeechang Lee <ylee at pobox.com> | San Francisco CA US


More information about the mythtv-users mailing list