[mythtv] [mythtv-commits] Ticket #8564: Inserting a new cut point alters existing cut points

[John Pilkington]

On 23/06/10 13:46, Stuart Auchterlonie wrote:
> On 21/06/2010 18:45, Michael T. Dean wrote:
>> On 06/21/2010 10:14 AM, MythTV wrote:
>>> #8564: Inserting a new cut point alters existing cut points
>>>
>>>
>>> Comment(by Jim Stichnoth):
>>>
>>> The attached patch restores the original behavior as far as I can tell.
>>>
>>> 1. Fixes the logic error pointed out in the previous comment.
>>>
>>> 2. Only calls DeleteMap::CleanMap() after a cutlist is loaded and before
>>> it is saved.
>>>
>>> 3. Doesn't try to clean the deletemap when Add() is called.
>>>
>>> 4. This is the tricky part. In OSD::SetRegions(), convert
>>> discontinuities
>>> (i.e., two marks in a row of the same type) into overlapping cut
>>> regions.
>>> It would probably be cleaner to extend the definition of regions in
>>> MythUIEditBar to include whether the start point and the end point
>>> should
>>> contain a start/end image, but that would require a lot more than a one-
>>> line change to MythUIEditBar.
>>
>> When I noticed this change, I mentioned to Mark K. that I would like to
>> fix it by extending his newer, cleaner approach to editing recordings
>> rather than falling back to the previous behavior. So, below is my
>> proposal for how we should handle this.
>>
>> Having edited a hand full of recordings using the current editor, I've
>> found that the process is somewhat clumsy. Besides issues with the key
>> bindings (and inconsistencies in their usage compared to the rest of
>> MythTV), the focus on single cut points when cut regions are the desired
>> end product makes editing require the user to keep track of whether they
>> need before or after cut points.
>>
>> Therefore--keeping consistent with Mark's new code--I propose that we
>> change the focus to the production of cut regions. The UI would be
>> updated to allow users to modify the existing cut points with:
>>
>> When in un-cut video:
>> - Move the previous end point here (or, if there is no previous end
>> point, Cut from the beginning)
>> or
>> - Move the next start point here (or, if there is no next start point,
>> Cut to the end)
>>
>> Or, when in cut regions:
>> - Move the next end point here (if we're already inside a cut region)
>> or
>> - Move the previous start point here (if we're already inside a cut
>> region)
>>
>
> So, since here in the UK the commflagger generally doesn't do anything
> my use case is as follows
> - Edit recording and skip forward until finding the start of program
> - Cut to beginning
> - Skip to next commercial, flag
> - Skip to end of commercial, flag
> - Repeat skip and flag
>
> Stuart

I'm in the UK too, and use the editor a lot, from the keyboard.  Not the 
comflagger.  I often wonder why the step increments change as they do:

10 min, 5 min, 1 min, 20 sec, 5 sec, 1 sec (default), 0.5 sec. 1 frame, 
keyframe, cutpoint

Is this to conform with some standard or precedent?  Is it 
user-modifiable?  Obviously any change would create initial confusion, 
but I think I would prefer a progression nearer to factors of two; and 
the 'cutpoint' setting sometimes catches me unawares.

John P