Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13
On 10/26/2014 01:10 PM, Christopher Neufeld wrote: 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. Fixed this in the v4l-utils git repository. This is now working again as expected. This reason this worked in the past was a case of two bugs canceling one another out. After fixing one bug, parsing this option no longer worked. Regards, Hans -- 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
Hi Andy, On 10/26/2014 07:28 PM, Andy Walls wrote: On Sun, 2014-10-26 at 13:41 -0400, Andy Walls wrote: Hi Chris, On Sun, 2014-10-26 at 08:10 -0400, Christopher Neufeld wrote: 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. Can you verify that v4l2-ctl -d DEV --get-fmt-sliced-vbi --get-ctrl=stream_vbi_format also fails, and that 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? Looking at the v3.16 kernel code that I'm compiling right now, it looks like extra checks put in the v4l2-core don't allow setting sliced VBI formats using video device nodes: http://git.linuxtv.org/cgit.cgi/v4l-utils.git/tree/utils/v4l2-ctl/v4l2-ctl-vbi.cpp#n209 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n959 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n1192 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n1265 I have to actually install and test, but this is my current guess. FWIW, those checks were introduced in this commit: http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=4b20259fa642d6f7a2dabef0b3adc14ca9dadbde Hans, I'm inclined to say these checks are good things, but they did break existing behavior for user scripts and apps at about kernel v3.7 AFAICT. I did check various apps (including mythtv) at the time whether they were using vbi nodes for doing vbi parsing, but I missed the sliced vbi handling in the mpegrecorder. This patch was part of the ongoing effort to be more picky about what drivers allow. It makes no sense to setup a vbi format on a video node. There is a reason we have vbi nodes, after all. Thanks for taking the time to track this down! Regards, Hans FYI, MythTV has already worked around it: https://code.mythtv.org/trac/ticket/11723 https://github.com/MythTV/mythtv/commit/25310069a1154213cbc94c903c8b0ace30893ec4 But I don't know about any other apps. Regards, Andy If you can use the /dev/vbiN node as a work-around, please do. Regards, Andy 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. -- 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
On October 26, 2014 1:50:36 AM EDT, Hans Verkuil hverk...@xs4all.nl wrote:
Hi Christopher,
On 10/26/2014 01:15 AM, Christopher Neufeld wrote:
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
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?
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.
I won't be able to test this myself until next weekend at the earliest.
Andy, are you able to look at this?
Regards,
Hans
--
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
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
Hi Chris, On Sun, 2014-10-26 at 08:10 -0400, Christopher Neufeld wrote: 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. Can you verify that v4l2-ctl -d DEV --get-fmt-sliced-vbi --get-ctrl=stream_vbi_format also fails, and that 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? Looking at the v3.16 kernel code that I'm compiling right now, it looks like extra checks put in the v4l2-core don't allow setting sliced VBI formats using video device nodes: http://git.linuxtv.org/cgit.cgi/v4l-utils.git/tree/utils/v4l2-ctl/v4l2-ctl-vbi.cpp#n209 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n959 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n1192 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n1265 I have to actually install and test, but this is my current guess. If you can use the /dev/vbiN node as a work-around, please do. Regards, Andy 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. -- 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
On Sun, 2014-10-26 at 13:41 -0400, Andy Walls wrote: Hi Chris, On Sun, 2014-10-26 at 08:10 -0400, Christopher Neufeld wrote: 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. Can you verify that v4l2-ctl -d DEV --get-fmt-sliced-vbi --get-ctrl=stream_vbi_format also fails, and that 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? Looking at the v3.16 kernel code that I'm compiling right now, it looks like extra checks put in the v4l2-core don't allow setting sliced VBI formats using video device nodes: http://git.linuxtv.org/cgit.cgi/v4l-utils.git/tree/utils/v4l2-ctl/v4l2-ctl-vbi.cpp#n209 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n959 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n1192 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n1265 I have to actually install and test, but this is my current guess. FWIW, those checks were introduced in this commit: http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=4b20259fa642d6f7a2dabef0b3adc14ca9dadbde Hans, I'm inclined to say these checks are good things, but they did break existing behavior for user scripts and apps at about kernel v3.7 AFAICT. FYI, MythTV has already worked around it: https://code.mythtv.org/trac/ticket/11723 https://github.com/MythTV/mythtv/commit/25310069a1154213cbc94c903c8b0ace30893ec4 But I don't know about any other apps. Regards, Andy If you can use the /dev/vbiN node as a work-around, please do. Regards, Andy 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. -- 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 -- 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
Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13
On October 26, 2014 5:35:30 PM EDT, Christopher Neufeld media-al...@cneufeld.ca wrote: 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. Hi Chris, Well, I didn't look at MythTV's logic for finding the correct vbi device. You might not get captions from MythTV recordings, if it guessed the wrong vbi node or if it didn't have sufficient permissions to access the vbi node. Regards, Andy -- 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
Hi Christopher,
On 10/26/2014 01:15 AM, Christopher Neufeld wrote:
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
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?
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.
I won't be able to test this myself until next weekend at the earliest.
Andy, are you able to look at this?
Regards,
Hans
--
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
