[pvrusb2] mythtv and wintv-hvr-1950 - analog/digital scanning

Tue Jan 6 20:02:43 CST 2009

OK... keeping things simple... :-)

as root...

* mythbackend off

* plug in HVR-1950, creates /dev/video0

* enum_val shows all inputs - no narrowing

* set cur_val to composite and attache video player to hvr-1950

* cat /dev/video0 > /tmp/foo
       stderr...
           cat: /dev/video0: Input/output error
       /tmp/foo...
           empty
       /var/log/syslog...
           Jan  6 21:00:39 vao1420 kernel: [ 3031.735288] pvrusb2:
WARNING: No decoder present

Cool... at least I noticed some feedback in the log when I did the cat.

On Tue, Jan 6, 2009 at 8:23 PM, Mike Isely <isely at isely.net> wrote:
> On Tue, 6 Jan 2009, fivenote wrote:
>
>> Great tips. Here's what I found...
>>
>> I disabled mythtvbackend and used sysfs interface to control the
>> driver. I also confirmed it is creating /dev/video0.
>>
>> The enum_val shows all 4 inputs (dtv, television, composite, svideo).
>> For fun I restarted mythbackend and mythtv and watched enum_val narrow
>> successfully between dtv and television. DTV signal came through, but
>> still no television signal came through.
>>
>> I disabled mythtvbackend again and checked sysfs. All four inputs
>> showed, meaning nothing was left open and narrowed.
>
> OK...
>
>
>>
>> I switched cur_val to 'composite' and hooked up a video player to the
>> HVR-1950's composite input. mplayer still didn't work. I tried xine
>> and it says "There is no demuxer plugin available to handle
>> '/dev/video0'. I'll try to figure out what that is. Any hints are
>> welcome.
>
> Did you get the same failure as before with mplayer?  Or is it different
> now?
>
> But forget mplayer.  The *easiest* thing - by far - to try is just to
> cat the device node, as you tried before.  That should always do
> something noteworthy.  You said you tried that before and got an EIO
> ("input/output error").  I am 99% certain you got that EIO because
> something else was streaming from the device at that time.  There is
> very little other reason for this occur.  Inability to tune does *not*
> result in an EIO.  Ever.  You should get something.  So, given that
> you've confirmed now that you've cleared everything else out of the way,
> does "cat /dev/video0 >/tmp/foo.mpg" still result in an EIO?  It should
> not.
>
> As for xine, the error you report sounds a lot like xine tried to open
> /dev/video0 as a DVB node, which is a wrong thing to do.  The node
> /dev/video0 is the V4L interface and attempts to open that with an app
> that tries to treat it as a DVB interface will only result in failure.
> The DVB interface path is entirely different; it is part of the DVB
> interface standard ("/dev/dvb/adapter0/....").
>
> If you try to 'cat /dev/vide0 >/tmp/foo.mpg' - given that NOTHING else
> is trying to stream from the hardware - and you still get an EIO, then
> that's noteworthy.  More likely the cat command will do something more
> useful, either result in a file full of video snow or a black screen, or
> it will just block generating no data (which you can interrupt), or it
> will fail with some other error.  (Or it might even work.)  Knowing the
> results of this is a big clue.  Definitely try this with the input
> selection via sysfs set to composite.
>
>
>>
>> Meanwhile... fyi... When I installed v4l drivers, it had it's own
>> pvrusb source and replaced the one I downloaded from Mike's site. Is
>> there a difference between the pvrusb2 source at Mike's site and
>> LinuxTV? Which is more current. I figure this is worth mentioning so
>> we know what source I'm running.
>
> They are both completely current.  The differences (when comparing the
> latest versions of each) are compatibility:
>
> The standalone driver has a lot of extra bits and pieces that allow it
> to compile and work correctly for all known Linux kernels back to
> 2.6.12.x and all known corresponding versions of v4l-dvb (i.e. those
> that work with those kernels).
>
> The in-v4l driver is trimmed to contain only that which is relevant to
> the specific surrounding code in the v4l-dvb snapshot.
>
> The in-kernel driver is further trimmed to contain only that which makes
> sense for the specific kernel version it was bundled with.
>
> Feature/function/stability wise, all three are equivalent.
>
>
>>
>> Thanks for all your help. I'm learning more each time and hope to
>> figure it out soon.
>
> You are trying to debug a confusing problem.  First step to solving the
> issue is to remove the confusion and simplify things down.  When
> testing, only change one variable at a time.  Be methodical about what
> you try - don't just do random combinations of things but try simple
> things first and build up from there as you verify the setup.  For this
> reason, FORGET MythTV right now.  And don't bother with mplayer (yet).
>
> Right now you don't even have the simplest case working, so focus on
> that first before dragging in everything else.  Use the sysfs interface
> to control the device and use cat to stream from /dev/video0.  Stick to
> the composite input and forget the RF tuner.  Make sure you can 'cat
> /dev/video0 >/tmp/foo.mpg' and that you get a non-zero file result.
> Then examine that /tmp/foo.mpg file with mplayer.  If mplayer then shows
> you have valid video, only THEN do you introduce other factors.  For
> example, I'd probably then try running mplayer directly on /dev/video0,
> and if that now fails re-read the pvrusb2 driver's web page notes about
> mplayer and make sure you are using it correctly - because if cat works
> then there's nothing wrong with the driver that should keep mplayer from
> working.
>
> Once you've got mplayer working with /dev/video0, then I'd turn my
> attention to the RF tuner and see if you can receive a broadcast.
> (Note: US citizens using OTA broadcasts only get until roughly middle of
> this February to do that test...)  Once you verify that then you've
> proven that the entire analog side of the device is healthy.
>
> Next I'd turn my attention to the DVB side.  You had that working with
> MythTV before so it's probably fine.  But for the record, one test I've
> done on the DVB side is to download and build the dvb-apps repository
> and use the azap utility to open the DVB interface and lock a station
> and then use mplayer to stream via the corresponding DVB interface.
> (This technique is not specific to the pvrusb2 driver; any utility /
> trick you can do with a DVB device will work here.  So just try
> something simple.)
>
> Remember, we're not throwing random stuff at a wall to see what sticks.
> You need to build a picture of what is going wrong, and you have to
> build it up starting with simple things, adding more factors as the
> simpler stuff is verified.  These are good things to remember any time
> you're trying to diagnose a problem anywhere, not just with this driver.
>
> Hope that helps.
>
>  -Mike
>
> --
>
> Mike Isely
> isely @ pobox (dot) com
> 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
>

-- 
~~~~~~~~~~~~~~~~~~~~
VAO - fivenote at gmail.com
~~~~~~~~~~~~~~~~~~~~