[PATCH] Updated enhanced cutpoint edit functionality patch

[Bill Stuff <billstuff2001@…>]

This is an update of #6322 - It adds a new visual display for editing recordings (see attached picture)

To use it, go into the normal edit mode and hit the MENU button ('M' ??). The rest of the keys are similar to normal editing. The pictures at the bottom of the screen are the previous and next frames by seekamount (i.e. if you're seeking by 20 seconds, they're -60, -40, -20, 0, +20, +40, +60) Hit Esc or MENU to go back.

This is against 0.24. AFAIK it should work with trunk but it doesn't apply because of the recent undo/redo changes in the DeleteMap?. If there's any interest in putting this into trunk I'll help clean it up.

This is development code so it might not work perfectly but it shouldn't do anything bad. YMMV

[Bill Stuff <billstuff2001@…>]

Screenshot

[J.Pilk@…]

I liked the look of this when Bill first submitted his original version two years ago. It would be great to see it committed - and in fixes. This looks the most appropriate place to record that.

[markk]

Bill

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.

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 changing).

• 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 middle.

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...

[Bill Stuff <billstuff2001@…>]

Patch which *compiles* against trunk. Might not work. YMMV

[Jim Stichnoth]

Here is a prototype implementation of the concept that uses the existing edit screen.

[Jim Stichnoth]

Attachment thumbs_v1.patch implements this concept within the existing cutlist editor screen.

In osd.xml in the osd_program_editor window, you can define any number of <imagetype> objects whose name starts with "thumbnail_". The rest of the name is a floating point value that specifies where to grab a thumbnail image, in terms of the number of edit distance "steps" away from the current frame. Here is an example (based on a 1280x720 OSD theme size):

      <imagetype name="thumbnail_-2">
	<filename>images/background.png</filename>
	<area>200,0,200,200</area>
	<preserveaspect>true</preserveaspect>
	<alpha>200</alpha>
      </imagetype>
      <imagetype name="thumbnail_-1">
	<filename>images/background.png</filename>
	<area>400,0,200,200</area>
	<preserveaspect>true</preserveaspect>
	<alpha>200</alpha>
      </imagetype>
      <imagetype name="thumbnail_1">
	<filename>images/background.png</filename>
	<area>680,0,200,200</area>
	<preserveaspect>true</preserveaspect>
	<alpha>200</alpha>
      </imagetype>
      <imagetype name="thumbnail_2">
	<filename>images/background.png</filename>
	<area>880,0,200,200</area>
	<preserveaspect>true</preserveaspect>
	<alpha>200</alpha>
      </imagetype>
      <imagetype name="thumbnail_10">
	<filename>images/background.png</filename>
	<area>1105,200,175,175</area>
	<preserveaspect>true</preserveaspect>
	<alpha>200</alpha>
      </imagetype>
      <imagetype name="thumbnail_-10">
	<filename>images/background.png</filename>
	<area>0,200,175,175</area>
	<preserveaspect>true</preserveaspect>
	<alpha>200</alpha>
      </imagetype>

A background helper thread loads the thumbnails in the order specified. One to-do item is to dynamically change that order to prioritize for the frames the user likely wants to see first. Another item is to improve the design of the thumbnail choice/size/placement.

[Stuart Auchterlonie]

We have moved all bug tracking to github [1]

If you continue to have this issue, please open a new issue at github, referencing this ticket.

[1] - ​https://github.com/MythTV/mythtv/issues