[mythtv] Mythcommflag final commercial break

Jim Stichnoth stichnot at gmail.com
Tue Nov 29 17:28:46 UTC 2011


On Mon, Nov 28, 2011 at 3:20 PM, R. G. Newbury <newbury at mandamus.org> wrote:
> On 11/28/2011 04:55 PM, Chris Pinkham wrote:
>> * On Sun Nov 20, 2011 at 10:21:28AM -0800, Jim Stichnoth wrote:
>>> Lately I've been noticing that mythcommflag often leaves a 1-2 second
>>> non-break section at the end of a recording, when it looks like the
>>> last commercial break should actually extend to the end of the
>>> recording.  This appears to be the result of line 1810 of
>>> ClassicCommDetector.cpp, which is the last statement excerpted below:
>>>
>>>      if ((breakStart != -1)&&
>>>          (breakStart<= ((int64_t)framesProcessed - (int64_t)(2 * fps) - 2)))
>>>      {
>>>          if (verboseDebugging)
>>>              LOG(VB_COMMFLAG, LOG_DEBUG,
>>>                  QString("Closing final commercial block started at "
>>>                          "block %1 and going to end of program. length "
>>>                          "is %2 frames")
>>>                      .arg(curBlock)
>>>                      .arg((framesProcessed - breakStart - 1)));
>>>
>>>          commBreakMap[breakStart] = MARK_COMM_START;
>>>          commBreakMap[framesProcessed - (int)(2 * fps) - 2] = MARK_COMM_END;
>>>      }
>>>
>>> Removing that statement leaves an open-ended commercial break, which
>>> seems to work just fine.  Is there any reason not to do that?
>>
>> I'm not sure if all the places where we generate or parse the commercial skip
>> list can handle an open ended list.
>>
>> I believe the reason for the above code was to make it so that the user could
>> hit rewind if the skip took them too far rather than the recording exitting
>> immediately if the skip caused the player to hit EOF.  The way it is now, the
>> user has ~1-2 seconds hit hit rewind or skip-back if the flagging was
>> incorrect.
>>
>> --
>> Chris
>
> I for one, find that 2 seconds extremely useful, for exactly the reasons
> Chris sets out.
>
> Geoff

That makes sense.  I took a quick look at commbreakmap.cpp and
markuputils.cpp, and I'm pretty sure Chris is right that an open-ended
list is not correctly handled.

At the same time, it's a minor annoyance when editing, and it seems
kind of unclean to deliberately "corrupt" the data before writing it
to the database.  What would you think of a patch that writes a
correct skiplist into the database, and the commskip portion of
playback makes a local modification to shorten the final skip region
if necessary?

Jim


More information about the mythtv-dev mailing list