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
