[pvrusb2] problem with a hvr-1900

Tomas Hylander tomas.hylander at gmail.com
Fri Sep 10 14:04:50 CDT 2010 

strange, even if it says that root was the owner I coulnt do anything.
Changed so all could read and write so now it works, sort of...

I can change inputs and so but now Im only getting black...
Tried changing to s-video and connected from my sat but still black.
Changed back to television but still black...
Tried changing frequency with

sudo echo "210.250" >ctl_frequency/cur_val
echo: write error: Invalid argument
sudo echo "210250" >ctl_frequency/cur_val
echo: write error: Numerical result out of range

How do I enter the frequency?

Looks strange thats I just getting black...no noise.

/Tomas


2010/9/10 Tomas Hylander <tomas.hylander at gmail.com>

> Hi again!
> Finally got time to test this, just to hit the wall with "permission
> denied" even when running sudo. Ive tried both setting frequency and
> changing to s-video.
>
> Gonna try some more, but if you know what Im missing out, please tell me.
>
> Thanks!
> /Tomas
>
> 2010/9/6 Tomas Hylander <tomas.hylander at gmail.com>
>
> 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
>>>
>>
>>
>

More information about the pvrusb2 mailing list