[mythtv] Firewire STB keeps jumping ports in 0.21-fixes. Suggestions?
w.munson at comcast.net
Sun Feb 17 14:26:03 UTC 2008
Daniel Kristjansson wrote:
> On Sat, 2008-02-16 at 22:03 -0500, William Munson wrote:
>> First off, sorry to post this to the dev list however I have not gotten
>> any answers in the users list.
>> I am testing the 0.21-fixes branch on ubuntu and am running into a
>> situation where if I accidentally tune a bad channel with my DCT6416 STB
>> it will cause the STB to switch ports from 1 to 0 and back again. The
>> port is still stable and firewire_tester will still capture packets in
>> broadcast mode just fine however the backend does not realize that the
>> port has moved even though the UUID is still the same. Am I missing
>> something or is there a bug that causes the backend end to miss the fact
>> that the port has changed? What can I do to troubleshoot this and
>> provide more useful info?
> LinuxFirewireDevice::UpdateDeviceListItem() should update the device
> list when there is a reset, and LinuxFirewireDevice::HandleBusReset()
> should reconnect the device when it calls iec61883_cmp_reconnect(),
> but it doesn't always work. The Linux firewire guys weren't too
> interested in fixing this driver problem when I discovered it (though
> they were helpful in many ways with the firewire code.) They were
> working on a new driver which I understand should be immune to these
> types of problems. I no longer use the firewire recorder, so this is
> not something I've looked into further.
> The OSX FirewireRecorder does recover in these instances. But it has
> it's own problems. The OSX driver devs decided to always issue a bus
> reset when an application starts or stops using firewire, so you end
> up losing portions of your recordings if you have more than one STB
> or have some other firewire devices on the same bus.
> The upshot is that AFAICT the bug is in the Linux Firewire drivers and
> not in MythTV; unless you track down the bug in the drivers yourself
> it is not likely to be fixed until the whole firewire driver stack is
> replaced with the next generation firewire stack. BUT, it has been a
> while since I've been on top of this so you might want to read up on
> the posts in the linux1394-devel at lists.sourceforge.net the next gen
> driver might be in a usable state at this point, or it might have been
> abandoned, and/or someone might have written some patches to fix the
> problem in the existing drivers.
> Searching the linux1394 mailing list for "bus reset" might give you
> something useful...
> -- Daniel
Thank you for the info. One more question. Is there a location in the
database that stores the current port? I was thinking of writing a
channel change script that would take a look at plugreport on each
channel change and update the database before changing channels. If myth
looks at this variable when setting up a recording then I could
dynamically update things whenever I change channel. It would also allow
me to stabilize the connection if required. This looks to be easier than
trying to patch the ubuntu 1394 stack.
More information about the mythtv-dev