[mythtv] ticket 5278 locked?

Herb Peyerl hpeyerl+myth
Sat Jan 23 15:23:17 UTC 2010


I'm affected by bug 5278 and have been working on isolating the  
problem.  I was encountering the problem fairly regularly with my two  
DCT-6200's and found what I identified as a potential solution but I  
noted (in the bug) that the fix still had some problems and required  
someone with more knowledge in the area to address... Later, (earlier  
last week), I discovered the problem still existed and is tickled by  
faulty hardware.  Unfortunately, someone (robertm) has gone and locked  
the bug; presumably because it has turned into a bit of a discussion  
forum...

Now it looks like the errant fix is scheduled to hit 0.23 but I'd like  
to emphasize that my fix is not wholly correct.

In one of the comments I note:

> There's one problem with my diff however; and that is cooked1394_read 
> () will time out after 20*20ms read attempts. After 2 of those, we  
> could return from rom1394_get_guid() with a bogus guid... We should  
> probably still use the guid_timer to detect this condition and do  
> something smart; but I'm not sure what 'something smart' is in this  
> case...

...and this is the comment I tried to make this morning before  
discovering the ticket was locked:

> So this condition appears to be tickled by a failing DCT-6200.  In  
> the event of a hardware problem, mythbackend still gets itself into  
> a state where it needs a restart even if the bad receiver is removed  
> from the equation.  So the above fix only masks the problem. Someone  
> who understands the code surrounding this needs to figure out what  
> to do when rom1394_get_guid() times out and returns a bogus guid.   
> Perhaps disable the receiver in question from mythbackend's  
> configuration and log it.   So this bug isn't yet resolved and I  
> lack the expertise to address the real issue.

If someone smarter than me in this area of the code wants to work with  
me and my bad hardware to make mythbackend more robust in the event of  
a firewire failure, then I'm happy to take the issue offline with  
them...

This looks like a moderate traffic list so I'll probably procmail it  
into the background; so private replies would probably be found more  
quickly by me.

Thanks

--hp


More information about the mythtv-dev mailing list