[pvrusb2] problem with a hvr-1900

Fri Sep 3 14:03:48 CDT 2010

On Fri, 3 Sep 2010, Tomas Hylander wrote:

> Hi
> Have been trying to get my hvr-1900 to work but it looks like I cant get it
> to change channel.

In digital mode or analog mode?  The mechanism is different in the two 
cases.

In analog mode, the application has to use the V4L API (i.e. open 
/dev/video0) to change the "channel", and what you're setting is the 
direct frequency for the channel you want (the application, e.g. mythtv, 
and to maintain the mapping between channels and frequencies).

In digital mode, the application has to use the DVB API (i.e. stuff 
related to "/dev/dvb/...") to change the channel, and the notion of 
"channel" there is entirely contained in the DVB subsystem not the 
pvrusb2 driver.  With ATSC reception (a USA thing; I don't know if this 
is the same case with other standards), a "channel" is a combination of 
frequency and program ID selected within the stream.

With analog mode, the pvrusb2 driver is more involved in the process of 
setting the frequency; it receives the API request and passes that 
information to the V4L tuner module.  But in digital mode, complete 
control of the RF tuner section is turned over to the DVB subsystem.  
Beyond providing physical I2C access to the relevant chip(s), the 
pvrusb2 driver is not at all involved in channel selection there.  (The 
fact that the DVB architecture means that DVB has to effectively "own" 
the tuner section exclusively away from the pvrusb2 driver is why we 
have this wierd non-orthogonal thing going on where you have to switch 
APIs when switching modes.)

> 
> Various logs..

   [...]

> [   24.554160] pvrusb2: Set up standard idx=11 name=PAL-K
> [   24.554166] pvrusb2: Set up standard idx=12 name=SECAM-B
> [   24.554172] pvrusb2: Set up standard idx=13 name=SECAM-D
> [   24.554178] pvrusb2: Set up standard idx=14 name=SECAM-G
> [   24.554184] pvrusb2: Set up standard idx=15 name=SECAM-H
> [   24.554190] pvrusb2: Set up standard idx=16 name=SECAM-K
> [   24.554195] pvrusb2: Set up standard idx=17 name=SECAM-K1
> [   24.554201] pvrusb2: Set up standard idx=18 name=SECAM-L
> [   24.554207] pvrusb2: Set up standard idx=19 name=SECAM-LC
> [   24.554214] pvrusb2: Initial video standard auto-selected to PAL-B/G
> [   24.554236] pvrusb2: Device initialization completed successfully.
> [   24.554409] pvrusb2: registered device video0 [mpeg]
> [   24.554418] DVB: registering new adapter (pvrusb2-dvb)
> [   24.620865] cx25840 4-0044: firmware: requesting v4l-cx25840.fw
> [   26.944036] eth0: no IPv6 routers present
> [   27.124735] cx25840 4-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
> [   27.355490] usb 1-2: firmware: requesting v4l-cx2341x-enc.fw
> [   27.656232] cx25840 4-0044: 0x0000 is not a valid video input!
> [   27.706604] DVB: registering adapter 0 frontend 0 (NXP TDA10048HN
> DVB-T)...
> [   27.740746] tda18271 4-0060: creating new instance

Up to this point, everything looks good.

> [   27.741738] tda18271_read_regs: ERROR: i2c_transfer returned: -5
> [   27.741751] Unknown device detected @ 4-0060, device not supported.
> [   27.741982] tda18271_read_regs: ERROR: i2c_transfer returned: -5
> [   27.741993] Unknown device detected @ 4-0060, device not supported.
> [   27.742001] tda18271_attach: error -22 on line 1243
> [   27.742011] tda18271 4-0060: destroying instance

Here a problem has happened :-( The failed driver mentioned above is 
involving in RF tuning...

A while back (a year or more) there was some thrashing about in the 
v4l-dvb subsystem involving proper tuner control for the HVR-1900.  
There have been posts to the list in the past regarding I2C errors 
taking place during tuner initialization, just like what you see above.  
I've never been able to reproduce any of it, but part of the reason may 
be that I'm in the USA and only have an HVR-1950 not the HVR-1900 you're 
using.  But this was a while ago and I thought the issues behind this 
were in fact in v4l-dvb (not pvrusb2) and had been solved.  That being 
the case, you might be using a kernel version that is too old...

Certainly without the ability to control the tuner on the device, that 
would explain why channel switching isn't working.

> tomas at MythCube:~$
> -------------------------------------------------------------------------------
> 
> My plan is to use it with MythTv, Ive set it up bot like a USB-device and
> like a ITVT-device without success.
> Entered my channels manually with MythWeb but only noise when changing
> channel.

I've never had to add channels manually.  In analog mode, I've just told 
MythTV which channel map to use (e.g. "US Broadcast") and for digital 
mode MythTV can scan all the frequencies and pick up the channel 
mappings on its own.

> 
> Tried using VLC, but cant figure out how to set frequency, "vlc /dev/video0"
> just brings same noise.

If you open /dev/video0, then you're in analog mode (using V4L).  Was 
that your intention?  It's still not clear to me whether you're trying 
to use the device in analog or digital mode.

> The red lamp on the hvr-1900 lights up when Im trying to use it, so it looks
> like everything works except changing channel, so thats why Im thinking that
> the problem lies in pvrusb2-driver.

The pvrusb2 driver directly controls the operation of the red LED on the 
device.  In Windows, that LED lights up when the driver is loaded and 
stays lit permanently.  But the pvrusb2 driver will only light the lamp 
when it is streaming video.

FYI, the pvrusb2 driver is always responsible for setting up and running 
the video pipeline, regardless of mode or input.  When you're in analog 
mode, the pipeline is set up to use the mpeg encoder and the pvrusb2 
driver "connects" the dataflow out through the V4L device spigot where 
the application is running, i.e. whoever has opened /dev/video0.  If 
you're in analog mode using the tuner ("television"), then the driver 
connects the video digitizer to the output of the tuner.  If you're in 
analog mode and capturing composite or s-video, the driver connects the 
video digitizer to whichever of those inputs you've selected.  If you're 
in digital mode, then the pipeline is configured to effectively bypass 
mpeg encoding - since it's already digital bits - and its input is 
always connected to the tuner.  The pipeline output however doesn't go 
to a device endpoint; in this case the pvrusb2 driver pipes the data 
directly into the DVB subsystem (where additional processing may take 
place but by this point it's out of the realm of the pvrusb2 driver).

Any time you see that red LED lit, the pvrusb2 driver has the video 
pipeline configured appropriate for the mode and input and is streaming 
data through it.  If you are actually getting a video stream - even if 
it's snow - then A LOT of things are in fact working fine.  If the video 
streaming were not working then you wouldn't get any data at all.

Generally if you can stream video but it's always snow, then it's a 
tuning problem, as you were already guessing.  But to address that one 
needs to look at the tuner driver and possibly also this may be affected 
by whether you're in analog or digital mode (the tuner driver internally 
can behave differently, depending on the driver).

There's an easy experiment you can try to verify if this is really a 
tuning problem: Try to stream the composite or s-video inputs instead.  
In those cases you have to be in analog mode and you have to tell the 
driver to switch inputs.  And obviously you need a video source, e.g. a 
DVD player output, a VCR, camcorder, iPod composite output, whatever.  
You can do the experiment without even needing a V4L app, by using the 
sysfs interface in the pvrusb2 driver.  Information on using sysfs can 
be found here: http://www.isely.net/pvrusb2/usage.html#sysfs

If you can successfully stream one of those inputs, then you've verified 
correct operation of every part of your device except the tuner section 
itself.  That being the case, the pvrusb2 driver is fine.  I'm betting 
that will work for you.  To deal with the tuner, we need to understand 
which kernel version you are running and if you've overlaid a v4l-dvb 
snapshot (which would have a later tuner driver).

> 
> All helps are appreciated since I've been trying for a couple of weeks now
> google around for info...

Let me know if any of the above helps.

  -Mike

-- 

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