[pvrusb2] pvrusb2 timeout?

[Dan Bodoh]

On Fri, Aug 22, 2008 at 10:32 AM, Mike Isely <isely at isely.net> wrote:

> Has the room in which the device sits gotten any warmer?  Have there
> been any power glitches that might be different than before (e.g. turn
> on the air conditioner)?

Room should not have gotten any warmer.  I can't really say if there's
been a power glitch recently (in my climate, the A/C has been running
all summer).  I haven't seen problems with any othe relectronic
equipment in the last few days.  We've had some rain, but no recent
thunderstorms.

>
>
>>
>> >> In the kernel logs - nothing at 20:00, but first message after 20:00
>> >> is at 20:41:
>> >>
>> >> Aug 20 20:41:05 mythbox kernel: [888366.618809] pvrusb2: Encoder timed
>> >> out waiting for us; arranging to retry
>> >> Aug 20 20:41:05 mythbox kernel: [888366.618820] pvrusb2: Encoder command: 0x82
>> >> Aug 20 20:41:05 mythbox kernel: [888366.619087] pvrusb2: Error
>> >> recovery initiated
>> >> Aug 20 20:41:05 mythbox kernel: [888366.619091] pvrusb2: Retrying
>> >> device reconfiguration
>> >
>> > Unfortunately that message is "normal".  Every once in a while the
>> > encoder chip will wedge itself when we try to stream with it.  This
>> > behavior has been observed for YEARS, and I've never been able to find
>> > out the trigger.  However the driver detects this and recovers by
>> > reloading and reconfiguring the encoder.  The whole recovery happens in
>> > a second or two.  This timeout only ever happens at all at the moment
>> > streaming is started.  Once it is going, I've never seen the encoder
>> > crash.  The upshot of all this is that while it's an interesting clue
>> > that this happened at the point when you got the backend timeout, this
>> > might not be the "smoking gun".
>>
>>
>> You may have misunderstood.  This message coincided with the point in
>> time when my failed recording successfully restarted (41 minutes in to
>> the program).  So whatever code is behind this message "fixed" the
>> problem.
>>
>
> Wow.  I sure did misunderstand.  This sounds a lot like the mpeg encoder
> chip crashed WHILE streaming.  I've never seen that happen here.  What
> the code you refere to did to "fix" this was to completely reinitialize
> the mpeg encoder chip: The chip is reset, reloaded with its firmware,
> restarted, and then re-sent all the configuration information.

I'm not sure it crashed WHILE streaming (but maybe this is semantics).
 The recording was supposed to start at 20:00, at which time the
timeout messages started and nothing actually recorded.  At 20:41, the
recording finally started, and the MPEG file finally got some valid
bits, which correlated with that reinitialization message.  So the
MPEG file was only 19min long, when it should have been 60 minutes.

According to my Myth logs, the first timeout appears Aug 18, 17:00,
and occurred several times (but not on every recording) until the Aug
20, 20:41 reinitiialization event.  I rebooted both the computer and
power cycled the PVR-USB2 sometime after Aug 20, 21:00 and haven't
seen the problem since.

If it was a heat problem, I'd wouldn't have expected the problem to
suddenly stop after reboot and not re-appear.  Unless a heat event put
some chip into a bad state, which it could not reset out of until
power cycle...

Dan Bodoh