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

Tue Jan 6 17:09:52 CST 2009

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.

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.

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.

Thanks for all your help. I'm learning more each time and hope to
figure it out soon.

On Tue, Jan 6, 2009 at 2:18 AM, Mike Isely <isely at isely.net> wrote:
>
> Vincent:
>
> Additional comments and ideas are laid out below...
>
> On Mon, 5 Jan 2009, fivenote wrote:
>
>> Thanks.
>>
>> I tried running /usr/bin/mythtv-setup.real -v all. Got lots of output
>> but no obvios problems.
>>
>> I went back to basics and tried to get data from the device. I
>> shutdown mythbackend and did...
>>
>> >cat /dev/video0
>> cat: /dev/video0: Input/output error
>
> I'm assuming that /dev/video0 is your device - do an "ls -l /dev/video*"
> and make sure you get back what you expect, e.g. if there are multiple
> entries make sure you are talking to the right one.  And there *can* be
> multiple entries even for a single device if you unplugged the device
> from the USB spigot while someone was operating it.  In that case, the
> old /dev/video0 can't go away until the entity hanging onto the open
> device handle has exited (perhaps some piece of mythtv is still not
> letting go).  Then when you plug it back in, the "new" instance will
> become /dev/video1 because /dev/video0 is still allocated to something
> else (i.e. the previous dying driver instance due to the previous unplug
> event).
>
> But assuming that /dev/video0 is correct...
>
> EIO ("Input/output error") will happen if the stream can't be started.
> This is NOT what happens if you can't receive any video.  In that case
> the stream will start but you won't receive any data (it will just
> stall) or you'll receive noise for video (depending on the situation).
> The fact that you got an EIO strongly suggests that streaming failed
> because something else already has the device open.  And that something
> else doesn't have to be someone with /dev/video0 open - it might be a
> process operating the DVB side of the device.  The HVR-1950 hardware is
> shared between V4L and DVB so if one side is trying to stream (even if
> only to acquire a signal lock in the case of DVB) then the other side is
> kept out of the way.  You said you shut down the mythtv back end, but it
> sure sounds like that didn't entirely work.  I'll bet you've got
> something hanging onto the DVB side.
>
> Try cat'ing /sys/class/pvrusb2/*/ctl_input/enum_val and see what input
> choices are in the list.  If you're only seeing "dtv" that means the
> input selection has been narrowed because the DVB interface is active -
> somebody is accessing it.  That would explain the behavior you are
> seeing.  To understand what I mean about "narrowing", go here:
>
> http://www.isely.net/pvrusb2/usage.html#Interactions
>
> and then scroll down to the section titled "V4L vs DVB interactions".
>
>
>>
>> and...
>>
>> > mplayer /dev/video0
>> MPlayer 1.0rc2-4.3.2 (C) 2000-2007 MPlayer Team
>> CPU: Intel(R) Core(TM)2 Duo CPU     T5450  @ 1.66GHz (Family: 6,
>> Model: 15, Stepping: 13)
>> CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
>> Compiled with runtime CPU detection.
>>
>> Playing /dev/video0.
>> Win32 LoadLibrary failed to load: avisynth.dll,
>> /usr/lib/win32/avisynth.dll, /usr/local/lib/win32/avisynth.dll
>>
>>
>> Exiting... (End of file)
>> -------
>>
>> Both of these used to work before I updated to the latest v4l drivers.
>> I don't know what else to try.
>>
>
> However we really need here to separate questions of what is going on in
> MythTV versus what is going on in the driver.  You are raising issues
> and we can't tell who is causing what.  I think given the confusion you
> are experiencing that you should unambiguously kick the applications out
> of the way and focus your attention purely on the driver.  Only then,
> after we know the driver is healthy, should you bring MythTV back into
> the puzzle.  So do this:
>
> 1. Disable the mythtv backend from even starting (i.e. rename the binary
> so that a system boot script can't start it without your knowledge).
>
> 2. Unplug the HVR-1950 from the USB port.
>
> 3. Reboot your system.
>
> 4. Plug in the HVR-1950.
>
> The idea for the above is not so much to reset the hardware but to start
> up in a way that gives high confidence that nobody is trying to access
> the device "behind your back".  Everything should come up clean and
> nobody should be trying to use the device, DVB or V4L.
>
> Now run through some of the usual tests with the V4L side.  Try mplayer
> while using the syfs interface to control the input selection and tuning
> frequency (again, see the above page for information about those
> interfaces).  If after that you are still having analog tuning problems,
> peel back another layer: plug a composite video source into the device
> (VCR, DVD player, camcorder, etc) and try to stream from that input.
> An operation like that does not require a working RF tuner.  If that
> works, then we know at least everything except the RF tuner is ok.  Do
> all that first and you can verify that you have working analog hardware.
>
> Then try a simple DVB application for the DVB side.  Verify that works.
>
> If you get past those steps then you've confirmed that the hardware is
> healthy and the pvrusb2 driver and all the various related V4L & DVB
> software bits are all working correctly.  Then turn your attention back
> to MythTV and debug that...
>
>  -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
~~~~~~~~~~~~~~~~~~~~