[mythtv] ~Realtime Commflagging

[Chris Pinkham]

> I've been running ~realtime commflagging for a few weeks now and I've
> noticed a few things that could be improved.  I think Chris is still
> working on this so maybe he's already noticed this, but I figured I'd
> point it out anyway.

Feedback is good (unless you're talking about audio). :)

> already 25 minutes into its 30 minute runtime.  Even though there
> should have been plenty of buffer available, I noticed that the
> commflag job had a status of "Building detection buffer" for about 10
> minutes (which seems to be normal when the commflag and record start

This was a pretty easy fix.  I have a fix in my tree for this
that will check the recording start time against the current time
and will offset the sleep amount to make sure we don't sleep when
we don't need to.

> The transcode job on the master backend completed at about 10:15 and
> the commflag job for a show recorded at 10:00 got picked up in the job
> queue slot.  This job showed the same behavior of running at degraded
> speed even though there should have been plenty of recording available
> for it to build the detection buffer at startup.

The FPS displayed by mythcommflag when using realtime flagging is not
a true indicator of raw FPS, it is the average FPS based on the number
of frames processed since the time mythcommflag was started.  I use
this average FPS to make sure that the flagger does not catch up to
the recorder during ~realtime flagging.  The flagger is supposed to
receive the DONE_RECORDING event from the recorder when the recording
finishes and this causes the flagger to go into normal speed and
not throttle itself anymore.  I think there may be a problem picking
up this event, I'm not seeing it being received in some of my testing.

I'll try to get the fix for the first issue above committed to CVS
tonight or tomorrow night at the latest.

-- 
Chris