Mailing List Archive: Adjusting capture card parameters too often => driver lockup?

Adjusting capture card parameters too often => driver lockup?

Nov 11, 2009, 3:50 AM

Post #1 of 3 (2292 views)

ivtv-driver : 1.4.1

I've written a threaded recording server that makes use of one or more TV-
capture cards (e.g. Hauppage 150, 350 etc) to do scheduled recordings
+transcodings.

I'm just now running through all kinds of tests and basically it works as it
should. I'm testing it on a server with both a 350 and a 150 (Hauppauge analog
MP2 capture cards)

However, I have occasionally seen issues which I interpret as driver "lockups",
i.e.

1) The card opens fine. (open() returns a valid descriptor)

2) The settings made to the card (tuner freq. bitrate etc) seems to work, i.e.
they give no error.

3) However, the read/write loop (which is based on select()/read()) gives a
timeout on the select() waiting for the video descriptor to indicate that it has
some data available to be read by a a subsequent read() call.

The problem is that this is an intermittent issue, i.e. the capture works fine 9
times out of 10.

This issues seems related to changing HW parameters on the card too often (e.g.
MP2 bitrate). so if I just open the driver (e.g. /dev/video0) and just use the
default parameters it seems to work fine 10/10 and not just 9/10. It looks like
an issues to change the parameters too frequently.

At least that is how it looks viewing the driver as a "black box"

Sometimes I have also got an EBUSY when I try to change the MP2 video bitrate on
a just opened card.

Can anyone comment on these thoughts:
-----------------------------------------------------

0. Does the open() call do some kind of a soft reset on the capture card?

1. Is there some HW limitations to when/and how often the MP2 parameters can be
set (i.e. why is some controls returning EBUSY when the card has been
succesfully opened and no other apps are using the card). If I only set the
tuner freq. but stay away from the bitrate etc. it seems to just work always.

2. I guess it could be a heating issue, but the server has _very_ good
ventilation so I find this hard to believe. Especially since once a recording
have started it can run for hours wihtout any problems and very good picture
quality.

Cheers,
Johan

HW Details:

04:05.0 Multimedia video controller: Internext Compression Inc iTVC15 MPEG-2
Encoder (rev 01)
Subsystem: Hauppauge computer works Inc. WinTV PVR-350
Flags: bus master, medium devsel, latency 64, IRQ 21
Memory at dc000000 (32-bit, prefetchable) [size=64M]
Capabilities: [44] Power Management version 2
Kernel driver in use: ivtv

04:06.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416)
MPEG-2 Encoder (rev 01)
Subsystem: Hauppauge computer works Inc. WinTV PVR 150
Flags: bus master, medium devsel, latency 64, IRQ 22
Memory at d8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [44] Power Management version 2
Kernel driver in use: ivtv

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: Adjusting capture card parameters too often => driver lockup? [ In reply to ]

awalls at radix

Nov 11, 2009, 6:58 AM

Post #2 of 3 (2214 views)

Permalink

On Wed, 2009-11-11 at 12:50 +0100, Johan wrote:
> ivtv-driver : 1.4.1
>
> I've written a threaded recording server that makes use of one or more TV-
> capture cards (e.g. Hauppage 150, 350 etc) to do scheduled recordings
> +transcodings.
>
> I'm just now running through all kinds of tests and basically it works as it
> should. I'm testing it on a server with both a 350 and a 150 (Hauppauge analog
> MP2 capture cards)
>
> However, I have occasionally seen issues which I interpret as driver "lockups",
> i.e.
>
> 1) The card opens fine. (open() returns a valid descriptor)
>
> 2) The settings made to the card (tuner freq. bitrate etc) seems to work, i.e.
> they give no error.
>
> 3) However, the read/write loop (which is based on select()/read()) gives a
> timeout on the select() waiting for the video descriptor to indicate that it has
> some data available to be read by a a subsequent read() call.
>
> The problem is that this is an intermittent issue, i.e. the capture works fine 9
> times out of 10.
>
> This issues seems related to changing HW parameters on the card too often (e.g.
> MP2 bitrate). so if I just open the driver (e.g. /dev/video0) and just use the
> default parameters it seems to work fine 10/10 and not just 9/10. It looks like
> an issues to change the parameters too frequently.
>
> At least that is how it looks viewing the driver as a "black box"
>
> Sometimes I have also got an EBUSY when I try to change the MP2 video bitrate on
> a just opened card.
>
> Can anyone comment on these thoughts:
> -----------------------------------------------------
>
> 0. Does the open() call do some kind of a soft reset on the capture card?

The *first* open() on any one of an ivtv card's device nodes with cause
a firmware load and other initialization activities. Also the first
need for setting up the CX25843 broadcast A/V decoder also causes a
firmware load for that chip to then take place. (Firmware load is
deferred on purpose to support minimal filesystem environments on boot
up).

All other open()s basically just do some various initialization
activities. There are exceptions for YUV and radio nodes and for
PVR-350 decoder streams where various different restrictions are
enforced.

The first read() or select() on a stream starts the encoder going on
that stream.

Once a single stream is going (PCM, YUV, or MPEG, and maybe VBI), you
will not be allowed to change the encoders parameters. The reason is
that all the streams are somewhat related in the fact that the PCM and
YUV streams are really extra available products internall used by the
CX23416 to feed the MPEG encoding process. Once you have the encoder
parameters set for any one stream, and any one stream is going, they
encoder parameters are essentially set for all.

The final close() on any one stream will stop that stream. Once all
streams are stopped, you should be able to change encoder parameters.

(At least that's my recollection. I could have some details about
close() slightly wrong.)

>
> 1. Is there some HW limitations to when/and how often the MP2 parameters can be
> set (i.e. why is some controls returning EBUSY when the card has been
> succesfully opened and no other apps are using the card). If I only set the
> tuner freq. but stay away from the bitrate etc. it seems to just work always.

There are 29 different places in the driver code where EBUSY can be a
return value. Could you enable debugging on module load with with

# modprobe ivtv debug=1023

? That will give some context in the logs about what is going on when
you get EBUSY and maybe nail down the failure mode you are running into.

If you want to fill up your logs looking at DMA transfer notifications
you could instead use:

# modprobe ivtv debug=2047

>
> 2. I guess it could be a heating issue, but the server has _very_ good
> ventilation so I find this hard to believe. Especially since once a recording
> have started it can run for hours wihtout any problems and very good picture
> quality.

I doubt it is a heat issue.

Regards,
Andy

> Cheers,
> Johan
>
> HW Details:
>
> 04:05.0 Multimedia video controller: Internext Compression Inc iTVC15 MPEG-2
> Encoder (rev 01)
> Subsystem: Hauppauge computer works Inc. WinTV PVR-350
> Flags: bus master, medium devsel, latency 64, IRQ 21
> Memory at dc000000 (32-bit, prefetchable) [size=64M]
> Capabilities: [44] Power Management version 2
> Kernel driver in use: ivtv
>
> 04:06.0 Multimedia video controller: Internext Compression Inc iTVC16 (CX23416)
> MPEG-2 Encoder (rev 01)
> Subsystem: Hauppauge computer works Inc. WinTV PVR 150
> Flags: bus master, medium devsel, latency 64, IRQ 22
> Memory at d8000000 (32-bit, prefetchable) [size=64M]
> Capabilities: [44] Power Management version 2
> Kernel driver in use: ivtv

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: Adjusting capture card parameters too often => driver lockup? [ In reply to ]

johanp at aditus

Nov 22, 2009, 6:42 AM

Post #3 of 3 (2094 views)

Permalink

Thanks for the comments,

I believe I have found the cause of my issues. Due to a very silly typo (that
took me two weeks to spot) it could happen that in some circumstances that the
file descriptor for the video resource was not getting the FD_CLOEXEC flag
properly set.

This of course meant that some child processes (under some circumstances), while
they were running, kept the descriptor open and when the parent (which had
closed its descriptor) tried again the resource was still held open by the
child.

BTW. I'm just releasing 'tvpvrd' on sourceforge (
http://sourceforge.net/projects/tvpvrd/) Which is fairly complete Linux/Unix
video recorder server/daemon which uses ivtv via v4l2.

Blurb:
The main reason for writing this is that I didn't want to have to install such a
big thing as MythTV or any other "big" packages just to record (and transcode)
news and some occasional movie. Thie server interface uses a dedicated TCP/IP
port with a built in command language to schedule and manipulate recordings. No
need for datbases or big UI .. (just a hint of XML with a touch of an ini-file).

The best thing is that I don't have to ask my wife to make a recording when I'm
travelling - I can just schdule a new recording with my phone :-)

I guess this could also serve as an example on how one could use > ~11,000 lines
of C to automate what one line in the shell could (almost) accomplish , i.e.
'cat /dev/video0 > movie.mpg' .... of course there are a few more features in
the server :-)

Rgds
Johan

On the 2009-11-11 you wrote:
> On Wed, 2009-11-11 at 12:50 +0100, Johan wrote:
> > ivtv-driver : 1.4.1
> >
> > I've written a threaded recording server that makes use of one or more TV-
> > capture cards (e.g. Hauppage 150, 350 etc) to do scheduled recordings
> > +transcodings.
> >
> > I'm just now running through all kinds of tests and basically it works as it
> > should. I'm testing it on a server with both a 350 and a 150 (Hauppauge
analog
> > MP2 capture cards)
> >
> > However, I have occasionally seen issues which I interpret as driver
"lockups",
> > i.e.
> >
> > 1) The card opens fine. (open() returns a valid descriptor)
> >
> > 2) The settings made to the card (tuner freq. bitrate etc) seems to work,
i.e.
> > they give no error.
> >
> > 3) However, the read/write loop (which is based on select()/read()) gives a
> > timeout on the select() waiting for the video descriptor to indicate that it
has
> > some data available to be read by a a subsequent read() call.
> >
> > The problem is that this is an intermittent issue, i.e. the capture works
fine 9
> > times out of 10.
> >
> > This issues seems related to changing HW parameters on the card too often
(e.g.
> > MP2 bitrate). so if I just open the driver (e.g. /dev/video0) and just use
the
> > default parameters it seems to work fine 10/10 and not just 9/10. It looks
like
> > an issues to change the parameters too frequently.
> >
> > At least that is how it looks viewing the driver as a "black box"
> >
> > Sometimes I have also got an EBUSY when I try to change the MP2 video
bitrate on
> > a just opened card.
> >
> > Can anyone comment on these thoughts:
> > -----------------------------------------------------
> >
> > 0. Does the open() call do some kind of a soft reset on the capture card?
>
> The *first* open() on any one of an ivtv card's device nodes with cause
> a firmware load and other initialization activities. Also the first
> need for setting up the CX25843 broadcast A/V decoder also causes a
> firmware load for that chip to then take place. (Firmware load is
> deferred on purpose to support minimal filesystem environments on boot
> up).
>
> All other open()s basically just do some various initialization
> activities. There are exceptions for YUV and radio nodes and for
> PVR-350 decoder streams where various different restrictions are
> enforced.
>
> The first read() or select() on a stream starts the encoder going on
> that stream.
>
> Once a single stream is going (PCM, YUV, or MPEG, and maybe VBI), you
> will not be allowed to change the encoders parameters. The reason is
> that all the streams are somewhat related in the fact that the PCM and
> YUV streams are really extra available products internall used by the
> CX23416 to feed the MPEG encoding process. Once you have the encoder
> parameters set for any one stream, and any one stream is going, they
> encoder parameters are essentially set for all.
>
> The final close() on any one stream will stop that stream. Once all
> streams are stopped, you should be able to change encoder parameters.
>
> (At least that's my recollection. I could have some details about
> close() slightly wrong.)
>
>
> >
> > 1. Is there some HW limitations to when/and how often the MP2 parameters can
be
> > set (i.e. why is some controls returning EBUSY when the card has been
> > succesfully opened and no other apps are using the card). If I only set the
> > tuner freq. but stay away from the bitrate etc. it seems to just work
always.
>
> There are 29 different places in the driver code where EBUSY can be a
> return value. Could you enable debugging on module load with with
>
> # modprobe ivtv debug=1023
>
> ? That will give some context in the logs about what is going on when
> you get EBUSY and maybe nail down the failure mode you are running into.
>
> If you want to fill up your logs looking at DMA transfer notifications
> you could instead use:
>
> # modprobe ivtv debug=2047
>
>
> >
> > 2. I guess it could be a heating issue, but the server has _very_ good
> > ventilation so I find this hard to believe. Especially since once a
recording
> > have started it can run for hours wihtout any problems and very good picture
> > quality.
>
> I doubt it is a heat issue.
>
>
> Regards,
> Andy
>
> > Cheers,
> > Johan
> >
> > HW Details:
> >
> > 04:05.0 Multimedia video controller: Internext Compression Inc iTVC15 MPEG-2
> > Encoder (rev 01)
> > Subsystem: Hauppauge computer works Inc. WinTV PVR-350
> > Flags: bus master, medium devsel, latency 64, IRQ 21
> > Memory at dc000000 (32-bit, prefetchable) [size=64M]
> > Capabilities: [44] Power Management version 2
> > Kernel driver in use: ivtv
> >
> > 04:06.0 Multimedia video controller: Internext Compression Inc iTVC16
(CX23416)
> > MPEG-2 Encoder (rev 01)
> > Subsystem: Hauppauge computer works Inc. WinTV PVR 150
> > Flags: bus master, medium devsel, latency 64, IRQ 22
> > Memory at d8000000 (32-bit, prefetchable) [size=64M]
> > Capabilities: [44] Power Management version 2
> > Kernel driver in use: ivtv
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
>