options: Add watch-later-key

[TAAPArthur]

A new option has been added to override the filename in mp_get_playback_resume_config_filename.

This option was made for the case where the video path or url changes or just isn't unique but the user still wants progress to be saved.

Examples include

• Streaming a url where the upstream path contains transient information like a session id
• Streaming a url where irrelevant query parameters are added/removed.
• Playing from stdin since the "file name" is always "-"
• Playing a local file from a link vs the real file

Read this before you submit this pull request:
https://github.com/mpv-player/mpv/blob/master/DOCS/contribute.md

Reading this link and following the rules will get your pull request reviewed
and merged faster. Nobody wants lazy pull requests.

[snylonue]

I'm curious about whether it is possible to implement a method that allows users to specify a key.

[TAAPArthur]

@snylonue

I'm curious about whether it is possible to implement a method that allows users to specify a key.

So if two invocations of mpv used the same key they'd use the same watch later file? Yes it is possible.
When I first thought of this I was thinking of something along those lines. You'd pass in some arbitrary string and that would be used in place of the file path/url to generate the hash used as the file name for the watch later data. For my usecase that would work just as well, but thought this form may be more convenient to more people. My use case involves invoking mpv from a script so the options just needs to be set once and it doesn't really matter how verbose or repetitive it would be. But I thought that some people may want to

• invoke it manually and not want to specify the title twice (assuming the specified title is already unique).
• Set the option in their config and effectively make this the default behavior

I'm personally fine with implementing either of them as they are all basically the same amount of work. If anyone has other usecases or opinions on the UI, I'd love to hear them

[snylonue]

Sorry for delayed response.

My use case involves invoking mpv from a script so the options just needs to be set once and it doesn't really matter how verbose or repetitive it would be.

So do I. In this case I think a user-specified key will be more flexible.

invoke it manually and not want to specify the title twice (assuming the specified title is already unique). Set the option in their config and effectively make this the default behavior

I think the option can be designed to use title as a default value, or support Property Expansion (though I don't know how much work it would take or whether there is any security issue).

[TAAPArthur]

So do I. In this case I think a user-specified key will be more flexible.

Updated. Changed the name option to watch-later-key

I think the option can be designed to use title as a default value,

For the moment I didn't give it a default. This way seems more inline with the other watch-later vars in that strings values always have to accept an arg.

Also planning on having the key be a literal string and not expanded. Feel like it may be confusing to people since the watch-later file name won't be dynamically updated even if the its property was.

[avih]

The main concern is that it sets a single global watch-later save filename. IMHO this doesn't make sense for mpv. E.g. if more than one item is loaded (playlist), then we can't save different watch-later files for the different files.

If we could limit it to only get applied per-file, then it would make sense.

As a global option, IMHO it can only work to specify a mode used to turn file/url into a key, but not the key itself.

[TAAPArthur]

So had a discussion in IRC about this feature. One objection was that it wouldn't be useful for playlist. Some options would be

1. Not care as this is an optional feature
2. Use merge-files to treat the playlist as a single file
3. Change the property into --merge-file-watch-later-key and only have it enabled if merge-files is set
4. Have a watch-later file for the playlist itself in addition to this PR.
   All of these disallow saving specific file information for a playlist which is just a side effect of this PR. It is assumed that the user wants to treat the single file/playlist as one item

[TAAPArthur]

As a global option, IMHO it can only work to specify a mode used to turn file/url into a key, but not the key itself.

Discussed in IRC, but a problem with this is that some urls are effectively random and short lived. So this couldn't be a complete solution

[avih]

but a problem with this is that some urls are effectively random and short lived

I didn't suggest it solves the problem, only that this is the only global type of option which could make sense at the context of affecting the watch-later file name.

In general, a single global watch-later file makes sense only in the context of a single played item, which only needs a single save file.

So as discussed, one option which makes all the files into a single item is --merge-files, hence if the key is global and applies only to the merged files "item", then it might make sense.

[TAAPArthur]

I didn't suggest it solves the problem, only that this is the only global type of option which could make sense at the context of affecting the watch-later file name.

I was just pointing out the flaw with the idea. Also disagree with it being "the only option that makes sense" since the ideas listed in #11020 (comment) make sense

[TAAPArthur]

@avih What about making the watch-later-key a list? Where the nth entry affects the nth file in the playlist and empty options get the default behavior?
Something like mpv --watch-later-key=key1,key2 foo bar

EDIT:

Have a working patch if we assume all files are uniquely named. IE not mpv --watch-later-key=key1,key2 foo foo; Both foos would use the same key.

So it when trying to determine the watch later file, all we really have is the filename and the global option. We don't have have the playlist index. So without a larger refactor, 2 files with the same name seem to have to share the same watch-later file. Don't know if that matters.

Attached the patch watch_later_list.patch
Not really sure if this is better. Silently making files with the same name share the same watch later file is already the current behavior, but kinda seems bad.

[avih]

We've had this discussion in the past - #9346 , my comments back then still stand, and I'm not seeing additional info here.

In a nutshell:

• Unless you can demonstrate otherwise, your initial PR is only good for a use case where there's a single playlist item, which doesn't change while mpv is running, and both the item and its alternative watch-later name/key/whatever are known in advance, in a generally automated setup. I.e. no user is likely to type that alternative key as a manual CLI option, except if launched via a script which automates it.
• The fact that it's highly likely to be used exclusively in an automated setup is important, because it means you can add custom scripts automatically, as needed.
• global mpv save file name is wrong because it behaves wrongly in any other use case (playlist, directory, item changes during playback like drag and drop, loadfile command, and more).
• If there was a way to reject such global option while still accepting it as a local option (using --{ and --}) then I'd be OK with that, but as far as I know mpv can't do that currently.
• There is a way to ensure that mpv plays a single item, using --merge-files, at which case maybe we could add an option to set a save key for the merged item. However, as far as I know it only works for local files, so it doesn't cover your example of using a URL (same goes for custom EDL wrapper file, which is used internally with --merge-files).
• A way to provide a custom map of play item name to a custom key might be OK, but is likely to be very awkward to use, and so far I've not seen something I liked. Also, your suggestion to map playlist item number to a key name breaks if the playlist changes.
• A 5 lines lua script I posted here Add ability to use save-position-on-quit when file name changes #9346 (comment) (based on a script by @guidocella few comments above) still solves all the use cases exaples you described (do correct me if I'm wrong):

Examples include
* Streaming a url where the upstream path contains transient information like a session id
* Streaming a url where irrelevant query parameters are added/removed.
* Playing from stdin since the "file name" is always "-"
* Playing a local file from a link vs the real file

Therefore, my position still stands that it's a highly unique use case, which is not worth the additional code and/or inconsistency in mpv, and where a custom script similar to the one above fits the task perfectly.

[TAAPArthur]

Unless you can demonstrate otherwise, your initial PR is only good for a use case where there's a single playlist item, which doesn't change while mpv is running, and both the item and its alternative watch-later name/key/whatever are known in advance

I agree with this part but not the rest of this post

in a generally automated setup. I.e. no user is likely to type that alternative key as a manual CLI option, except if launched via a script which automates it.

So for my main usecase there is a script. You can imagine it queries a 3rd party api and prints a url mpv can stream.
The workflow is basically

my_script | while read -r url mpv_args; do
    if  `mpv $mpv_args $url`;
       mark_watched
   fi
done

Where my_script skips urls that have been marked watched.
That's my main usecase, but underlying problem affects more cases.

Consider the case where if you start watching something you watch it to completion. In that world, you'd be ok with the watch-later data always saving to the same file since that would always be correct and just dropping watch-later-key in your config file would give you the desired behavior when playing a single file where the path/url changes.

Other cases could be

• anytime when one manually sets title. If you know a descriptive title, you probably know what you are watching. THe original version of this PR was used the title as the key, but that seemed non-ideal cause the title could change.
• the path changes because the file is on removable media since where the media is mounted is user/OS/distro specific. Seems pretty common if you are playing a dvd. Also when playing a dvd the individual video files may not be unique across dvds
• the file is renamed
• the file is moved. I know there is an option to only use the base name, but consider the case where files are stored Show1/ep1, Show1/ep2 etc. Probably don't want to share progress on a given episode across different shows

The fact that it's highly likely to be used exclusively in an automated setup is important, because it means you can add custom scripts automatically, as needed.

I think you are making too many assumptions here. Yes it is easy for a single user to patch mpv. But if one is trying to ship a package adding extra requirements like this quickly adds up. For one the requirement of lua is added.
Another is that automated workflow I'm using is player agnostic. The user just specifies a command to run and we just give a url. Needing to patch/script every possible player is doable but isn't ideal.

global mpv save file name is wrong because it behaves wrongly in any other use case (playlist, directory, item changes during playback like drag and drop, loadfile command, and more).

I still say it behaves in an expected albeit probably not useful manner. I'm just taking it as a requirement that all combinations of options have to have "useful" behavior

Also, your suggestion to map playlist item number to a key name breaks if the playlist changes.

Fair. Forgot playlist could change

A 5 lines lua script I posted here
#9346 (comment) (based on a script by @guidocella few comments above) still solves all the use cases exaples you described (do correct me if I'm wrong):

Yes if one has lua support. But it has all the limitations you point out. I don't care about the limitations and I don't think anyone who desired this patch did. Honestly I think harping on the limitations ignores the problem it solves. From what I've gathered it solves a real problem and causes some well-defined behavior that has questionable use.

@avih
But after sleeping on it,

As a global option, IMHO it can only work to specify a mode used to turn file/url into a key, but not the key itself.

may be good enough.

If I could specify a regex, I could select the domain which may be unique. And if I didn't want to make the assumption I could just use a dedicated watch-later-dir and have the regex select an empty string or something.

So I'm proposing having a watch-later-regex, that would be used to generate the key. Need to look in to mpv's convention for such options but currently thinking it would be like a sed command. Like mpv --watch-later-regex "s/.*\(\w*\.\w*\).*/\1/" someurl.com/random_path to only use the domain name. Or mpv --watch-later-regex "s/.*//" someurl.com/random_path if you want the same behavior as this patch. Open to an alternative syntax.

Think this would also make the watch-later-filename obsolete as this would be a more general form. I don't think it is worth removing and would apply the regex transform afterwards if both were set.

EDIT:
I described full find replace capabilities which is probably overkill. Find-remove would probably be sufficient generally and think there is precedent for such options. Also open to literal string remove

[qmega]

To me this seems most useful as a per-file option, and a regex replace would be less generalizable, less debuggable, etc. (and a regex replace could be trivially implemented as a script if the per-file option were available). Take for example the use case of ytdl_hook.lua writing watch-later based on the video id and not the start time param or youtube/youtu.be -- maybe could be done with regex, but certainly cleaner using the already-parsed info in the lua script.

qmega@4fda5de makes it work as (only) a file-local option (including resuming the right entry in a playlist), but does so by pretty much bypassing the normal option loading mechanics.
I haven't looked into strictly rejecting it globally (though the above commit does ignore the global value) because I don't feel like the approach is too likely to be well-received anyway, but I could look into that if we want to go down this road.

Having it work file-local with mp_get_playback_resume_config_filename reading the option value as in the current version of this PR would require (as far as I can see) player/loadfile.c to load_per_file_options before mp_load_playback_resume, which would change precedence so that watch-later overrode perfile-options, which is probably not desirable. Then more logic would be required to handle playlist resume.

[TAAPArthur]

To me this seems most useful as a per-file option, and a regex replace would be less generalizable, less debuggable, etc. (and a regex replace could be trivially implemented as a script if the per-file option were available). Take for example the use case of ytdl_hook.lua writing watch-later based on the video id and not the start time param or youtube/youtu.be -- maybe could be done with regex, but certainly cleaner using the already-parsed info in the lua script.

Completely disagree. A find/replace regex is strictly more generalizable than setting a constant value. If you know the key you want you could just s/.*/YOUR_KEY and set that as a per file option and you get the same result as setting a constant. And if you need a script to figure it out after startup, the script could update the regex. If the regex could only remove parts of the url, maybe... In the youtube case, this wouldn't be a problem since the video id could be selected with v=[0-9A-z] in either version. So it is useful without scripting and if you are already scripting you could update it as needed.
And this may be a matter of opinion but I also find a one line regex more debuggable than an arbitrary script.

I don't hate the idea of a constant (obviously as that was the original PR); just think the regex sufficiently solves every presented usecase and avoids all the objections presented.

Another downside of a constant is that it won't affected newly added files unless one additionally added scripts to support them. Don't know if that matters to anyone.

I haven't looked into strictly rejecting it globally

I don't see the value of rejecting it globally. There are usecases for having a global value. Like if you will always finish the video you started before starting another and really don't care about the possibility of the path/url changes. You could just set the key to a constant in your config file and never think about it again instead of having to specify on the cli every time. Or for a less extreme case, you use a dedicated watch later dir for certain types of videos and always finish a video in that group before starting the next.
That may behave poorly if you start mpv with multiple files, but if that's the user's desired behavior I don't see the point of adding code to stop them. If you don't want the behavior you can use a per-file option but what's the benefit of killing usecases?

[qmega]

A find/replace regex is strictly more generalizable than setting a constant value. If you know the key you want you could just s/.*/YOUR_KEY and set that as a per file option and you get the same result as setting a constant.

I was comparing a global regex (which I believed you were describing) to a per-file constant. The watch-later-key as implemented in this PR doesn't work as a file-local option, so a regex with a similar implementation wouldn't either. Implementing per-file regex would be strictly more flexible than per-file constants, yes, but also doesn't enable any use cases that aren't possible with per-file constants alone. Global regex on the other hand is not strictly more flexible than per-file constants. I'd argue it's the opposite: Global regex can be fully implemented using per-file constants, but the reverse isn't true.

And this may be a matter of opinion but I also find a one line regex more debuggable than an arbitrary script.

My perspective is that you can trivially add prints of intermediate values to a script that isn't yielding the desired result, while debugging regex generally involves putting variations or subsets of it into some independent script or console, testing it on the inputs it would get in the real use case, and also verifying that those inputs actually come as you expect them; I usually find the latter more time-consuming and error-prone. But I suppose it is a matter of opinion.

I think the more critical point, though, is that a per-file option can do things that a single regex can't. This is already a fairly niche feature; it would be a shame if we compromised on an implementation that narrowed the niche further and still left some use cases out in the cold after all this. (An implementation that allowed regex and also worked per-file would handle all the cases, too, but strikes me as an unnecessarily complex interface.)

In the youtube case, this wouldn't be a problem since the video id could be selected with v=[0-9A-z] in either version.

I disagree. That would match for example ?t=123&garbagev=thewrongvalue&v=therightvalue and select the wrong value. To guarantee the correct result you'd need regex that actually properly parses the URI. I don't care to remember at the moment whether standard regex is even capable of doing that in all possible edge cases. Surely it's been practically done millions of times with more or less acceptable results. But I have a strong preference for using the ytdl_hook's existing understanding -- the relevant value is already reliably available in the script.

I don't see the value of rejecting it globally. There are usecases for having a global value. [...] if that's the user's desired behavior I don't see the point of adding code to stop them.

In theory I agree that blocking it if it would work would be pointless. However, @avih expressed a desire to block it globally, so I was addressing that, and the code I came up with so far that implements it file-locally ignores the global value of the option, not with code for that purpose but as a result of the way its implemented (it only reads file-local params). Making the global value work there would be additional code. Adding that code would be fine by me, but if we don't, there's some value in warning the user that they've set something that isn't going to take effect. If you've got an alternate implementation that correctly handles the option's global value incidentally (as well as handling the other cases that need to be) then I suppose it'd be a different story.

[avih]

No need to argue which is better - per file key or global regex modifier. Both have value, and both have their use cases. That being said, both also have issues:

• We don't have regex on windows, and additionally it's likely to slow down considerably use cases where the user opens a dir with thousands of audio files, for instance, because mpv needs to check a resume file for each of them, and using a regex on each could have considerable impact on startup time. What I had in mind was more along the lines of --ignore-path-in-watch-later-config, e.g. maybe to remove some URL arguments etc (though whether that'd be faster than regex could be arguable). Also, even a regex wouldn't be a solution for the general use case of playlist of several items where each needs its own watch-later key.
• Local config key ("per file") is more of an issue than I imagined initially, thanks to the proof of concept code by @qmega . The issue is that local config should work when saving or loading a watch later file, because the local options are in scope, but it wouldn't work when loading a playlist, because mpv looks for all the items resume files without that local options being currently active for each file. So even before rejecting it globally, I think local options still wouldn't work as one expects (except using some deeper modifications like at the POC patch). Another issue is that it's not actually "per file", because it still can be applied to several files together e.g. --{ file1 file2 file3 --watch-key=foo --}.

To be honest, the more I think about it, the only absolutely solid solution that comes to my mind is to feed mpv a map of hash-calculated-by-mpv to replacement-filename-or-hash, e.g. using a key-value string list. The main loophole is that the (automated) user would need to replicate the internal mpv calculation, in order to map it to something else. However, in the past decade it was and is md5, so it's relatively simple (and remaining related issues can be addressed).

But, for now I consider such solution (map) an overkill for the task at hand, for the main reason that even though we agree that currently there's no way to tell mpv to use a custom watch-later file/key/whatever, I do honestly believe that the use cases are both few, and different (so a single solution might not fit all, and especially the map approach can't really be used without external automation), and the the current system of filename either with or without the path covers the use cases for the vast majority of users.

I do acknowledge that there can be good use cases which could use such feature, but due to the issues with the various approaches so far of an internal mpv solution, and the fact that mpv supports scripts, it does make it relatively simple to write a script which targets each specific use case.

One could even write a script which replaces the internal watch-later system with a new implementation, using whatever data/options/names/properties to choose the file name, choose the file format (e.g. so that a shell script could add it as mpv CLI options), etc. The sky is the limit.

But so far, I've not seen an approach to a good/simple solution in mpv that would cover more than a single super niche use case which already has a lua script to address it (well, the @qmega patch is not bad, but it only exposes new issues with the local options approach).

So it's over and out for me on this issue, at least for now.

If anyone else feels like taking over, I don't mind.

[TAAPArthur]

@qmega

Generally agree

think the more critical point, though, is that a per-file option can do things that a single regex can't.

Technically yes I agree a per-file option could do things a single global regex.

I disagree. That would match for example ?t=123&garbagev=thewrongvalue&v=therightvalue and select the wrong value.
There was a small type-o in my earlier comment, but it still is easy to parse

$ echo "?t=123&garbagev=thewrongvalue&v=therightvalue&garbage2v=anotherwrongvalue" | sed "s/.*\W\(v=[0-9A-z]*\).*/\1/"
v=therightvalue

I can imagine edge cases where "v=" is quoted earlier in query and I'll admit handling that is going to be more confident depending on the regex favor, but don't that is likely to happen in practice.

This is already a fairly niche feature; it would be a shame if we compromised on an implementation that narrowed the niche further and still left some use cases out in the cold after all this.

Really this is just a generalization of the ignore-file-path option with a very similar rational. I agree with the notion of supporting all possible usecases (within reason). Honestly I wouldn't complain if you solution was accepted as is, I think it would just be a pain to use manually if you had multiple files.

If you've got an alternate implementation that correctly handles the option's global value incidentally (as well as handling the other cases that need to be) then I suppose it'd be a different story.

Pretty sure your impl basically does that. Just default override_watch_later_key to the global value. If the global value is null, it would be ignored and if set and a file-only option isn't it, it would be used.

`
@avih

To be honest, the more I think about it, the only absolutely solid solution that comes to my mind is to feed mpv a map of hash-calculated-by-mpv to replacement-filename-or-hash, e.g. using a key-value string list. The main loophole is that the (automated) user would need to replicate the internal mpv calculation, in order to map it to something else. However, in the past decade it was and is md5, so it's relatively simple (and remaining related issues can be addressed).

I feel like this would be significantly more viable if instead of a hash, the user specified the pre-hash value (whatever that may be depending on other options). It would at least make cli use easier.

So I keep hearing that this is a "niche" feature. And the attempts to generalize seem to add complexity require a refactor. Would it be more viable to go the other direction and make it even more niche? Consider how ignore-file-path gets the basename of the file/url. What about just getting the domain name of the url? It isn't generalizable but doesn't seem worse than ignore-file-path.

Actually instead of a new option, maybe that's just what ignore_path_in_watch_later_config should do when given a url. Only using the domain (and maybe protocol?) sounds more like what the option should do instead doing nothing. Not sure if that would affect any common workflows though.

[avih]

I feel like this would be significantly more viable if instead of a hash, the user specified the pre-hash value (whatever that may be depending on other options). It would at least make cli use easier.

The reasons I suggested hash key rather than pre-hash string key are:

• In a key-value option, a hash can be a key, but using pre-hash string (e.g. URL) as a key for the new value could be highly awkward or impossible to enter. E.g. --watch-map-add=AB123545FA=<whatever> vs --watch-map-add=http://<messy URL with "=" chars and more>=<whatever>.
• It's not always obvious what the string is, e.g. with --merge-files, but because internally mpv always calculates a hash, then the hash as a key covers 100% of the cases. Still remains an issue of how the caller calculates it, but we can add an API to query the current hash, for instace.

Other than this, my last comment above still stands.

[LittleBenjiBoy]

I'm personally fine with implementing either of them as they are all basically the same amount of work. If anyone has other usecases or opinions on the UI, I'd love to hear them

I have went through the trouble to use and build from source @TAAPArthur's first commit in this pull request "options: Add watch-later-use-title," excluding the last commit "fixup! remove window subsystem args" on Windows 10, and it works exactly the way I want it to. It works for videos that contain an expiry time, because they will always contain the same title. I don't see a reason against this change as it is just a more general case for the currently implemented --ignore-path-in-watch-later-config option.

I don't agree with the idea of passing a watch-later-key to resume a video. This would force the user to come up with a key name for every video they'd like to resume that contains a variable link. I assume that mpv's supposed to be ran through the command line, but I am just a casual user who uses GUI. Because of this, it is more user friendly to have the option to make mpv use the video's title to resume. This allows me to just edit the mpv.conf file once and will work the way I want it to. I don't expect to constantly change my config, which is needed with the watch-later-key option.

And as I have said in #9346 (comment), I would like this to be implemented so that I don't need to have a built from source mpv that isn't portable due to its dependency on the .dll files in C:\msys64\mingw64\bin.

Just for reference, here's the link to the original fork of @TAAPArthur's change/commit that I used to test if it had the feature I wanted: options: Add watch-later-use-title.

[qmega]

I don't agree with the idea of passing a watch-later-key to resume a video. This would force the user to come up with a key name for every video they'd like to resume that contains a variable link. I assume that mpv's supposed to be ran through the command line, but I am just a casual user who uses GUI. Because of this, it is more user friendly to have the option to make mpv use the video's title to resume. This allows me to just edit the mpv.conf file once and will work the way I want it to. I don't expect to constantly change my config, which is needed with the watch-later-key option.

The idea isn't that you'd manually pass a key on the command line every time. Rather, if you wanted to always use the title as the key, you'd add a script to your config that sets the watch-later-key to the title when loading a file, so it would still be a one-time change, though a slightly more complicated one. The advantage then is that if you wanted to use the title sometimes but do something else other times, the generic key approach gives you that flexibility.

[TAAPArthur]

Yeah the watch-later-key idea was my (failed) attempt at a compromise to get the change in master. In my workflow, the mpv wrapper I use explicitly sets the title so it would have been trivial to have it additionally set this key. But I agree it would be more complicated in other workflows and that the original version of just having the watch-later-use-title flag is cleaner.

@LittleBenjiBoy I do appreciate the support, but think the chances of this getting merged are near zero. I do keep my fork/patch relatively up to date so you keep referencing that if you're fine with building from source.

[guidocella]

As suggested in #12303 I think this should be closed to instead add an option that resumes playback based on the first bytes of files, replacing the default path hashes and disabling the mechanism to determine which playlist entry to resume from, as everyone who requested variants of this feature doesn't seem to care for that and it would be too slow for playlists of network URLs. This is also necessary to fix mpv-android/mpv-android#542 (Android seeing file descriptors instead of the real URLs). It's not worth adding a generic --watch-later-key option when it's trivially achieved with the short script from #9346 (comment).