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 _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
