VBI on PVR-500 stopped working between kernels 3.6 and 3.13

VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Christopher Neufeld]

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:0000:06:08.0
+       Card type     : WinTV PVR 500 (unit #2)
+       Bus info      : PCI:0000: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.250000 MHz)
+Frequency for tuner 0: 884 (55.250000 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"

Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Hans Verkuil]

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:0000:06:08.0
> +       Card type     : WinTV PVR 500 (unit #2)
> +       Bus info      : PCI:0000: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.250000 MHz)
> +Frequency for tuner 0: 884 (55.250000 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

Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Andy Walls]

On October 26, 2014 1:50:36 AM EDT, Hans Verkuil <hverkuil@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:0000:06:08.0
>> +       Card type     : WinTV PVR 500 (unit #2)
>> +       Bus info      : PCI:0000: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.250000 MHz)
>> +Frequency for tuner 0: 884 (55.250000 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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

I have time from 1 pm to about 10 pm EDT today; the rest of my week is booked.  If I dont have an answer by 10 pm, next Sunday would be the earliest.

Regards,
Andy

Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Christopher Neufeld]

Hello Hans,

On Sun, 26 Oct 2014 06:50:36 +0100, Hans Verkuil <hverkuil@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"

Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Andy Walls]

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 <hverkuil@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/vbi<N> --set-fmt-sliced-vbi=cc=1 --set-ctrl=stream_vbi_format=1
	v4l2-ctl -d /dev/vbi<N> --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.
> 

Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Andy Walls]

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 <hverkuil@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/vbi<N> --set-fmt-sliced-vbi=cc=1 --set-ctrl=stream_vbi_format=1
> 	v4l2-ctl -d /dev/vbi<N> --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 majordomo@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

[Christopher Neufeld]

Andy,

On Sun, 26 Oct 2014 13:41:14 -0400, Andy Walls <awalls@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/vbi<N> --set-fmt-sliced-vbi=cc=1 --set-ctrl=stream_vbi_format=1
> 	v4l2-ctl -d /dev/vbi<N> --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 <awalls@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"

Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Andy Walls]

On October 26, 2014 5:35:30 PM EDT, Christopher Neufeld <media-alias@cneufeld.ca> wrote:
>Andy,
>
>On Sun, 26 Oct 2014 13:41:14 -0400, Andy Walls
><awalls@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/vbi<N> --set-fmt-sliced-vbi=cc=1
>--set-ctrl=stream_vbi_format=1
>> 	v4l2-ctl -d /dev/vbi<N> --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
><awalls@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

Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Hans Verkuil]

On 10/26/2014 01:10 PM, Christopher Neufeld wrote:
> Hello Hans,
> 
> On Sun, 26 Oct 2014 06:50:36 +0100, Hans Verkuil <hverkuil@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

Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Hans Verkuil]

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 <hverkuil@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/vbi<N> --set-fmt-sliced-vbi=cc=1 --set-ctrl=stream_vbi_format=1
>> 	v4l2-ctl -d /dev/vbi<N> --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 majordomo@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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>