On 10/11/05, John P Poet <[EMAIL PROTECTED]> wrote: > On 10/11/05, Daniel Kristjansson <[EMAIL PROTECTED]> wrote: > > On Tue, 2005-10-11 at 18:03 -0600, John P Poet wrote: > > > When mythcommflag runs, I often get a lot of: > > > 2005-10-11 18:02:02.387 GetNextFreeFrame() unable to lock frame 100 > > > times. Discarding Frames. > > > > I thought I had fixed this last week. > > > > Basically, if you get a frame you are supposed to return it, > > either by calling DoneDisplayingFrame(), if you are processing > > the "LastShownFrame", or DiscardFrame(VideoFrame*), if it is > > possibly some other frame. This is essential if you are using > > hardware decoding such as XvMC, as not doing things properly > > can deadlock the Linux kernel inside the video driver. But if > > you are using the null video output like in the commercial > > scanner, not doing it only means you will pause every 32th > > frame or so waiting for a "free-all" timeout (while waiting, > > these messages get printed out). > > > > > Commerical flagging seems to working just fine, so I assume I can > > > ignore all these? > > Yep. But, of course, it would be nicer to fix this, are you sure > > this is the commercial scanner and not transcode? I thought I > > looked though the commercial scanner pretty carefully last week. > > > > I have never used the transcoder. > > Another mythcommflag process is running now, and it is *not* > generating those messages, so it does not do it all the time. > > Is there an option to "mythbackend -v" that I should add, so I can > give you more information then next time this happens? > > Actually, now that I think about it, I wonder if it was trying to > "real time" flag commericals for one of my manual-record-tests even > after I aborted (and deleted) the show? I bet mythcommflag was not > told that the show/file had been removed and kept trying to process > it. > > John >
Okay, the idea that these messages where coming from a recording which had been deleted out from under mythcommflag was wrong. I do occasionally get these when it is working on perfectly valid recordings. They don't seem to cause any problems, but I am willing to try and help track down the cause, with some direction... John _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
