Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13
Hello Hans, On Sun, 26 Oct 2014 06:50:36 +0100, Hans Verkuil hverk...@xs4all.nl said: The script that I use to set up captions invokes this command: v4l2-ctl -d DEV --set-fmt-sliced-vbi=cc --set-ctrl=stream_vbi_format=1 This now errors out. Part of that is a parsing bug in v4l2-ctl, it wants to see more text after the 'cc'. I can change it to v4l2-ctl -d DEV --set-fmt-sliced-vbi=cc=1 --set-ctrl=stream_vbi_format=1 This is a v4l2-ctl bug. I'll fix that asap. But using cc=1 is a valid workaround. with this change, it no longer complains about the command line, but it errors out in the ioctls. This behaviour is seen with three versions of v4l2-ctl: the old one packaged with the old kernel, the new one packaged with the newer kernel, and the git-head, compiled against the headers of the new kernel. Are you calling this when MythTV is already running? If nobody else is using the PVR-500, does it work? When my script is running, MythTV is not using that unit of the PVR-500. I use the recording groups feature to ensure that that unit is made unavailable for recordings whenever high-definition recordings are being made. The details of what I'm doing can be found here: https://www.mythtv.org/wiki/Captions_With_HD_PVR I would not expect this command to succeed if the unit were in use, in fact the script detects that as an error case and loops until the device is free. The v4l2-ctl command that I use has historically returned an error if somebody had the unit's video device open for reading. Now, though, it errors even when the unit is unused. For my script, it is necessary that the MythTV backend be running, the script is invoked by the backend, but when it is invoked, nobody is using that unit of the PVR-500 (and, in practice, the other unit is almost never used, as it's quite rare that I make standard-definition recordings). My script is not used when MythTV directly makes a standard-definition recording from the PVR-500. In that case, the program presumably issues its own ioctl equivalents of the v4l2-ctl command, and those are not working, because the recordings produced do not have VBI data, while those recorded before the kernel upgrade do. I won't be able to test this myself until next weekend at the earliest. Captions are mostly for my wife's benefit, and I checked, most of her upcoming shows are being recorded from OTA broadcasts, which provide ATSC captions independently of the PVR-500, so I can wait for a week or two. Thank you for looking into this. -- Christopher Neufeld Home page: http://www.cneufeld.ca/neufeld Don't edit reality for the sake of simplicity -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13
Andy, On Sun, 26 Oct 2014 13:41:14 -0400, Andy Walls awa...@md.metrocast.net said: Can you verify that v4l2-ctl -d DEV --get-fmt-sliced-vbi --get-ctrl=stream_vbi_format also fails, and that Yes, that also fails. v4l2-ctl --list-devices v4l2-ctl -d /dev/vbiN --set-fmt-sliced-vbi=cc=1 --set-ctrl=stream_vbi_format=1 v4l2-ctl -d /dev/vbiN --get-fmt-sliced-vbi --get-ctrl=stream_vbi_format both succeed on the corresponding vbi node? Yes, those succeed. So, that solves my problem, thank you. If you can use the /dev/vbiN node as a work-around, please do. I will switch to doing that, and update the MythTV wiki appropriately. I assume that this is the correct invocation for any similar capture devices, not just the PVR-500 and family. On Sun, 26 Oct 2014 14:28:15 -0400, Andy Walls awa...@md.metrocast.net said: FYI, MythTV has already worked around it: https://code.mythtv.org/trac/ticket/11723 https://github.com/MythTV/mythtv/commit/25310069a1154213cbc94c903c8b0ace30893ec4 Ah, well then that part of my bug report was incorrect. Sometimes shows don't send caption data, even the same program one week later. I happened to have two recordings in standard definition that had no captions, but one recorded last night did, as might be expected if MythTV already worked around it. Thank you for your time on this, Andy and Hans. I will update my scripts, and this will work perfectly for me. -- Christopher Neufeld Home page: http://www.cneufeld.ca/neufeld Don't edit reality for the sake of simplicity -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
VBI on PVR-500 stopped working between kernels 3.6 and 3.13
I've been using a PVR-500 to record shows in MythTV, and to capture the VBI
part of the stream from the standard-definition output of my STB when it
records high definition. This has worked for about 7 years now.
I recently updated my LinHES MythTV distribution, and part of the update
involved moving to a new kernel. The old kernel went by the code
3.6.7-1-ARCH, while the new one is 3.13.7-2-ARCH.
With the updated kernel, my VBI captures no longer function.
Standard-definition recordings made from MythTV using the PVR-500 before
the update have caption data in the stream, those made after do not.
The retrieval of caption data for high-definition shows involves some
manual scripting to set the modes for the PVR-500, after which I run
ccextractor on the V4L device node and just pull out the captions data (the
audio and video being output separately on high-definition outputs of the
STB, and captured by a HD-PVR).
The script that I use to set up captions invokes this command:
v4l2-ctl -d DEV --set-fmt-sliced-vbi=cc --set-ctrl=stream_vbi_format=1
This now errors out. Part of that is a parsing bug in v4l2-ctl, it wants
to see more text after the 'cc'. I can change it to
v4l2-ctl -d DEV --set-fmt-sliced-vbi=cc=1 --set-ctrl=stream_vbi_format=1
with this change, it no longer complains about the command line, but it
errors out in the ioctls. This behaviour is seen with three versions of
v4l2-ctl: the old one packaged with the old kernel, the new one packaged
with the newer kernel, and the git-head, compiled against the headers of
the new kernel.
I strace-d the v4l2-ctl command. The relevant output is:
open(/dev/pvr_500_1, O_RDWR) = 3
ioctl(3, VIDIOC_QUERYCAP or VT_OPENQRY, 0x7fff836aac10) = 0
ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
brk(0) = 0x12ca000
brk(0x12eb000) = 0x12eb000
ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
PREVIOUS LINE REPEATS 41 TIMES
ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = -1 EINVAL (Invalid argument)
ioctl(3, VIDIOC_S_FMT or VT_RELDISP, 0x62eae0) = -1 EINVAL (Invalid argument)
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7fe8233bf000
write(1, VIDIOC_S_FMT: failed: Invalid ar..., 39VIDIOC_S_FMT: failed: Invalid
argument
) = 39
close(3)= 0
exit_group(-1) = ?
I did once see VBI data arriving from one of the paired devices in the
PVR-500, and not from the other. I would guess that to be because it
started up in that state. When this happened, I ran v4l2-ctl --all on both
devices, captured the output, and stored it to files. I did not see any
relevent differences in these outputs, but I present the diff here:
--- file1 2014-10-25 13:40:36.698703171 -0400
+++ file2 2014-10-25 13:40:41.248614481 -0400
@@ -1,15 +1,14 @@
Driver Info (not using libv4l2):
Driver name : ivtv
- Card type : WinTV PVR 500 (unit #1)
- Bus info : PCI::06:08.0
+ Card type : WinTV PVR 500 (unit #2)
+ Bus info : PCI::06:09.0
Driver version: 3.13.7
- Capabilities : 0x81070051
+ Capabilities : 0x81030051
Video Capture
VBI Capture
Sliced VBI Capture
Tuner
Audio
- Radio
Read/Write
Device Capabilities
Device Caps : 0x01030001
@@ -18,7 +17,7 @@
Audio
Read/Write
Priority: 2
-Frequency for tuner 0: 4148 (259.25 MHz)
+Frequency for tuner 0: 884 (55.25 MHz)
Tuner 0:
Name : ivtv TV Tuner
Capabilities : 62.5 kHz multi-standard stereo lang1 lang2
freq-bands
The fact that I once saw valid VBI data suggests that the driver is still
capable of the feature, but something about the ioctl invocations in
v4l2-ctl and in MythTV 0.27.4 is wrong for getting the driver reliably into
the state where VBI data is present in the stream coming from the device.
--
Christopher Neufeld
Home page: http://www.cneufeld.ca/neufeld
Don't edit reality for the sake of simplicity
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
