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
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
