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 <hverk...@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
> 

Reply via email to