Thanks Lorne! (and Mike :) ) Yes, that helped clearing up some things... Gonna try it as soon as possible.
/Tomas 2010/9/6 Lorne Shantz <[email protected]> > 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 <[email protected]> wrote: > > > From: Tomas Hylander <[email protected]> > > Subject: Re: [pvrusb2] problem with a hvr-1900 > > To: "Communications nexus for pvrusb2 driver" <[email protected]> > > 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 <[email protected]> > > > > > 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. > > > > > > > > > > to...@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 > > > [email protected] > > > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > > > > > _______________________________________________ > > pvrusb2 mailing list > > [email protected] > > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > > > > > _______________________________________________ > pvrusb2 mailing list > [email protected] > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
