On Fri, 22 Aug 2008, Dan Bodoh wrote: > On Fri, Aug 22, 2008 at 10:32 AM, Mike Isely <[EMAIL PROTECTED]> 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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
