[pvrusb2] problem with a hvr-1900

Sun Sep 5 11:57:23 CDT 2010

Hi!
Thanks for your reply.
Im sorry I missed out that it is the analog-part of the hvr-1900 Im trying
to get going.
Im running a dual-core Atom mini-itx with Nvidia ION graphical board. On
this Ive installed latest Mythbuntu based on Ubuntu 10.04lts. So the system
should be up to-date.

Ive read somewhere how to change inputmode (s-video) on vlc, but now when I
need it I cant find it :(  Do you know?  I tried looking into yours sysfs
but must say I didnt understood how to use it (I did find it on my drive
tho).

Im using kernal  2.6.32-24generic.

Thanks in adance.
/Tomas
.
.2010/9/3 Mike Isely <isely at isely.net>

> 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
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>