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

[Daniel Kristjansson]

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