[mythtv] Ticket #12809: Use lastPlayPos rather than bookmark

[Roger Siddons]

On Thu, 11 Jan 2018 09:47:20 +0000
John Pilkington <J.Pilk at tesco.net> wrote:

> On 11/01/18 05:26, Mark Perkins wrote:
> > On 11 January 2018 9:45:37 am Roger Siddons
> > <dizygotheca at ntlworld.com> wrote: ......  
> >>
> >> I can't imagine a valid reason for a client to overwrite the
> >> duration, so I think it should be excluded/ignored.  
> > 
> > What about the pre-padding / post-padding being trimmed from the
> > recording? 
> 
> Yes.  I don't know how it fits into the new plans, but duration
> can/will be reset by mythcommflag --rebuild
> 

Good question.

Any form of 'transcode' invalidates all marks so a traditional
frontend should probably never set the duration directly, but prod the
backend to do it, via mythutils/mythcommflag.

If the API supports mythutil-like clients as well - we let
any client do anything - then there's a risk of corrupted
recordings (albeit repairable)

I would argue that bookmark/lastplaypos etc are user/client properties
that only affect playback behaviour. They don't cause damage. 

Whereas duration/seek-table/etc marks are backend properties and only
updateable via approved methods, i.e. mythutils/mythcommflag.
That they are all "marks" is an implementation detail.

A 'set duration to 0' request could even become a sentinel to run
mythutils/mythcommflag, but I'm not sure that's a good idea. 

Maybe a new Myth service ? I can't find any current service for a client
to run a User Job or start commflagging.