[mythtv] Ticket #13202: playback doesn't start at begining

David Engel david at istwok.net
Mon Jan 8 17:06:24 UTC 2018


On Sun, Jan 07, 2018 at 11:43:29PM +0000, Roger Siddons wrote:
> On Sun, 7 Jan 2018 12:20:13 -0600
> David Engel <david at istwok.net> wrote:
> 
> > I have a
> > better implementation in mind that would allow nearly any playback
> > setting to be used in a play group.  It's not high on my TODO list,
> > though, so it won't be happeing any time soon.
> 
> Even so, it would be interesting to hear any ideas, however rudimentary.

The central idea is to use the normal settings table and flag play
group values in some way.  For example, appending "#PlayGroupName" to
the setting name or using "#PlayGroupName" as the hostname.  The
latter would ensure that play group settings are not host specific.

The tricky part would be how to present this in the settings.  The old
settings code was not conducive to doing anything(*).  I'm hoping the
new, mythui-baase, tree-structured settings code is.  For example,
havigate to a normal, playback setting, press MENU and choose "Add
Play Group Value".

(*)Someone, I think John Poet, but I'm not absolutely sure, did
actually implement a scheme for allowing play group versions of any
playback setting.  I didn't think it was maintainable, so it never
made it to git.

> > Personally, I think this default, mythical bookmark behavior is wholly
> > unintuitive.  I think most reasonable people would expect playback to
> > start at the start of the recording.  When somebody uses the feature
> > to jump to 5 minutes from the beginning, is that 5 minutes from the
> > beginning of the recording or 5 minutes from the scheduled program
> > time?
> 
> I agree. It's useful but users should opt-in to it.
> 
> > My preferred solution would be to make it easier to then jump to the
> > scheduled program time after playback starts.  
> 
> Interesting thought.
> 
> There's talk of committing https://code.mythtv.org/trac/ticket/12809,
> which frees up the bookmark but begs: why is the user limited
> to a single bookmark ?
> StuartM has talked of per-user bookmarks. A simpler/preliminary version
> is to allow multiple bookmarks.
> JUMPSTART & JUMPBOOKMARK appear useful but I don't use them because
> they're not undo-able and I'll never remember which button they've been
> assigned to. Hit the wrong one and you're lost.
> 
> Comm-skipping is well-designed. It uses 2 buttons NEXT/PREV, is
> undo-able and (briefly) shows the OSD with position, skip distance &
> reason.
> 
> If manual/user comm-skipping was extended to all/any marks it could
> navigate the mythical bookmark, all bookmarks and any future marks.
> 
> Auto-commskipping could use mythical bookmark as well as commflags. So
> even without commflagging playback would start at the mythical, if
> Auto-skip was set (Notify also available). Crucially the OSD would show
> what's happening.
> 
> Essentially:
> - Comm-skipping is re-branded as mark-skipping. 
> - More types of marks can be used/handled with OSD feedback. All skips
>   are reversible.
> - The existing Auto/Notify/No skip setting would control where playback
>   started
> - Non-commflaggers get to use the existing commskip UI. Currently it
>   does nothing for them.
> - Commflaggers will stop at bookmarks/other marks when manually
>   skipping. That could be useful. If not, just skip again.

Hmm, might work.  Jumping around to find the right mark might get a
tedious if there are lots of marks.  There might also need to be a
popup listing all of the marks so the user can more easily choose the
right one.

David
-- 
David Engel
david at istwok.net


More information about the mythtv-dev mailing list