[pvrusb2] pvrusb2 timeout?

[Mike Isely]

On Fri, 22 Aug 2008, Dan Bodoh wrote:

> 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.

Well it was a thought.  Trying to find a reason for the mpeg encoder to 
fall over dead mid-stream...


> 
> >
> >
> >>
> >> >> 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.

So it recovered in the middle of the recording?  That I do not 
understand.  If the mpeg encoder died at the beginning and the driver 
failed to detect this at that point, then I'm at a loss for what trigger 
could have caused the driver to later on detect the dead encoder.


> 
> 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.

It's important to figure out at what point during the streaming that it 
timed-out.  If it was right at the beginning, then the driver is failing 
to detect this known condition.  If it was in the middle, then you are 
seeing a new type of failure not previously noticed.


> 
> 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...

I agree with your point here.  So it's probably not heat.

  -Mike

-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8