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 >