[mythtv-users] firewire issues
gaberubin at gmail.com
Fri Jan 29 18:23:27 UTC 2010
On Fri, Jan 22, 2010 at 3:18 PM, Gabe Rubin <gaberubin at gmail.com> wrote:
> On Fri, Jan 22, 2010 at 3:15 PM, Jarod Wilson <jarod at wilsonet.com> wrote:
>> On Fri, Jan 22, 2010 at 6:12 PM, Gabe Rubin <gaberubin at gmail.com> wrote:
>>> On Fri, Jan 22, 2010 at 3:08 PM, Jarod Wilson <jarod at wilsonet.com> wrote:
>>>> On Fri, Jan 22, 2010 at 6:03 PM, Gabe Rubin <gaberubin at gmail.com> wrote:
>>>>> I am having issues with reliability from firewire captures these days
>>>>> running fedora 12.
>>>>> I looked in dmesg and have the following line spammed for a bunch of it:
>>>>> "firewire_core: Unsolicited response (source ffc0, tlabel 3c)" The
>>>>> portion after tlabel varies.
>>>> I believe that means the cable box is still sending data after the
>>>> host has said 'please stop'.
>>>>> Any idea what could be going on here?
>>>> Maybe. Is that a DCT-6200 cable box? The upstream firewire maintainer
>>>> mentioned a DCT-6200-specific quirk to me on irc today, which needed a
>>>> work-around in the driver added...
>>> It is a DCT-6200 (or some close variant to that).
>>> I have not had
>>> these type of reliability issues in quite some time (only the
>>> occasional missed recording), so unsure why it is all of a sudden
>>> popping up.
>> Could be that the problem wasn't triggered until a recent change in
>> the firewire driver, as its still evolving (though quite stable and
>> feature-complete now).
>> I'll follow up with Stefan Richter about this one, haven't actually
>> looked at the fix yet... (actually not even sure if its been written
> Should I revert to an older kernel (with presumably an older driver)?
> I know at one point I had to blacklist some firewire stuff because of
> the new stack and I know that you have said that the new stack should
> be stable. I can dig through my old emails to see what I did to
> blacklist and determine if it still is (that was a long time ago and
> perhaps my upgrade to Fedora 12 did away with the blacklisting;
> however, I did not affirmatively do anything on that). Should I check
> into that?
I wanted to check in on this again. The problem has become more
pronounced over the last week where I can only get one firewire
recording (sometimes not even that) and then the firewire connection
goes to hell until I reboot. Any idea what could be causing this?
As another data point, even though myth can access and change the
channel, i get this error with firewire_tester
[mythtv at localhost ~]$ firewire_tester -B -n 0
Failed to create new raw1394 handle on port 0
And it appears port 0 is where I should be testing:
[mythtv at localhost ~]$ plugreport
Host Adapter 0
Node 0 GUID 0x001e46fffe3057b3
oMPR n_plugs=1, data_rate=2, bcast_channel=63
oPCR online=1, bcast_connection=0, n_p2p_connections=0
channel=63, data_rate=0, overhead_id=0, payload=376
iMPR n_plugs=0, data_rate=2
Node 1 GUID 0xb35730fefe3057b3
libiec61883 error: error reading oMPR
libiec61883 error: error reading iMPR
More information about the mythtv-users