[mythtv] ~Realtime Commflagging

[Brad Benson]

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.

My master backend is configured to run up to 2 jobs simultaneously and
my single slave backend to run only a single job.  I had a transcode
job running on the master backend and a nuvexport job running on the
slave backend which left me with only a single job slot available. 
Myth started recording 2 shows at the same time (9pm).  One of them
got picked up in the available job queue slot and started commflagging
as it should.  The second show got queued up for later running.  I
killed the nuvexport job on the slave backend around 9:50 so it would
be available to commflag the second 9pm show.  The commflag job did
get picked up for processing by the slave backend, but the show was
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
at the same time).  By the time the detection buffer was completely
built the show had finished recording.  However, the commflag job
continued to run at degraded speed (presumably because it thought the
show was still recording).

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.

Normally commercial flagging seems to take about 5-10 minutes for a 30
minute show (when running at full speed), but since turning on
~realtime flagging all commflagging jobs seem to take almost the same
length of time to complete as the show is long (~30 mins to commflag a
30 min show).  My system is recording at least 1 show nonstop for the
next several hours which means my commflagging probably won't catch up
until an hour or so after the last show finishes recording.

I assume it should be possible to have the commflag job, if it's set
to ~realtime, check to make sure the recording is, in fact, still in
progress.  If it is still in progress then see how far along the
recording is and determine if we need to wait to build the detection
buffer or if we can start in on the flagging immediately.  If the
recording has completed, then we shouldn't bother running at degraded
speed because there's no danger of outrunning the recording.  Or,
better yet, since commflag sleeps periodically to handle ~realtime
flagging, couldn't we check the recording status before each sleep? 
If the recording is still in progress then sleep as normal, but if the
recording has completed then kick into high gear and finish the
flagging job at full speed.

Brad