No subject

a file or to a running program does not matter AT ALL.  The driver and 
the hardware simply can't tell the difference.

However there is another explanation.  Go here:

http://www.isely.net/pvrusb2/usage.html#V4L

and scroll down to the last paragraph about using mplayer.  The summary 
there is basically that if the device hardware's streaming gets paused / 
broken for short intervals then mplayer gets confused and starts 
misbehaving.  There are various legitimate reasons for streaming to 
temporarily "stick" - one is a weak signal that causes the hardware to 
lose video lock.  Or interference can do that.  The surefire telltale 
that this is happening is if you stream to a file and then play back the 
file then the problem goes away.  That's because when you play back the 
file there's no longer any real-time breaks in the stream - mplayer 
might see a "jump" in the data but it never has to wait to get the next 
chunk of bits.  That's different than grabbing from the hardware, where 
a break can cause the driver to stop delivering bits for a few moments.  
(I pulled my hair out on this issue for at least a month before I 
finally understood it.  This misbehavior seems to be specific to 
mplayer; vlc seems not to have a problem with real-time breaks.)

I saw in another post that you have data showing repeated 
reinitialization of the encoder.  That's another thing that can cause 
temporary disruptions in the streaming.  Unfortunately I don't have a 
really good handle on that.  There are two possible explanations for an 
encoder having to be reinitialized:

1. You just started to stream and the encoder failed to respond.

2. Something else caused the encoder to crash.

Case (1) is pretty well understood and the driver does a good job of 
recovering.  But in case (1) mplayer won't have a problem because the 
"pause" triggered by the recovery happens before the first bits are even 
emitted, in which case there really isn't any kind of pause (just a 
slightly delayed start which is fine).  I do not know what specifically 
causes (1), but in 3 years of working with the hardware, it *always* 
recovers and the device continues to function fine after that point.  
Case (1) never happens while streaming is already underway - only when 
you first start.  This is likely a bug in the encoder's firmware, but I 
don't have source code for it so there's no way I can debug this.  Odds 
are this sort of issue is probably not even noticed on the Windows 
side...

Case (2) is very very rare.  I personally have never seen it happen.  
Not including yours, I have seen just a couple reports of this on the 
list here but I've never been able to reproduce it.  I have some 
suspicions however.  Possibly this is a sign of a real hardware problem 
or other disruption within the device.  The encoder chip is the major 
consumer of power within the device and it appears to be the most 
sensitive of any chip there.  It is also the part that dissipates nearly 
all of the heat (this part is the reason why the device requires 
external power and can't draw juice from the USB cable).  So if the 
device is getting too hot or if there is a power glitch, I imagine the 
encoder will be the most likely victim.  I'd check really carefully that 
the device is getting clean power (remember that little wall-wart is not 
nearly so forgiving as a PC power supply), and I'd make sure that air 
can flow freely around the device's enclosure.

Hope that helps.

  -Mike


-- 

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