[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