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

[William Munson]

Steven Adeff wrote:
> On Feb 17, 2008 9:26 AM, William Munson <w.munson at comcast.net> wrote:
>   
>> 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
>>     
>
> I have a channel change script that uses the Firewire GUID for the box
> in question to change the channel. It doesn't affect the database but
> since I've started using it (to fix 0-byte recordings) I've yet to
> miss a firewire recording. The downside is you have to manually give
> mythtv-setup the GUID of the box in the channel changer field, but
> otherwise it works great.
>
> http://www.mythtv.org/wiki/index.php/User:Steveadeff#6200changer.sh
>
>   
Thank you, that may just do what I need.