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