[pvrusb2] Two PVR USB2 unit initially tune PAL as black and white
isely at isely.net
Sun Jun 19 12:07:46 CDT 2011
On Wed, 4 May 2011, Tom Warren wrote:
> 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:
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
> 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.
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
More information about the pvrusb2