Closed Glandos closed 3 years ago
If you add the following line to your mpv.conf
, it will save the position on exit:
save-position-on-quit
write-filename-in-watch-later-config
The second line is not strictly necessary, but I find it useful.
You can also exit MPV with shift+q to resume later. From the man page:
Q Like q, but store the current playback position. Playing the same file later will resume at the old playback position if possible.
However, ytcc will still mark it as watched. Together with a configurable threshold like mentioned in #69 it could be a solution. But I don't really see a reliable way to track the playback progress. Simply recording the time which the player is running is problematic if the video is paused for longer times.
You're right, pausing video can be a real issue ;)
If mpv store the playback position somewhere… I was thinking… Do you believe if it is reliable or not to read that position and use it? It's an idea out of nowhere, maybe parsing mpv own files is a nightmare.
ytcc doesn't need to read it at all. The resuming is done by mpv when it starts.
This seems to be not trivial: https://github.com/mpv-player/mpv/blob/a92466c28959536cd3b1e7fa5ce31232a2b9a5fd/player/configfiles.c#L195
As I said before, ytcc does not need to handle this at all. The behaviour is implemented entirely within mpv.
Yes, it is entirely in mpv. And you can configure mpv to exit with a non-zero exit code when quitting with the quit-watch-later
command, which tells ytcc to not mark the video as watched. I didn't know this behavior exists in mpy until @wavexx pointed it out in #69.
Okay. After browsing through the mpv man page some more I found --save-position-on-quit
and --watch-later-directory
options.
Following idea:
A new config option would control how far the playback progress must be to mark a video as watched (set to 0 by default to keep the existing behavior)
I think that would make for a pretty seamless experience. @EmRowlands @Glandos what do you think of this approach? And do you see potential downsides?
Indeed, using these parameters are a nice trick. I guess that the idea is to create a new temporary directory for every new mpv call, so that the watch-later file will be alone.
For the last point, I'd say that changing the current behavior, and setting a default value to 80 or 90 wouldn't hurt. But being conservative is always a good idea anyway.
So this would definitely be a good answer to this issue.
I like the idea of using --watch-later-directory, but "save-position-on-quit" shouldn't be IMHO. This behavior is controlled by the mpv binding already.
Having used quit-watch-later with a non-zero exit code for some time now, I'm quite satisfied by the behavior out-of-the-box already. Knowing the video has been only partially seen would be a nice addition though.
@Glandos commented on 13 nov. 2020 à 23:37 UTC+1:
Indeed, using these parameters are a nice trick. I guess that the idea is to create a new temporary directory for every new mpv call, so that the watch-later file will be alone.
It seems that this idea is broken, or at least non complete. When resuming, mpv should be able to find the resume file. So either the watch filename is stored in database, and restored before launch, or all watch file are store below ~/.local/share/ytcc/
directory. Anyway, I know that you know what you are doing :)
I have decided to not implement anything special here. No automatic detection of playback progress, no parsing of mpv's watch-later files, etc. I decided to do so, because that leaves (almost) full control of mpv's commandline parameters and config to the user and therefore does not cause unexpected behavior in more advanced configs.
I documented relevant mpv settings in d0c1d2ac0.
Is your feature request related to a problem? Please describe. Long videos can't be watched in one time. Resuming them can be useful.
Describe the solution you'd like When exiting player in the middle of a video, it could be nice to be able to save the timestamp, and use it when relaunching the video.
Additional context We have to see if it can be solved along with #69