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 <[email protected]> > 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 <[email protected]> > > 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
