GitLab

In order to be able to probe the media type after it is stopped and its
track vectors have been emptied.

Hugo Beauzée-Luyssen authored Feb 28, 2020 and Thomas Guillem committed Feb 28, 2020

We were using 50% instead of 5%
Signed-off-by: Thomas Guillem <thomas@gllm.fr>

Hugo Beauzée-Luyssen authored Feb 28, 2020 and Thomas Guillem committed Feb 28, 2020

Co-authored-by Thomas Guillem <thomas@gllm.fr>
Signed-off-by: Thomas Guillem <thomas@gllm.fr>

Hugo Beauzée-Luyssen authored Feb 28, 2020 and Thomas Guillem committed Feb 28, 2020

Instead of a macro with dubious readability
Signed-off-by: Thomas Guillem <thomas@gllm.fr>

And use it to ask the user if they want to resume the playback position
when a last position is known by the media library

And allow states to be restored independently of the position

As it's already contained in the player input

While this is still not optimal, we don't want to force a resume for
short audio files.
Support for the old "always resume/never resume/ask the user" will come
in a later patch.

Mikhail Gusarov authored Dec 15, 2019 and Hugo Beauzée-Luyssen committed Dec 19, 2019

Existing logic of storing playback position excludes positions within last 5%.

This heuristic is fine for short videos, but for a longer, say 6-hour hones, it
means that the position is not stored for the last 18 minutes, which is a
nuisance.

This change adds an upper limit for the size of excluded positions and makes it
symmetric, so that a video that was stopped just after the start will be
restarted from the beginning.

This is a continuation of a macOS-specific patch that landed as
e3e32ab0

 in branch 3.0
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Signed-off-by: Hugo Beauzée-Luyssen <hugo@beauzee.fr>

refs #22524

Refs #22524