"Resume Playback" behavior is sub-optimal and unintuitive.
As of version 3.0.6 (the current stable) the behavior of the "Resume Playback" is sub-optimal and unintuitive.
Currently (3.0.0-git tag, commit 8d432b09), Progress though a video is conditionally saved at /modules/gui/qt/input_manager.cpp:167.
Progress is only saved if
- the video has a length of at least 1 minute
- playback is at least 5% though the video
- playback is no more than 95% though the video
I believe the last 2 conditions are sub-optimal. While it is obviously pointless (and potentially frustrating) to resume to either the immediate end or immediate beginning of a video, the rejection criteria should be based on absolute time, not percent of video.
Currently, I am slowly watching though a ~100 hours video. As a result of the current behavior I can't resume in the first or last 5 hours. At the same time the feature would resume 5 seconds into a 90 second clip.
Instead I would propose resumption should not happen for the first or last N seconds regardless of video length. Where N could reasonable be a value between 30 and 120 seconds.
I attempted to implement this based off the current git master. However the file that saved recent timestamps was removed 2 weeks ago in commit dda157b5. As far as I can tell nowhere else currently calls RecentsMRL::setTime to update playback progress, meaning resumptions seems to be broken in master. That commit was included in the nightly for the last few days and resumption does not work as I would expect. However, in those nightly's the interface also seems to have radically changed and the entire recents menu is missing. So it could be caused by some other unrelated systemic breakage unrelated to that commit that happened to occur around the same time.