[mythtv-users] Commercial Detection during recording

[Karl Newman]

On Mon, Mar 11, 2013 at 5:17 PM, Michael T. Dean <mtdean at thirdcontact.com>wrote:

> On 03/11/2013 05:00 PM, Joseph Fry wrote:
>
>>
>> Mike, CPU is certainly the greatest resource used by comflagging
>> itself... but there is an IO component to it... and if the IO is already
>> nearly saturated with concurrent recordings and playback... comflagging may
>> contribute to playback/recording issues.
>>
>> Preferring comflagging on current recordings over a FIFO queue achieves 2
>> advantages:
>> 1. reduction in IO due to caching
>> 2. higher priority recordings can be comflagged before lower priority,
>> completed recordings.
>>
>> For example, lets say that one night I record six 1 hour shows, 2 at a
>> time for 3 hours.  Assume I only have one comflag job defined and my CPU is
>> just barely fast enough to run realtime.  In this case, when my favorite
>> show airs in the 3rd hour of recordings, there will be 2 hours of shows
>> left in the queue before it will get flagged.
>>
>> This happens to me all the time... there are only a few shows that I want
>> to watch right away... mostly so friends/coworkers don't spoil them for me
>> the next day, and they are almost never transcoded when I watch them
>> because the queue is full of stuff that recorded earlier in the evening.
>>
>>
> See the link I quoted. It says that there's work being done...
>
>
> Mike
>

In 0.25+, there was a problem with mythcommflag frequently dying after
hitting the EOF, which it's going to do all the time if it's trying to
commflag while recording. I believe this was attributed to a race condition
(one of about 5 new annoying little bugs in 0.25+ that were attributed to
race conditions). Do you know if that ever got fixed?

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130313/a1a1570c/attachment.html>