hdpvr.ko kernel 5.3-rc6

hdpvr.ko kernel 5.3-rc6

[Scott Doty]

Hello,

Hadn't used my Hauppauge HDPVR for a while, decided to check status of
driver.

Doesn't seem to be working now.  Everything initializes okay (afaict),
but it doesn't seem to want to start streaming.

In the past, a command like this has worked for playback:

vlc v4l2c:///dev/video2 \
    --v4l2-chroma=H264 \
    --v4l2-width=1920 \
    --v4l2-height=1080

Running that with -vvv, I get output that includes words to the effect of:

   https://termbin.com/re3q

Running the module with buffer debug on shows the following from dmesg:

   https://termbin.com/u39v

I'm probably in over my head, but if I could hazard a guess, I'd say
there's something awry with the frame rate it is trying to set.  Video
input is off a DirecTV box component input using the SPDIF input.

Also tried mplayer, and I sometimes get a video feed (but it tries to
use hwac3 for my audio, wish isn't going to work with my setup).  In
this case, streaming seems to get started (according to buffer debug),
but output is either nonexistent, or it will play video for a few
seconds then exit.

And from dmesg in that case: https://termbin.com/pwsp

If someone could point me in the right direction, I can try to fix this
-- or if someone has a solution, I'd very much appreciate the help.

Thank you,

 -Scott

Re: hdpvr.ko kernel 5.3-rc6

[Hans Verkuil]

Hi Scott,

On 9/2/19 3:02 AM, Scott Doty wrote:
> Hello,
> 
> Hadn't used my Hauppauge HDPVR for a while, decided to check status of
> driver.
> 
> Doesn't seem to be working now.  Everything initializes okay (afaict),
> but it doesn't seem to want to start streaming.
> 
> In the past, a command like this has worked for playback:
> 
> vlc v4l2c:///dev/video2 \
>     --v4l2-chroma=H264 \
>     --v4l2-width=1920 \
>     --v4l2-height=1080
> 
> Running that with -vvv, I get output that includes words to the effect of:
> 
>    https://termbin.com/re3q
> 
> Running the module with buffer debug on shows the following from dmesg:
> 
>    https://termbin.com/u39v
> 
> I'm probably in over my head, but if I could hazard a guess, I'd say
> there's something awry with the frame rate it is trying to set.  Video
> input is off a DirecTV box component input using the SPDIF input.
> 
> Also tried mplayer, and I sometimes get a video feed (but it tries to
> use hwac3 for my audio, wish isn't going to work with my setup).  In
> this case, streaming seems to get started (according to buffer debug),
> but output is either nonexistent, or it will play video for a few
> seconds then exit.
> 
> And from dmesg in that case: https://termbin.com/pwsp
> 
> If someone could point me in the right direction, I can try to fix this
> -- or if someone has a solution, I'd very much appreciate the help.
>
The only non-trivial change in hdpvr in 5.3 is this commit:

commit 6bc5a4a1927556ff9adce1aa95ea408c95453225
Author: Hans Verkuil <hverkuil@xs4all.nl>
Date:   Thu Jun 20 07:43:41 2019 -0400

    media: hdpvr: fix locking and a missing msleep

Try reverting it and see if it makes a difference.

Also test with 'v4l2-ctl -d /dev/videoX --stream-mmap' and see if it
keeps streaming buffers or if it also stalls.

Regards,

	Hans

Re: hdpvr.ko kernel 5.3-rc6

[Scott Doty]

On 9/2/19 12:31 AM, Hans Verkuil wrote:
> Hi Scott,

Hi Hans!  Thank you for the speedy reply. :)

> The only non-trivial change in hdpvr in 5.3 is this commit:
> 
> commit 6bc5a4a1927556ff9adce1aa95ea408c95453225
> Author: Hans Verkuil <hverkuil@xs4all.nl>
> Date:   Thu Jun 20 07:43:41 2019 -0400
> 
>     media: hdpvr: fix locking and a missing msleep
> 
> Try reverting it and see if it makes a difference.

I should mention that I haven't tried this driver for over a year,
so it's not just the change to 5.3 that we would be talking about.

Tried reverting the commit and built Linux 5.3-rc7+ -- alas, it didn't
change anything.

> 
> Also test with 'v4l2-ctl -d /dev/videoX --stream-mmap' and see if it
> keeps streaming buffers or if it also stalls.

That doesn't seem to work:

$ v4l2-ctl -d /dev/video2 --stream-mmap
New timings found
VIDIOC_REQBUFS: failed: Inappropriate ioctl for device

I suspect I might have to do a git bisect to find where the problem started.

 -Scott

Re: hdpvr.ko kernel 5.3-rc6

[Hans Verkuil]

On 9/3/19 5:45 AM, Scott Doty wrote:
> On 9/2/19 12:31 AM, Hans Verkuil wrote:
>> Hi Scott,
> 
> Hi Hans!  Thank you for the speedy reply. :)
> 
>> The only non-trivial change in hdpvr in 5.3 is this commit:
>>
>> commit 6bc5a4a1927556ff9adce1aa95ea408c95453225
>> Author: Hans Verkuil <hverkuil@xs4all.nl>
>> Date:   Thu Jun 20 07:43:41 2019 -0400
>>
>>     media: hdpvr: fix locking and a missing msleep
>>
>> Try reverting it and see if it makes a difference.
> 
> I should mention that I haven't tried this driver for over a year,
> so it's not just the change to 5.3 that we would be talking about.
> 
> Tried reverting the commit and built Linux 5.3-rc7+ -- alas, it didn't
> change anything.
> 
>>
>> Also test with 'v4l2-ctl -d /dev/videoX --stream-mmap' and see if it
>> keeps streaming buffers or if it also stalls.
> 
> That doesn't seem to work:
> 
> $ v4l2-ctl -d /dev/video2 --stream-mmap
> New timings found
> VIDIOC_REQBUFS: failed: Inappropriate ioctl for device

That's weird. I'll dig out my hdpvr later this week and test as well.

> 
> I suspect I might have to do a git bisect to find where the problem started.

That would certainly help.

Regards,

	Hans

Re: hdpvr.ko kernel 5.3-rc6

[Hans Verkuil]

On 9/3/19 8:35 AM, Hans Verkuil wrote:
> On 9/3/19 5:45 AM, Scott Doty wrote:
>> On 9/2/19 12:31 AM, Hans Verkuil wrote:
>>> Hi Scott,
>>
>> Hi Hans!  Thank you for the speedy reply. :)
>>
>>> The only non-trivial change in hdpvr in 5.3 is this commit:
>>>
>>> commit 6bc5a4a1927556ff9adce1aa95ea408c95453225
>>> Author: Hans Verkuil <hverkuil@xs4all.nl>
>>> Date:   Thu Jun 20 07:43:41 2019 -0400
>>>
>>>     media: hdpvr: fix locking and a missing msleep
>>>
>>> Try reverting it and see if it makes a difference.
>>
>> I should mention that I haven't tried this driver for over a year,
>> so it's not just the change to 5.3 that we would be talking about.
>>
>> Tried reverting the commit and built Linux 5.3-rc7+ -- alas, it didn't
>> change anything.
>>
>>>
>>> Also test with 'v4l2-ctl -d /dev/videoX --stream-mmap' and see if it
>>> keeps streaming buffers or if it also stalls.
>>
>> That doesn't seem to work:
>>
>> $ v4l2-ctl -d /dev/video2 --stream-mmap
>> New timings found
>> VIDIOC_REQBUFS: failed: Inappropriate ioctl for device
> 
> That's weird. I'll dig out my hdpvr later this week and test as well.

Never mind, hdpvr uses read(), not streaming I/O. Of course this
doesn't work...

Just plain 'cat /dev/videoX >x.mpg' will do.

> 
>>
>> I suspect I might have to do a git bisect to find where the problem started.
> 
> That would certainly help.

If you can at least narrow down what the first kernel version is that broke
hdpvr? That should help a lot.

BTW, you specified H264 in the vlc command line, but hdpvr only supports MPEG.
So that's weird.

Regards,

	Hans

> 
> Regards,
> 
> 	Hans
> 

Re: hdpvr.ko kernel 5.3-rc6

[Scott Doty]

On 9/3/19 1:34 AM, Hans Verkuil wrote:
>
> Never mind, hdpvr uses read(), not streaming I/O. Of course this
> doesn't work...
>
> Just plain 'cat /dev/videoX >x.mpg' will do.
>
>

Okay, tried that, it produces data that vlc can then play back.

So I think I'm running into a problem with vlc instead of hdpvr. It's 
just weird that mplayer, vlc, and ffplay would all three be unable to 
use it.

I'm at work atm, will plug it back in when I get home and see for how 
long it will read data with cat.

Thank you for looking, now I feel a bit dumb.

  -Scott

Re: hdpvr.ko kernel 5.3-rc6

[Mauro Carvalho Chehab]

Em Wed, 4 Sep 2019 11:13:36 -0700
Scott Doty <scott@ponzo.net> escreveu:

> On 9/3/19 1:34 AM, Hans Verkuil wrote:
> >
> > Never mind, hdpvr uses read(), not streaming I/O. Of course this
> > doesn't work...
> >
> > Just plain 'cat /dev/videoX >x.mpg' will do.
> >
> >  
> 
> Okay, tried that, it produces data that vlc can then play back.
> 
> So I think I'm running into a problem with vlc instead of hdpvr. It's 
> just weird that mplayer, vlc, and ffplay would all three be unable to 
> use it.

You can use any of them, provided that it is opened as if it were a
normal file, using the read() interface. For example, this should work:

	cat /dev/videoX | mplayer -cache 8000 -

The thing is that most apps assume that a V4L2 device supports mmap().

This is true for almost all devices, being hdpvr - and pvrusb - two
exceptions.


Thanks,
Mauro

Re: hdpvr.ko kernel 5.3-rc6

[Scott Doty]

On 9/4/19 11:40 AM, Mauro Carvalho Chehab wrote:

> You can use any of them, provided that it is opened as if it were a
> normal file, using the read() interface. For example, this should work:
> 
> 	cat /dev/videoX | mplayer -cache 8000 -
> 
> The thing is that most apps assume that a V4L2 device supports mmap().
> 
> This is true for almost all devices, being hdpvr - and pvrusb - two
> exceptions.


That works, and this works:

_[/tmp]_(scott@eva)_
$ cat /dev/video2 | vlc --prefetch-buffer-size 8192 -

So I've learned something more about the driver (and the direction
playback apps have gone).  Thank you very much for the assist. :)

 -Scott

Re: hdpvr.ko kernel 5.3-rc6

[Scott Doty]

On 9/4/19 11:13 AM, Scott Doty wrote:
> 
> On 9/3/19 1:34 AM, Hans Verkuil wrote:
>>
>> Never mind, hdpvr uses read(), not streaming I/O. Of course this
>> doesn't work...
>>
>> Just plain 'cat /dev/videoX >x.mpg' will do.
>>
>>
> 
> Okay, tried that, it produces data that vlc can then play back.
> 
> So I think I'm running into a problem with vlc instead of hdpvr. It's
> just weird that mplayer, vlc, and ffplay would all three be unable to
> use it.
> 
> I'm at work atm, will plug it back in when I get home and see for how
> long it will read data with cat.
> 
> Thank you for looking, now I feel a bit dumb.
> 
>  -Scott
> 

Yep, reads indefinitely.

_[/tmp]_(scott@eva)_
$ time -p cat /dev/video2 > out5.ts
^C
real 45.49
user 0.00
sys 0.27
_[/tmp]_(scott@eva)_
$ time -p cat /dev/video2 > out6.ts

Furthermore, I can run "vlc out6.ts",  and it will play the file until
it reaches the end (which it won't, if I keep writing to it).

So this appears to be a problem in userland.  My apologies for reporting
otherwise.

 -Scott