[pvrusb2] WinTV USB2/Tv-Viewer question

[Mike Isely]

On Tue, 27 Aug 2013, Lorne Shantz wrote:

> I have done some more tinkering... It seems to be related to the composite cables coming from the vcr player. ? Tv-viewer would not play. I'm getting a lot of this below:
> 
> 
> [19727.089020] pvrusb2: ***WARNING*** device's encoder appears to be stuck (status=0x00000003)
> [19727.089023] pvrusb2: Encoder command: 0x81
> [19727.089024] pvrusb2: Giving up on command.  This is normally recovered via a firmware reload and re-initialization; concern is only warranted if this happens repeatedly and rapidly.
> 
> Routinely testing, I removed the cables from the vcr player and up it comes. ??  So it is intermittent it seems. I have recorded stuff from the vcr, but something seems amiss. Is there such a thing as a firmware update for these devices?
> 

I have over time seen later versions of the mpeg video encoder firmware 
bundled with later models of the device (any of the devices, actually).  
The fwextract.pl script recognizes a number of variants.  However I 
personally have never really seen any improvement (or degradation) in 
behavior of that encoder correlated with firmware revision.  Generally 
speaking, the different mpeg encoder firmware variants floating around 
all seem to be interchangeable, and the pvrusb2 driver doesn't make any 
attempt to discriminate among them.

As for the "...apears to be stuck..." message, that is what happens when 
the pvrusb2 driver attempts to issue a command to the mpeg encoder and 
the encoder fails to acknowledge it.  (There's a sort of shared memory 
mailbox interface which uses a sort of handshake protocol for issuing 
commands to the encoder.)  From all outward behavior at this point, the 
encoder appears to be crashed.  I've only ever seen this happen when the 
command is issued to start streaming and there has NEVER been any 
pattern to it that I could find.  It's just generally been random with a 
low probability.  The pvrusb2 driver always recovers this case by 
quickly reseting the encoder and reloading its firmware.  It's hackish 
but the whole recovery happens in less than a second and because it only 
ever seems to happen when streaming is started, it never actually causes 
lingering problems.  Back when I first encountered this behavior (way 
back around 2005) I spent a LONG time trying to characterize it so that 
I could understand its cause.  I never did find the root cause.  
Instead, the workaround (i.e. reboot the encoder) all along seems to 
have been good enough.  Some day if I could ever get a good look at the 
source code for that encoder firmware, it might be possible to finally 
suss out what's really going on.  But I doubt that day will ever come 
:-(

I have over time seen some reports where people have gotten frequent 
rapid bursts of this problem happening.  In all cases that I remember, 
it was never pinned down to be a real encoder problem.  Rather some have 
found that cleaning up glitchy power has helped - the mpeg2 encoder is 
probably the most complicated and definitely the most power hungry chip 
in the device so it might be the most power sensitive as well.  It might 
also be a sign over overheating.  I've also suspected over time that if 
the mpeg encoder fails to get a "clean" digital stream from the upstream 
pipeline stage (the video digitizer) - perhaps because of problems with 
video sync - that this might cause the mpeg encoder to behave badly.  
But I've never been able to prove it.

  -Mike


-- 

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