[mythtv] Ticket #9556: Updated enhanced cutpoint edit functionality patch
billstuff2001 at sbcglobal.net
Mon Feb 14 22:43:30 UTC 2011
On 02/14/2011 07:59 AM, MythTV wrote:
> #9556: Updated enhanced cutpoint edit functionality patch
> Comment (by markk):
> This is a big patch and I haven't had a chance to try and get it working
> with trunk, so please forgive me if I've missed something.
> Can you clarify what additional features this adds? (over and above the
> obvious of providing the extra frames). Implementation details aside, this
> is a lot of code for what appears to be a small amount of fairly niche
> functionality - and something that adds additional overhead for a fully
> completed theme.
Thanks for taking a look at it, Mark.
This gives the user a better view of where they're cutting and speeds up
For example, take the process of saving programs without commercials:
This requires going into the editor, loading the comm-flag list and
adjusting the cutpoints for errant flags. When doing this I often flick
back and forth to see the adjacent frames. It's kind of like having
tunnel vision. This lead to my original patch in #6322 - the basic
functionality to display the current frame and the immediately adjacent
Later I found the adjacent frames are useless when navigating through
the recording. It's more useful to see the next few frames I'll seek to,
then I can lower the seek amount to fine tune the cutpoint. Kind of like
zoom in / zoom out.
> Implementation wise:-
> - I'd personally rather see this displayed and themed as part of the OSD.
> This seems the most logical place to handle it (we already have the
> current frame on screen), avoids the extra main UI integration (and the
> complications involved) and makes it a little more future proof (the
> implementation of guidedrid etc causes many problems and it needs
> - I'm not sure I see the utility of displaying a series of frames that
> are, for example, 60seconds apart. frame by frame yes - but otherwise it's
> just confusing.
> - If you stick to the next and previous X frames, you by and large have
> these available already - or at least it would take relatively little work
> to ensure that you have a buffer of 11 frames, and re-position to the
> All told, I think I can see a far simpler solution that hence is more
> maintainable and, if done properly, requires minimal theming. Unless I've
> missed the point...
Valid points. As always, you guys are welcome to do whatever you want
with this. I'll help where I can if there's interest in getting it into
More information about the mythtv-dev