[pvrusb2] problem with a hvr-1900
Lorne Shantz
lorne_shantz at yahoo.com
Sun Sep 5 20:45:03 CDT 2010
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
>
More information about the pvrusb2
mailing list