[pvrusb2] Two PVR USB2 unit initially tune PAL as black and white

[Mike Isely]

On Wed, 4 May 2011, Tom Warren wrote:

> Greetings,
> 
> I have two WinTV PVR USB '24xxx' boxes I'm using with the pvrusb2 driver
> which feed into tvheadend to stream PAL cable channels to xbmc. The set up
> works but I always get the first tuned channel in black & white and have to
> tune to one (or more) different channels and then go back to the original
> channel get colour. Occasionally a channel will later go black and white
> again and I must apply the same fix.

Hmm.  Sorry I didn't notice this post when you first sent it - over a 
month ago :-(

> 
> Could this be a driver problem, hardware problem, or fine-tuning problem??
> 
> I saw a post from 2006 that describes a similar issue using NTSC:
> 
> http://www.isely.net/pipermail/pvrusb2/2006-January/000384.html

Yes, I remember that well.  The root cause was defective hardware.  I 
spent weeks trying to find a bug in the driver and eventually came to 
the conclusion that it just wasn't possible for the driver to do this.  

Then I tried the obvious and ran the tuner under Windows, using the 
Hauppauge-supplied software, and sure enough same problem...  Then I 
RMAed the unit.

For analog video, there is an interesting history which might play into 
this issue.  See long long ago before the advent of color TV, there was 
basically one video standard.  But with color came along different 
countries adopted different schemes to encode the color information.  
That's really the big difference between NTSC vs PAL vs SECAM - 
different color information encoding.  The outward effect of this is 
that if the video standard is set "wrong", what you will see will in 
fact be a picture (perhaps distorted but a picture nonetheless) but it 
will be black and white.  That's because with the wrong video standard 
set, the hardware will be using the wrong mechanism to find the encoded 
color information and thus it won't find anything, falling back to a 
black and white image.

The point here is that there really isn't anything in the driver that 
can be used to "get rid" of the color component of the video.  The only 
ways this can happen really comes down to these scenarios:

1. Wrong video standard in use

2. Selecting S-video and having a loose/unconnected wire for the chroma 
lead, or a defective s-video cable (because the color is pre-separated).

3. Defective hardware.

Back in 2006, I went crazy looking for a non-existant case (4) after 
ruling out (1) & (2).  It never occurred to me to test for (3), but it's 
really easy to test for by running it under Windows: If totally 
different software still produces the same wrong results then it 
obviously can't be the software at fault.  When I finally figured out it 
was (3) I was ready to smack myself for wasting so many weeks chasing a 
ghost!


> 
> I'm running Ubuntu server 10.10 64-bit with the driver from
> linux-s2api-tbs6980-1_20101024 (commercial mod for the Tenow International
> TBS6981 dual satellite card) in which I made a small modification to set:
> 
> .pixelformat    = V4L2_PIX_FMT_MPEG,
> 
> ...in the pvrusb2-v4l2.c file in order for tvheadend to recognise it as a
> valid source.

A very very long time ago I instituted that change in the driver - and 
then discovered that xawtv no longer worked with the driver.  So I 
backed out the change and it's been that way ever since.

I'm unfamiliar with "tvheadend".



> 
> Since both boxes behave the same way, I suspect this is an issue with the
> driver. What can I do to debug the issue further?

Two different pieces of hardware with the same wrong behavior?  I wonder 
if this might be some kind of variation of (1) above.

  -Mike


-- 

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