[mythtv] Firewire STB keeps jumping ports in 0.21-fixes. Suggestions?

[William Munson]

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.

TIA,
William