[pvrusb2] // 0 byte mpegs //

[Mike Isely]

On Mon, 22 May 2006, Julian Oliver wrote:

> ..on Mon, May 22, 2006 at 01:24:56PM -0500, Mike Isely wrote:
>>
>> See if you can find evidence that the cx23416 firmware has been loaded.
>>
>> The symptoms you are seeing are what will generally happen if the device
>> can't stream for some reason.  (Yeah, obvious.)  There are multiple
>> possible causes for this, basically anything in the pipeline which isn't
>> functioning correctly will result in a lack of streaming.  Given that you
>> had this working on another machine means the hardware is fine.  The log
>> output is suggestive that the various chip level drivers are OK too.  Look
>> further up in your log and see if the cx23416 firmware got loaded; without
>> that streaming definitely won't work.
>
> hey thanks again Mike. my fault, i lost track of this driver. it's in my
> /etc/modules now and it all loads fine.

Glad to hear you got the problem solved.

BTW, I just scanned my IRCs logs.  Saw you pop into #pvrusb2.  During the 
day I can't really answer there because I'm at work but I stay logged in 
there when I'm away so I can pick up any chatter that might have happened 
there.  If anyone sees me there you can tell if I'm actually around by 
doing a "get info" (or whatever your client supports) on my nick.  There's 
an away message set there if I'm not actually there...

I also saw your chat in #v4l.  There was one interesting question that 
mkrufky wasn't sure about regarding cx25840 stability fixes that went into 
2.6.16.  That was a problem in cx25840 that caused it to do bad things to 
the pvrusb2 driver (in a nutshell: it stomped on pvrusb2 internal state). 
The problem has been fixed in cx25840, but the current version of the 
standalone pvrusb2 driver (i.e. the one you download from isely.net) also 
contains a workaround that makes it immune to such abuse from cx25840. 
Look at the change history on the pvrusb2 web set and you'll see a 
description of this.  So nothing to worry about there.  The in-V4L version 
of the pvrusb2 driver does not have this workaround, but it is completely 
unneeded there since of course the corresponding in-V4L version of cx25840 
has been fixed.

>
>>
>> Another thing you can do is 'cat /sys/class/pvrusb2/*/debuginfo' which
>> will tell you which chip level drivers are actually talking to the pvrusb2
>> driver - something beyond just knowing that those modules have been loaded
>> into this kernel.
>
> great to know, and i appreciate the verbose response - will no doubt serve
> as a point of reference again in future.

Yeah, and I need to update the FAQ.  It would probably also be a good idea 
to put together a list of debugging tips & techniques along with perhaps a 
list of "easy and obvious things to check for" when the driver doesn't 
work...

I probably should also fix the driver to not report "successful 
initialization" when in fact it had failed to load the cx23416 firmware 
:-(

   -Mike

-- 
                         |         Mike Isely          |     PGP fingerprint
      Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                         |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                         |                             |