[pvrusb2] problem with a hvr-1900

[Tomas Hylander]

Thanks Lorne! (and Mike :) )
Yes, that helped clearing up some things...
Gonna try it as soon as possible.

/Tomas

2010/9/6 Lorne Shantz <lorne_shantz at yahoo.com>

> Hey Thomas,
>
> I hope Mike won't mind me posting this. This is an email from him, so the
> credit obviously goes to him. It greatly helped me understand. Let me know:
>
> There's a "magic" file system area on your Linux system; it is known as
> "sysfs".  The root of this area starts at the /sys directory.
> Everything below that point is *not* a real file.  Rather these are
> "special" files that can be used to do interesting things.  When you
> open and read one of these files, a special function is dispatched
> within the kernel that synthesizes the content on-the-fly as you read
> the "file".  The exact function that is dispatched depends on which file
> you open.  Similarly, if you write to one of these special files,
> another function is dispatched in the kernel that receives the data you
> write and will interpret it in some particular way.  Exactly how that
> interpretation works depends on the function dispatched and the choice
> of function dispatched depends on which file you write.
>
> So effectively by reading and write various things under /sys you can
> retrieve information about your system or influence its behavior.  This
> area is, for example, used by udev to know what devices are really out
> there.  But it has many many other uses.
>
> In the case of the pvrusb2 driver, the path /sys/class/pvrusb2 is the
> root of an area controlled by the pvrusb2 driver.  And it is laid out in
> a manner that gives you the ability to directly query and control nearly
> all the various "knobs" and "switches" within the driver.  Just pick the
> right file and read it to find the knob's state, or write to that file
> to change the knob's state.  It's the same access you can get through
> the V4L API, except in this case the "API" as it were is just the file
> system.  Thus you don't need any special programs to control the driver
> - just use "cat" to read one of the files and "echo" to write new
> values.  The explanation for how these all work can be found here:
>
>       http://www.isely.net/pvrusb2/usage.html#sysfs
>
> So using that interface you can do things like select the input to
> stream from.  For example, this will change the device to capture its
> composite input:
>
>       echo "composite" >/sys/class/pvrusb2/*/ctl_input/cur_val
>
> To go back to television capture, the command would be:
>
>       echo "television" >/sys/class/pvrusb2/*/ctl_input/cur_val
>
> You can get a list of what input keywords are legal with:
>
>       cat /sys/class/pvrusb2/*/ctl_input/enum_val
>
> If you're capturing television input you can set the tuner's frequency
> in Hz just by writing the frequency to ..../ctl_frequency/cur_val (with
> "...." being the same prefix shown in the other examples).  The "*" part
> of the path by the way is just a wildcard; your shell will expand that
> automatically since you only have a single device attached.
>
> This allows you to control the driver without needing a V4L application,
> thus you can eliminate uncertainties caused by bugs in the app.
>
> Now there are two things that sysfs interface cannot do: (1) It can't
> control the DVB side of the driver (which is a non-issue in our case),
> and (2) you can't directly stream from it.  However streaming is
> trivially easy once you have the device configured the way you want -
> just read the stream data from /dev/video0 using cat.  Let's say you
> wanted to capture 15 seconds of video from the composite input.  Here's
> what you can do:
>
>       echo "composite" >/sys/class/pvrusb2/*/ctl_input/cur_val
>       cat /dev/video >/tmp/foo.mpg
>
> then wait 15 seconds and hit ^C to break out of the cat command.  Now
> you should have 15 seconds of video sitting in /tmp/foo.mpg.  You can
> then use mplayer to play it: "mplayer /tmp/foo.mpg".
>
> You can also directly use mplayer in place of the "cat" command as you
> have already discovered.  However I'd advise against that for the moment
> because mplayer can do some very confusing things if the video streaming
> isn't constant - the results will be even more confusing.  By capturing
> to a file and then playing the file we can rule out any funny business
> that mplayer might be trying when the stream breaks up.
>
> Is that enough to get you going?
>
> --- On Sun, 9/5/10, Tomas Hylander <tomas.hylander at gmail.com> wrote:
>
> > From: Tomas Hylander <tomas.hylander at gmail.com>
> > Subject: Re: [pvrusb2] problem with a hvr-1900
> > To: "Communications nexus for pvrusb2 driver" <pvrusb2 at isely.net>
> > Date: Sunday, September 5, 2010, 9:57 AM
> > 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
> > >
> > _______________________________________________
> > pvrusb2 mailing list
> > pvrusb2 at isely.net
> > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
> >
>
>
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>