Add ability to use save-position-on-quit when file name changes

[TAAPArthur]

Before requesting a new feature make sure it hasn't been requested yet. https://github.com/mpv-player/mpv/labels/meta%3Afeature-request

I primary use mpv to play remote media and the remote server often changes the filename. The exact url is determined by the an external script which launches mpv. For all intents an purposes it is fair to say the url is random but there is some unique, constant metadata that is known to the script that could in theory be passed to mpv. I wish for mpv to be resume position for said remote urls even when the url is completely different

Expected behavior of the wanted feature

I invoke mpv with some flag (like --hash HASH) and said flag (or hash of that flag) is used in place of the filename/url for resuming playback. That is the passed in value is saved instead of the file name and if I invoke mpv with the same value and different file name, it should resume as if the file names were the same.

Alternative behavior of the wanted feature

Instead of adding a new flag, my usecase would be satisfied with using an exiting one like title for the hash. For my usecase at least the title passed in will uniquely identify the video.

Log file

I don't think it'll be helpful but here is the log file: output.txt

[guidocella]

This is possible if you set stream-open-filename in the on_load hook instead of an external script. quit-watch-later will use whatever path you pass to mpv instead of the actual media URL.

[TAAPArthur]

Thanks for the tip. Will look into it.

[TAAPArthur]

@guidocella So I think I understand how hooks work and did as advised. However, writing stream-open-filename just changes the name of the file that is being opened. I wanted to use the exact url/filename passed into mpv to access the media and just wanted a different name/hash saved used for resuming playback.

[guidocella]

The exact url is determined by the an external script which launches mpv

I wanted to use the exact url/filename passed into mpv to access the media

These seem to contradict? You can pass aliases for the media URL to mpv and translate them to the real URL in on_load instead of a script, and the aliases will be the paths used by quit-watch-later. mpv has no other way to achive something similar for URLs (for local files you can use symlinks).

[TAAPArthur]

Let me rephrase. I want to watch video V from some site. The url I'm given could be URL1, URL2, ... URLN. I first pass URL1 into mpv via mpv --tile=V URL1 and exit and save progress. Then I open the video again with mpv --tile=V URL2 and want to resume exactly where I left off. For this second invocation URL1 is no longer known nor valid and I have no control over that. And we can assume V, URL1, URL2 are all independently random so going from V -> URL 1 or URL1 -> V is non trivial.

Using aliases for the url could work but seems really hacky. At that point patching mpv seems easier to me. And I'm not opposed to doing so. Just wanted to check that it wasn't already easily possible and the proposed solution was somewhat reasonable before starting.

[avih]

I want to watch video V from some site. The url I'm given could be URL1, URL2, ... URLN. I first pass URL1 into mpv via mpv --tile=V URL1 and exit and save progress. Then I open the video again with mpv --tile=V URL2 and want to resume exactly where I left off

Using aliases for the url could work but seems really hacky. At that point patching mpv seems easier to me

This is a very very unique use case which probably no one but you ever encounters.

While it's easier for you to solve your problem by patching mpv, it's not beneficial to any other user but yourself and therefore such patch doesn't belong in mpv - more code, more potential for bugs, etc - even if it's a small patch (small patch can still have many bugs - maybe not in the patch code itself, but elsewhere which depends on what the patch changes).

As for your original problem, if you can't solve it with mpv options or scripts, then you can wrap mpv with some shell script which renames the watch-later files as you see fit before and/or after mpv runs.

The watch-later filename is currently an md5 hash of the (verbatim) input file/url, possibly without the path if --ignore-path-in-watch-later-config is specified.

Either way, even if it's impossible to solve it without patching mpv (which I highly doubt), the solution to this use case still does not belong in mpv.

However, if indeed it can't be solved outside of mpv, then you can patch your local copy of mpv and use that.

[avih]

Just to demonstrate concrete issues with the patch, beyond of the complete comment I linked earlier:

Use the specified string instead of the current file name for saving and resuming.

What does "current file name" refer to when playing a playlist? The playlist file/URL (which gets its own watch-later file)? or the first file at the playlist? or maybe the last one? or even all the files at the playlest should save to the same watch-later file? Because currently each playlist entery gets its own watch-later file.

[guidocella]

A script like this would write watch-later config files for the foo and bar path aliases instead of the real URLs:

mp.add_hook('on_load', 50, function (foo, bar)
    local filename = mp.get_property('stream-open-filename')

    if filename == 'foo' then
        mp.set_property('stream-open-filename', 'https://url1')
    elseif filename == 'bar' then
        mp.set_property('stream-open-filename', 'https://url2')
    end
end)

The URLs can be updated as necessary within the script, or it could call a shell script that determines them.

Also your PR always uses the same watch-later-effective-path for every entry in the playlist and for the redirect entries that should be created for each segment of the directory that contains the played file.

[TAAPArthur]

@avih I don't agree with your judgment nor your decision to close without waiting for a response.

This is a very very unique use case which probably no one but you ever encounters.

I don't think that is a fair claim. Many streaming sites (like Crunchyroll, Funimation, VRV, etc) don't have static urls that are directly streamable. I know some solutions get around that by doing the translation inside mpv, but don't think that makes the general usecase uncommon. An example url is

https://vmfst-api.prd.funimationsvc.com/FunimationStoreFront/V2593189/b9b2327b-fb11-44c2-a0ea-e1f6676a29f0_index.m3u8?Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9kMzNldDc3ZXZkOWJnZy5jbG91ZGZyb250Lm5ldC9GdW5pbWF0aW9uU3RvcmVGcm9udC9WMjU5MzE4OS8qIiwiQ29uZGl0aW9uIjp7IkRhdGVMZXNzVGhhbiI6eyJBV1M6RXBvY2hUaW1lIjoxNjM1MjY5MzExfX19XX0_&Signature=Xg9Qqni6~ocdH3r3RjRGW6gVPdi~JWwbPGBGYN0cpwnbF9pAZWslpNAn~8o7Qsr46zeA-8wpYqGvOojjUDaCMzl7dcWtJGO~6d6loWKB1ev-aMgefWXlIMTt3uN-3JjZKaJI29Yuu8pd6T5XadDpy8JfcdiLO4rUlxYv40KAvRqSBSpC6cAjfxbK6x6t59xGt7RRvPEJCV1WGEh7rrPoBk6WWWZTXZqL0xPJaSQpoY1OIBOWARWtfGOyVVjMSNlv2YCgv4e8zHCYkLBDmNmKnYkcdX-yF40CRDAU3etj5VeL7iQnMd8R-l6yLRjUU2~Tkt4VfA8V2v2Dw1yB9d6-3Q__&Key-Pair-Id=APKAIHNXECY27H4O6NIA&rt=1420003

Which is literally what Funimation uses to provide content. I had oversimplified the issue because the url format wasn't the focus and can't be controlled and just treating them as random seemed sufficient to get the point across.

As for your other comments about playlists perhaps that is fair. However that was the intent -- to just ignore the filename and use literally what was passed for the watch later path. Perhaps appending an index would resolve that. Or just being content with --merge-files. Either way I don't think it was such a fatal issue that the PR/issue needed to be immediately closed.

Also probably could manually modify the watch later directory. Think there is an option to save it to a custom path and could manually move it to the one mpv expects on start. But couldn't everything related to resuming playback be done from scripts?

@guidocella Neither foo, bar, url1 or url2 are known before. Sure I can just have the script call the program that does the conversion but that'll be really inefficient. Also I don't believe the example provided will allow one to resume bar from where they left off in foo which misses the goal. Still appreciate the response.

[guidocella]

Many streaming sites (like Crunchyroll, Funimation, VRV, etc) don't have static urls that are directly streamable.

All of these sites are handled by ytdl_hook.lua which does call an external program to do the conversion (youtube-dl) and changes stream-open-filename in the on_load hook exactly like I suggested, that's why you can use quit-watch-later with youtube URLs, or any other site supported by youtube-dl, even if the media URL changes. So I don't see why a second way to do this is necessary.

[TAAPArthur]

All of these sites are handled by ytdl_hook.lua which does call an external program to do the conversion (youtube-dl) and changes stream-open-filename in the on_load hook exactly like I suggested, that's why you can use quit-watch-later with youtube URLs, or any other site supported by youtube-dl, even if the media URL changes. So I don't see why a second way to do this is necessary.

I don't disagree with the claim that I could restructure my script to work with mpv as-is. I could pass in whatever I would have for watch-later-effective-path so long as I could reconstruct what I wanted from it. The difference to me is that I'm using the remote server's api and actually have (one of the final) urls that mpv can already play. Encoding that and passing it to mpv so it can decode it seems convoluted. I invoke my script with some args like play MEDIA_NAME EPISODE_NUM and discover the streamable url and pass it to mpv. Yes I could say pass those args directly to mpv as if they were the file name, use the on_load hook to call back into my script with a new endpoint to get the final url and set stream-open-filename to that. I wasn't really trying to tie into a specific media player (users can change which video player they use) and wanted to pass the same url to any arbitrary one given it could handle it...

Also for the youtube dl case, if the query parameters change, it won't be treated as the same url which may or may not be ideal. Funimation, for example, may have extra query parameters for the user facing url for some reasons. These would be treated as different urls currently when it is the same underlying video (in this case).

P.S. Those sites aren't all handled well by youtube-dl. It is common to get the wrong language (when the language is specified in the url) or to not have subtitles. Then there are also some sites (vrv) that have broken subs such that they need to be read bottom to top. None of this goes against your argument

[guidocella]

I personally think this is a valid feature request now that you explained what you're trying to do more concretely.

[avih]

So far we you did not provide any concrete example. Personally, I don't yet understand the problem exactly, and I don't think it ever happened to me.

The one thing we do know for a fact is that you want to be able to specify the watch later filename.

We can't help unless we see several examples where it can happen to a random Joe, or at the very least in your specific use case with that script. Like, actual example, with concrete random URLs which are effectively the same content, how the user manager to invoke such random URLs, etc - the whole shebang.

Show me how to reproduce the problem, and I want to understand the problem domain 100%, with examples, before we start talking about a solution.

[TAAPArthur]

I think that is perfectly fair and I appreciate your willingness to help. Later today I'll provide

• At least 2 urls that at one point could have been used to play exactly the same remote content
• Examples where the urls on the user-facing website that youtube-dl would parse can vary but refer to the same video
• Both of the above for multiple popular media servers

Do you want the json page/content where I'm getting the urls from too? Just using their (non-public) api but can provide that if it helps.

I can also link the entire script I'm using/have written to go from a media name/episode number to a streamable url. Just don't want to self promote my work without explicit prompt. Probably could make a case just using Funimation without my script since the website will just sometimes give different urls depending on how you got there and/or if you are logged in or not. But if you want to use the actual script I'm using/have written, I could give you something that could generate 2 different urls that play the same video

[avih]

Do you want the json page/content where I'm getting the urls from too?

Whatever you think is needed to help me reproduce the problem on my own, without you feeding me the URL-variants to try, and preferably without giving me any URLs at all (e.g. "visit youtibe at the browser, drag the URL to mpv..." etc). I want to know how it can happen to a random user, and I want to be able to make it happen to me from start to finish.

If that can't happen because private/whatever, then I need to understand how it happens in your use case from start to finish - who has control over mpv? who is the user? the user of what? (mpv? or some program which you maintain?), what's the sequence of events from-start-to-finish which ends up with the problem, etc.

And if you currently have some solution to this problem, even if partial or hacky, then I want to understand it too, because it could help understand the problem better.

[garoto]

If only OP had provided some real real use-cases examples, or, at least, cooked some mock-up URLs with enough similitude to his actual real world use-case. Imagine that.

[TAAPArthur]

@garoto I'll accept that criticism if and only if when I can back and provide those urls, we reach a different conclusion of them being random. Some maintainers like want the issue simplified and I don't think my description of the problem was inaccurate. What I don't understand however is why you'd make such a statement after I'd agreed to provide the urls.

Also don't misunderstand; what I stated in the initial description is what I wanted. The ideal solution would allowing resuming playback from 2 different servers hosting the same content which is what the patch I provided does. It also works on local files too without having to create unneeded symlinks.

[TAAPArthur]

@avih

Youtube

So starting off with the general youtube-dl example. Here are 2 urls that clearly refer to the same video

https://www.youtube.com/watch?v=2nYozPLpJRE
https://www.youtube.com/watch?v=2nYozPLpJRE&list=PL6EC7B047181AD013

One is in a playlist and one isn't, but it the same video. Similar problem when playing a video directly or from your liked videos. This is a more specific case that what I'm trying to solve as both urls are valid and one could be derived from the other. If you want your own example just find a video and find the same video in a playlist (or add it to your own or liked videos). When you access it from the playlist vs dependently the url is slightly different.

Funimation

Their urls used to be able to control the language of the video, but can't seem to access that from the UI after their recent redesign. It used to be that one could append "?lang=jap" and change the language if possible and thing playback should be resumed in that case. But on that note youtube-dl or similar doesn't know what language you want....

Crunchyroll

Crunchyroll has 2 websites. The latter is only for premium members I believe which is why I'm just providing the urls. Below are urls to play One piece episode 1

https://www.crunchyroll.com/one-piece/episode-1-im-luffy-the-man-whos-gonna-be-king-of-the-pirates-650673
https://beta.crunchyroll.com/watch/GR3VWXP96/im-luffy-the-man-whos-gonna-be-king-of-the-pirates

If you happen to have an account you can just search "One Piece" on the beta site and you'll get the same urls. You should be able to search the normal site regardless.

Crunchyroll vs VRV

All anime on crunchyroll is on VRV because the latter is owned by the former. So say watching One Piece on crunchyroll is the same (content-wise) as VRV. One reason to switch in the middle of playback is that youtube-dl may grab hardsubs that aren't for your language. Can discover vrv urls by searching for something like "One Piece". Here is the VRV link for convenience: https://vrv.co/watch/GR3VWXP96/One-Piece:Im-Luffy-The-Man-Whos-Gonna-Be-King-of-the-Pirates.

And not gonna lie between what could be a 2 min opening and some shows/episodes where characters don't talk, it can take a while to notice the subs are off.

With my script

The above are for general cases. To go into more detail amount my usecase, I have this script that will allow play media by name instead of by url. Only dependency is python-requests. I've only tested it on Linux. Setup could go something like

amt search --server crunchyroll_anime "One Piece"

Select some "season". It doesn't matter which; I did "One Piece: East Blue (1-61)". Then one could play the media with

amt play --limit 1 

The script will output every external command it runs and every url requests it makes. I recommend quitting mpv such that it generates a non-0 exit status other the next video will play on next invocations Exiting with 0, indicates that the video has been fully watched. But notice that I don't have the url that youtube-dl would use. The backend is using the api and/or scrapping the site to find the raw video file.

In my case the url I get is

https://pl.crunchyroll.com/evs1/4d5ebef8c5e11efef476910028f49148/assets/oih0k1cp5uqyvui_,3812462.mp4,3812461.mp4,3812460.mp4,.urlset/master.m3u8?Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cCo6Ly9wbC5jcnVuY2h5cm9sbC5jb20vZXZzMS80ZDVlYmVmOGM1ZTExZWZlZjQ3NjkxMDAyOGY0OTE0OC9hc3NldHMvb2loMGsxY3A1dXF5dnVpXywzODEyNDYyLm1wNCwzODEyNDYxLm1wNCwzODEyNDYwLm1wNCwudXJsc2V0L21hc3Rlci5tM3U4IiwiQ29uZGl0aW9uIjp7IkRhdGVMZXNzVGhhbiI6eyJBV1M6RXBvY2hUaW1lIjoxNjM1NDY4NDEyfX19XX0_&Signature=CVaE5rL6aTY9Lawvl7BzbsskHbV430SC8-X2w6gcLlpTQzK6nFo2kanznd1vqW9ExoC~NgsT9qlYm2FsR9quVFlQgT1yQ0vtfaEM04onMoWFJ4zxq9-TBy3oVcMglUxhDkadx-CNmmFo1vcCNSJFDwK2bPMQVE2acyGpHnEP2kWa4zq1e22PkqReXQZbKEf6bIGzcrF9YPIWTiKnv2~ZNtS1W1b7WPx5rDC8WhUwXVKDojoASTCS4AOXqJNS1uRUjXYLRaapDyPpaFMwJBP3cIY1WyZ9fZqQVbJjgd31QfB2hwQNHW~PtgnM3wAUVBywZ8DcTrIJ17dagXpOZLi8dQ__&Key-Pair-Id=APKAJMWSQ5S7ZB3MF5VA

Can be re-run with amt play if mpv existed with non-zero exit status or amt play crunchyroll_anime 0 to play the last completed episode. For me right afterwards I get the same url. I don't know exactly when rerunning when generate a new url. I watch anime with a group weekly and we sometimes stop in the middle of a show and notice that the following week the resume-playback feature didn't trigger so assume a new url was generated.

Let's try again with a different server Repeating the above steps with vrv instead (literally replace "crunchyroll_anime" with "vrv" in the above commands). The generated url is

https://pl.crunchyroll.com/evs1/6650fe42f07b7f15d4d74f55c7edbfae/assets/oih0k1cp5uqyvui_,1890411.mp4,1890405.mp4,1890399.mp4,1890417.mp4,.urlset/manifest.mpd?Expires=1635470847&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9wbC5jcnVuY2h5cm9sbC5jb20vZXZzMS82NjUwZmU0MmYwN2I3ZjE1ZDRkNzRmNTVjN2VkYmZhZS9hc3NldHMvb2loMGsxY3A1dXF5dnVpXywxODkwNDExLm1wNCwxODkwNDA1Lm1wNCwxODkwMzk5Lm1wNCwxODkwNDE3Lm1wNCwudXJsc2V0L21hbmlmZXN0Lm1wZCIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTYzNTQ3MDg0N319fV19&Signature=tMKVv1bgJaDHyB0lblfH4LjSh-z8oNZALQaS35yaCOt-5sAvYqUC3VTjXP8b1IvvitxHap1BT0VpzMsQmRP5Ba5Gpz~heKrV5OIST0GU3gXmQeShKlcuHMNL9Tu3EA~CRQgbYC4N5AA~LP2fbcL12KnuUF~8Pe4vGz3hpr4AcZnfB6ycRgg~UOym~~ce7jLoUphAiaT1VJTHREvwGCaIRd1aqGEM2y-zuV6lqWKf7KDEnG2KT4D4KIYxn4N8Aqo7LrbiMZ6vl3DnnOmHLtY80CtEZm317agUmPgcyQHcgxI7-G-TcCcQ89J0b604VSQE4BikLDEckgozsf2C29b2Ow__&Key-Pair-Id=APKAJMWSQ5S7ZB3MF5VA

Rerunning amt play --abs vrv 1

https://pl.crunchyroll.com/evs1/6650fe42f07b7f15d4d74f55c7edbfae/assets/oih0k1cp5uqyvui_,1890411.mp4,1890405.mp4,1890399.mp4,1890417.mp4,.urlset/manifest.mpd?Expires=1635470911&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9wbC5jcnVuY2h5cm9sbC5jb20vZXZzMS82NjUwZmU0MmYwN2I3ZjE1ZDRkNzRmNTVjN2VkYmZhZS9hc3NldHMvb2loMGsxY3A1dXF5dnVpXywxODkwNDExLm1wNCwxODkwNDA1Lm1wNCwxODkwMzk5Lm1wNCwxODkwNDE3Lm1wNCwudXJsc2V0L21hbmlmZXN0Lm1wZCIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTYzNTQ3MDkxMX19fV19&Signature=X1Q6W6aN7vuaGcdvC07B9SBXnoXuc1Za-Wul2fbjto401QyYKLzFxwrCo-FXgguQ6SA66ZQOOENcchWMZWx5rpSaPp0QkiSpo0T4YIngnEgtADY5itM03jfTIAj~aGFX1ITDfVOPVsZ0OiJxy5IeGx0rN6J9T9DmyuUAQ2FZpi3hQAJ7qUSzicKpC-MRiJTHJz9N1w3l9TAWKs9Z6J2bfOOGvlclHGudcotJ7EodrLRB2mC~zsnLd~rKqKhs9FDDmkQLuYxj3enr5S2E1lW7cKEZYImZi0PnTzMhkNfVGneoseQwY5YDP7w~QX102i2vqFuu~ZKSd4Ta~WjBZijNBg__&Key-Pair-Id=APKAJMWSQ5S7ZB3MF5VA

And a third time amt play --abs vrv 1

https://pl.crunchyroll.com/evs1/6650fe42f07b7f15d4d74f55c7edbfae/assets/oih0k1cp5uqyvui_,1890411.mp4,1890405.mp4,1890399.mp4,1890417.mp4,.urlset/manifest.mpd?Expires=1635471033&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9wbC5jcnVuY2h5cm9sbC5jb20vZXZzMS82NjUwZmU0MmYwN2I3ZjE1ZDRkNzRmNTVjN2VkYmZhZS9hc3NldHMvb2loMGsxY3A1dXF5dnVpXywxODkwNDExLm1wNCwxODkwNDA1Lm1wNCwxODkwMzk5Lm1wNCwxODkwNDE3Lm1wNCwudXJsc2V0L21hbmlmZXN0Lm1wZCIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTYzNTQ3MTAzM319fV19&Signature=Go7MWpdUPTFVRf2cXGYtj2BhrmzGdViZGafp7AVu2qCWGhPWztQBgV-VobNB1DRzHUMc-kFEEdgWbLLO5enF98f97HWhrtfSf8ioH~Xcd7KzjRNWk7TZIPlhaKfsaAEXKHCgfPxUU4yOjhzap1RLpUGUDUUslOjEMWtmMJYjzLZSTuYYI8wO~sQ2xqAun7U8g3w5ZQPwG~ySAFesN7tRsRIkuulgBfg~vOVFMr4thByx8dPr4L8rtoB4cIE2w4ef6ea2jM8rNkBMrb7n1lDPkK8SMb2woOzD2vgjYAd8zGg8Sw6rNvykI2CeWLOgsMbXwRrhltUT1Ttw3MeiXjuiYw__&Key-Pair-Id=APKAJMWSQ5S7ZB3MF5VA

Here you can see different urls for the same video. And I'm sure you could tell just from the format that the urls aren't stable.

Ran through all these commands myself as I was writing this up, but let me know if you run into any problems.

[TAAPArthur]

Just want to make sure I covered everything you wanted

Whatever you think is needed to help me reproduce the problem on my own, without you feeding me the URL-variants to try, and preferably without giving me any URLs at all (e.g. "visit youtibe at the browser, drag the URL to mpv..." etc). I want to know how it can happen to a random user, and I want to be able to make it happen to me from start to finish.

I included some urls for convenience but it should be clear how to get your own.

If that can't happen because private/whatever, then I need to understand how it happens in your use case from start to finish - who has control over mpv? who is the user? the user of what? (mpv? or some program which you maintain?), what's the sequence of events from-start-to-finish which ends up with the problem, etc.

In my usecase, the mpv is invoked through my script. Users can change the actual invocation command but ideally the default would be sane in that it actually plays the video with no additional scrips needed. The current default command is mpv --sub-file-paths=\"$PWD/.subtitles\" --sub-auto=all --title={title} {media} where the stuff in {} gets replaced with the title/url

And if you currently have some solution to this problem, even if partial or hacky, then I want to understand it too, because it could help understand the problem better.

What I submitted in the patch is the closest thing I have to a solution. It added a new config options that could be amended to the default mpv invocation. Planned to either just use the title as watch-later-effective-path and/or combine that with the media id. If default mpv can't handle this case, then plan to leave the default command as it, patch mpv for my uses and have my only lua script like:

if mp.get_property("watch-later-effective-path") == "" then
    mp.set_property("watch-later-effective-path", mp.get_property("title"))
end

I will say the worse instance of this problem is when the stream dies in the middle of playback and exiting mpv and rerunning takes you back to the beginning.

[TAAPArthur]

Just to elaborate a bit on a a standard workflow... I have ctrl+c quit-watch-later 4 line in my input.conf and exiting mpv with a 0 exit status causes amt to assume the video was successfully watched to completion, mark the video as watched and potentially play the next episode.

So suppose I'm marathoning One Piece and and currently on episode 100

1. `amt play "One Piece"
2. mpv opens episode 100
3. video finishes normally; amt marks the episode as watched and plays the next
4. mpv opens episode 101
5. video finishes normally; amt marks the episode as watched and plays the next
6. mpv opens episode 102
7. I get interrupted for some reason and use "ctrl+c" to close
8. mpv exists with non-zero exit status
9. amt exits
10. I come back later
11. `amt play "One Piece"
12. mpv opens episode 102. Weather it remembers exactly where I left off depends on how long I've been gone and/or whomever is providing the media. Ideally it would resume where I left off, which is what I'm trying to achieve

[qmega]

Depending on how far you are willing to specialize your script for mpv... You could pass in your desired watch_later hash source as the filename to play, pass the actual stream URL separately and set it through a script. You'd still be doing the conversion outside mpv and you wouldn't have to patch mpv.

A very simple example that only works for a single url per mpv invocation:

mp.add_hook("on_load", 50, function ()
    mp.set_property("stream-open-filename", mp.get_opt("real-stream-url"))
end)

The trick is that you then swap the title and the real url when you call mpv:

mpv --script=/path/to/script.lua --script-opts-append=real-stream-url='(real url to play goes here)' 'AMT/One Piece Episode 100'

You could flesh out the script to accept a mapping of input titles (mp.get_property("path")) to stream-open-filenames.

It's definitely a hack, but it works, should be pretty stable, and is doable with stock mpv.

[avih]

Before we continue, let's make one thing clear - I'm well aware that two URLs can point to identical content. One only needs to copy a local file a.mkv to b.mkv and start a local web server, which will have the files as different URLs with identical content. Same for the actual web, clearly two URLs can have identical content.

This is not limited to URLs either. With the same example above, they can play a.mkv locally (not via a server), and then play b.mkv and expect it to resume correctly.

What I requested was a description of how a reasonably normal user gets to the state where they face the problem - what they actually do - visit a page, click this or that, etc. To understand the workflow from start to finish which ends up with the problem.

The fact that two URLs with identical content exists doesn't explain how the user got from playing one to want to resume the other, and that's what I want to understand - the normal scenario where it happens - not a made-up scenario where you play your local 128.0.0.1/a.mkv file and then play b.mkv from your filesystem and expect it to resume corrrectly.

So let's go over your examples.

Youtube ... This is a more specific case that what I'm trying to solve ... Funimation ... can't seem to access that

Great, let's ignore those for now, as we're indeed interested in the general case, and we're not interested in cases which don't happen anymore.

Crunchyroll ... If you happen to have an account you can just search "One Piece" on the beta site and you'll get the same urls. You should be able to search the normal site regardless.

This is, again, an example that two URLs with identical content can exist. On its own this fact is not interesting.

So I'll try to guess the scenario: The user searches some content at the public site, start playing it in mpv, quit-watch-later, then gets to the beta site, searches for the same content, gets a different URL, and expects it to resume.

Is this correct? If not, please provide a real-world example which ends up with the problem.

Crunchyroll/VRV ... One reason to switch in the middle of playback is that youtube-dl may grab hardsubs that aren't for your language ... could be a 2 min opening ... it can take a while to notice the subs are off.

It's still not a concrete workflow scnario, so I'll guess an example here too: The user searches some content on VRV, finds a URL, starts mpv with that URL, few minutes later they realize that it has bad hard subs, so they quit-watch-later, then visit Crynchyroll, search the same content, and get the same content but with a different link. Now they play it in mpv and expect it to resume.

Do note that in this case it's a completely different file - one has hard subs and the other doesn't. They could be different codecs, sizes, etc. And you still expect mpv to resume from the same point.

Did I get it correctly?

With my script ...

Not yet. For obvious reason I'm much more interested in the general case. These reasons include, among others, the fact that you opened a PR with a solution which should supposedly help the general case, and not only your private use case.

Were there other examples which I missed?

I would have preferred much more common examples, but for now let's assume that I agree that the examples above are real and good and general, and we want to merge your patch to solve it.

What's next for the two users which I described above?

Clearly their problem will not get magically solved just because the patch was merged in mpv, right? They need to actually use that option to make any kind of difference.

How do they use it?

Is it enough that they put some value at their mpv.conf file? If not, what do they actually need to do in order for your patch to solve their problem?

And maybe most importantly, do you expect a reasonably normal user to do what it takes for the patch to fix the problem?

[TAAPArthur]

The user searches some content at the public site, start playing it in mpv, quit-watch-later, then gets to the beta site, searches for the same content, gets a different URL, and expects it to resume.

Is this correct? If not, please provide a real-world example which ends up with the problem.

Basically. An underlying assumption is the webplayer for some of these sites are kinda worse than mpv. There are already well known scripts/browser extensions that can take a url and pipe it into mpv. So could imagine you goto crunchyroll, start playing a video, stop for whatever reason and resume on the beta site or vise versa. Why switch sites? Because you are currently forced to the beta if you are logged in and to the old/normal site otherwise. So if your cookies expire and you get logged out which will happen, you'll find yourself on the normal site.

Youtube ... This is a more specific case that what I'm trying to solve ... Funimation ... can't seem to access that

Great, let's ignore those for now, as we're indeed interested in the general case, and we're not interested >in cases which don't happen anymore.

Perhaps there was a misunderstanding. The youtube case is valid I believe. It is the same video weather you access from a playlist or not. Searching for a video by name content can yield either. The examples I gave where from looking up DBZA episode 1. It is just a more specific case since the urls are related to each other so it could be solved without solving the general problem. Some subtle aspect of the Funimation example was that even the user-visible urls aren't constant.

It's still not a concrete workflow scnario, so I'll guess an example here too: The user searches some content on VRV, finds a URL, starts mpv with that URL, few minutes later they realize that it has bad hard subs, so they quit-watch-later, then visit Crynchyroll, search the same content, and get the same content but with a different link. Now they play it in mpv and expect it to resume.

Do note that in this case it's a completely different file - one has hard subs and the other doesn't. They could be different codecs, sizes, etc. And you still expect mpv to resume from the same point.

Did I get it correctly?

Yes. For this case the raw video is probably the same. If you inspect their api they will often give different videos for different audio languages and/or different subtitles. Guess I can't guarantee they are all exactly the same, but they are generally supposed to believe users would expect them too. The most often case is sub vs dub and I personally haven't seen content different between the 2... at least not between crunchyroll and vrv.

If not, what do they actually need to do in order for your patch to solve their problem?

Ideally set the watch-later-effective-path to something that unique identifies the video. Which is trivial if the are invoking it manually. They'd just have to append "--watch-later-effective-path One Piece ep 1". One could attempt to default this to the title, but youtube-dl doesn't always detect the title correctly so explicitly setting it most reliable. Or maybe I misunderstood the question. You've seen (closed) the PR with a working example so you know about the new cli option. Are you asking how they know what to set it to? Because they probably know what they are trying to watch?

And maybe most importantly, do you expect a reasonably normal user to do what it takes for the patch to fix the problem?

They just have to set a flag. They know what they want to watch - media name + episode number is probably enough.

[TAAPArthur]

The fact that two URLs with identical content exists doesn't explain how the user got from playing one to want to resume the other, and that's what I want to understand - the normal scenario where it happens - not a made-up scenario where you play your local 128.0.0.1/a.mkv file and then play b.mkv from your filesystem and expect it to resume corrrectly.

You say this but this is what I'm literally asking for. If you want another example, I'm watching some media online while the torrent downloads and when it finises I want to switch to the torrent and resume where I left of. And I'm doing this as part of some group watch so I'm already assuming the videos were the same. Or it could be I'm downloading a video through a browser and it saves it initially as MEDIA.part until the download finishes. So If I open the video to MEDIA.part then once the download finishes, I want to resume it from just MEDIA. Another examples is for sites that mirror each other. Like there's mysiteA.com/MEDIA and mysiteB.com which are guaranteed to have the same content either because they point to the same server (2 dns address or 2 ip address mapping) or the servers mirror.

I'm glad we agree that fact examples like this are plenty. I don't see why they aren't interesting. This is the feature I'm requesting -- to be able to treat 2 arbitrary paths as the same for the purposes of resuming playback. Are you just doubting these situations actually happen or the effectiveness of the proposed solution?

I would have preferred much more common examples

I can't answer how often the average joe gets into these situations. They happen to me fairly often and could happen to anyone. Switching languages and subs is a problem people is a common annoyance with existing web UIs among my circle. Yes it does assume that you trust the 2 videos to actually be the same but that's why it is a dedicated option rather than defaulting to say the title.

[avih]

The youtube case is valid I believe

It's valid but you claimed it's not generic enough, and I ignored it on this basis.

They'd just have to append "--watch-later-effectice-path One Piece ep 1"

So you actually expect them to add a different custom argument every time they invoke mpv with such URL? that's never going to happen. Or maybe it would, hard to tell, because you didn't actually describe how they invoke mpv in your "example" (neither did I). In my example they drag the URL from the browser to an mpv window, so they can't add an argument even if they wanted to.

Also, even if they have the patience to pass a different custom argument every time they invoke URL without any typos, then can't use a playlist anymore.

And if we're talking about users which have some scripting setup which automates launching mpv, then maybe they could use it - still without playlist support.

But in such case they could also do what @guidocella and @qmega suggested and solve it with a trivial mpv script and without the patch.

[avih]

The gist of your problem scenario is that you know in advance that some video with file/URL X should use a watch-later file as if it was Y.

It cannot be automated for a random user by an mpv option, because the knowledge that X should map to Y must be known before mpv is launched.

So for users which do use some automation, the example lua script provided above should solve this problem trivially.

[TAAPArthur]

It's valid but you claimed it's not generic enough, and I ignored it on this basis.

Just in the case that a solution only covering that case isn't desired. The solution I'm proposing covers this case however and think it is fair to use this as evidence for this feature

The gist of your problem scenario is that you know in advance that some video with file/URL X should use a watch-later file as if it was Y.

I phrase it as some video with file/URL X and some video with file/URL Y should use watch-later file as if Z where Z is known the the users.

So you actually expect them to add a different custom argument every time they invoke mpv with such URL? that's never going to happen. Or maybe it would, hard to tell, because you didn't actually describe how they invoke mpv in your "example" (neither did I). In my example they drag the URL from the browser to an mpv window, so they can't add an argument even if they wanted to.

Well I've invoking mpv with a script that doesn't make any assumptions on users custom scripts. In other words I'd want the syntax to be valid on vanilla mpv which is why I didn't like @qmega's suggestion. And with that setting it to the watch-latter-effective-path to media_id + title is trivial. By second choice would be goto to the website and question and copying the url. So going from mpv --title=OP1 VIDEO_URL to mpv --title=OP1 --watch-later-effective-path=OP1 VIDEO_URL doesn't seem unreasonable but this is coming from someone who specifies title.

It cannot be automated for a random user by an mpv option, because the knowledge that X should map to Y must be known before mpv is launched.

It can be automated the same way the original url is gotten. If that's manual may be too. It depends on their workflow. If they will also resume from the same video, they could just set it to a constant or make it some function of the url. Like mpv --watch-later-effective-path=crunchyroll URL assuming URL is the last crunchyroll link known. Like if the video just ended because of internet problems, the stream died, computer crashed etc). If they are open to scripting, it could be automatically set to the domain of the url. There are plently of valid usecases where videos are watched in a somewhat predictable order

Also, even if they have the patience to pass a different custom argument every time they invoke URL without any typos, then can't use a playlist anymore.

So I believe playlists work with the patch as-is if --merge-file is specified since mpv treats it as one giant file right? But yes I don't use playlists and don't really expect this option to be used with playlists. If we wanted playlist support, we could append the index into the playlist to --watch-later-effective-path. So mpv --watch-later-effective-path=OP ep1 ep2 ep3 which would use OP1 OP2 OP3 as a filename for resuming playback. Works for my case and would allow use for a playback. Wouldn't work if you wanted to use mpv --watch-later-effective-path=OP ep2. We could change it to make mpv --watch-later-effective-path=OP2 ep2 (by not appending the index to the first option).

But in such case they could also do what @guidocella and @qmega suggested and solve it with a trivial mpv script and without the patch.

Both of their suggestions involve passing a url that mpv natively cannot handle. That is it relies on mpv having lua/scripting support and a dedicated hook setup. It is one thing if mpv isn't configured correctly the resume-play feature doesn't work correctly in all cases and another if the video can't play at all. Especially when setting defaults that other people will use. So an additional requirement is that vanilla mpv should always be able to play the url/file passed in assuming it supports it without the use of hooks. Believe someone suggested a wrapper around mpv and yes that could work but think the situation is common enough and the fix simple enough to justify mpv having proper support.

[TAAPArthur]

I guess you were clear that you wanted a workflow: I want to watch https://vrv.co/watch/GR3VWXP96/One-Piece:Im-Luffy-The-Man-Whos-Gonna-Be-King-of-the-Pirates. I got to this link in the browser and use some extension/script to spawn mpv with this url. And for some reasons I discussed above, I want to switch to crunchyroll. So I go visit https://beta.crunchyroll.com/watch/GR3VWXP96/Im-Luffy-The-Man-Whos-Gonna-Be-King-of-the-Pirates. Going to out on a limb and and say there are properties of these user-facing urls to associate the 2 urls to each other that can be derived outside mpv when invoking the script or via some lua script. @qmega solution could extend to this use case if I had parsing both internally and externally to mpv and was ok with the the video not loading in mpv didn't have this specific custom configuration.

Just trying to illustrate that it could be use for automation via cli option. Example also applies to youtube videos by only caring about the v parameter and domain instead of the entire url. Or if you are that guy who will also resume whatever you were last watching, you could just set it to a constant and use --no-resume-playback or a different constant on exceptions

[avih]

It can be automated the same way the original url is gotten

It can't, because if you drag the URL from the browser to mpv, or double click a media file in a file manager, then there's no custom automation in place where it oculd fit. I'd guess that these cases are orders of magnitude more common than users who pass everything which goes to mpv through some custom automation system.

Only users which already have their own automation system in place can maybe fit it into their existing system.

All these are exactly the reasons why I wanted YOU to describe how a random user ends up facing the problem. Because how they get there is super important in assessing which kinds of solutions could work for them.

But you keep not providing such examples, and I have to guess how the user gets there.

The only "real" workflow examples you provide are your own, which is a super non trivial system. It's great that you set it up, but it's far from what most mpv user have in place (this is an educated guess).

As long as you keep claiming that your solution solves the problem for random users of mpv, I'll keep getting back to "show me exactly how they get there", and you'll probably keep not providing actual examples with concrete steps, and I'll keep assuming that your solution only works for you until you show me otherwise.

So I believe playlists work with the patch as-is if --merge-file is specified since mpv treats it as one giant file right? But yes I don't use playlists and don't really expect this option to be used with playlists

In other words, yes, it does break watch-later for playlist items, and personally you don't particularly care about this use case.

OK, at least we have that in place.

Both of their suggestions involve passing a url that mpv natively cannot handle. That is it relies on mpv having lua/scripting support and a dedicated hook setup

Yes, it does require a custom setup, but so does your solution. Both don't help random users, both only help users with a custom automation in place, and both are trivial if one has such automation. The difference is that one requires patching mpv (yours), and the other doesn't because it already works today.

[qmega]

It seems to me that a normalized watch-later name makes sense as a file-local option. ytdl_hook and similar scripts could set that in a load hook, and external scripts that call mpv could set it on each file with --{ / --}. (I agree with @avih that a user passing a watch-later path explicitly in a direct manual mpv invocation feels unrealistic.)

A trivial example for youtube -- where the user calls mpv directly, with no external wrapper -- is opening a video with a t= parameter (or a playlist= parameter), saving state, then opening the same video from a fresh url without said parameter. You'd probably want mpv to resume where you left off from the first link, but it won't, because the URL string is different. The URLs could be normalized by ytdl_hook to include only the video ID, and not time / playlist / whatever else, and that would fix that use case. It can't be addressed by passing in a fake original path because there's no wrapper for mpv in this case, and because some of the parameters that we'd want to strip for the sake of watch-later are actually used by ytdl_hook for other things. This is admittedly not something I can remember needing myself, but it does seem plausible.

Another potential use case for normalization (which is now the way I see this feature) is #1027, which is actually for local files, but deals with a filesystem that normalizes Unicode (which I believe is true of the default filesystems on Mac and Windows) while mpv doesn't. This is probably sufficiently normal-user triggerable as well; all you have to do is play the same file from the terminal and a file manager. I think Akemi did something since then that might have addressed it, though. Or at least that use case could reasonably be implemented in core mpv as a by-default Mac-specific thing if it hasn't already.

One more thing that comes to mind is scrubbing auth data from URLs (e.g. smb, sftp with password). It requires so many coinciding factors that I hesitate to even mention it, but hypothetically, given a known filename and username, watch_later could allow an offline brute-force against md5 (which is cryptographically weak) instead of an online attack against a server.

There are probably more out there. They're probably all edge cases, but allowing the watch later path to be overriden per file seems like a fairly low-impact way to make them all workable.

@qmega solution could extend to this use case if I had parsing both internally and externally to mpv and was ok with the the video not loading in mpv didn't have this specific custom configuration.

Just to be clear, I don't see anywhere you'd need parsing internally to mpv, nor would a script like that need to be part of the user's local config. You could ship the script with your program and point mpv to it on the command line (which is exactly what my example command line did). It's still absolutely a hack, though. It doesn't generalize, and since it changes the meaning of the original path, it has the potential to conflict with other user scripts or configuration. Being able to specify a watch-later name for each file/stream would certainly be preferable.

[TAAPArthur]

It can't, because if you drag the URL from the browser to mpv, or double click a media file in a file manager, then there's no custom automation in place where it oculd fit. I'd guess that these cases are orders of magnitude more common than users who pass everything which goes to mpv through some custom automation system.

I'd guess this isn't true. I'm thinking of users of surf of vimb or other minimal browsers that either can't play many/most web videos. What scripts like that can do is pipe the url into a custom player. Do you not believe it is possible or common? That workflow is that you navigate the url in question, and use some keybinding to invoke mpv and pass the url in

But you keep not providing such examples, and I have to guess how the user gets there.

I'm trying to provide examples. I'm not sure what you are looking for. I thought my last message was a detailed example. Instead of saying got to site X and find episode Y of series Z I'm just giving the url. I can spell it out but doubt that's where the disconnect is happening. I feel like I'm providing many examples from different providers. Perhaps explaining how they are different than what you are looking for helps.

So I believe playlists work with the patch as-is if --merge-file is specified since mpv treats it as one giant file right? But yes I don't use playlists and don't really expect this option to be used with playlists

In other words, yes, it does break watch-later for playlist items, and personally you don't particularly care about this use case.

That isn't a fair conclusion. I'm saying it doesn't break playlists with merge-file and that the solutoin could be extended if that was a deal breaker.

[TAAPArthur]

@qmega solution could extend to this use case if I had parsing both internally and externally to mpv and was ok with the the video not loading in mpv didn't have this specific custom configuration.

Just to be clear, I don't see anywhere you'd need parsing internally to mpv

By internally I meant with a lua script or similar. As opposed to the caller of mpv doing the parsing. I was trying to say that either whomever invoked mpv would need to be aware or mpv ( specifically some lua script) needed to be aware of what was being done. I didn't mean to apply mpv binary had to be patched.

nor would a script like that need to be part of the user's local config. You could ship the script with your program and point mpv to it on the command line (which is exactly what my example command line did).

Fair. I had over looked that. Yeah that satisfies all my criteria.

[avih]

I'd guess this isn't true. I'm thinking of users of surf of vimb or other minimal browsers that either can't play many/most web videos

I'm willing to bet a lot of real money that you can't provide any kind of reasonable data which supports the claim that users or normal browsers are not orders of magnitude more than users of vimb or surf.

But I'll save you the trouble. Even if we assume that all linux/bsd users to use vimb and surf exclusively (which is very very far from truth), there are still orders of magnitude more windows/osx users which don't use surf or vimb.

[TAAPArthur]

Thank you for saving me the trouble. Do X% percent of users of mpv have to use a feature for it to be worth it? I guess you said "common" and that could be take multiple ways. I took that to me that a fair amount of users (more than just me) could take advantage of it.

EDIT: I don't think everyone or even most people would. I would guess a large amount of people don't know about watch-later commands at all (I only found out because I was explicitly looking for something like it) let alone the more obscure ones like watch-later-dir. I thought you were looking for evidence that this could extend to more people rather than just me (which everyone else on the threads seems to buy)

[avih]

Do X% percent of users of mpv have to use a feature for it to be worth it?

No, I only said that there are orders of magnitude more users which don't have any automation in place, and you said it isn't true, and I said I'm willing to bet real money that it is true.

[avih]

I'm saying that the only users which have the setup and knowledge to map arbitrary file/URL X to watch-later data Y before mpv is launched are advanced users, which are comfortable with scripting and other tools.

And for those users the mpv-scripting solution as suggested above works the same as any other - it requires some simple tweaks of their setup, and then it works.

[TAAPArthur]

Do X% percent of users of mpv have to use a feature for it to be worth it?

No, I only said that there are orders of magnitude more users which don't have any automation in place, and you disagreed, and then I disagreed with your disagreement.

I think the results would shift dramatically if you filter by people who are playing remote media. Probably would shift even more in my favor if you include those that currently use resume-from-playback (ie actually save the watch-later file) If the majority of these people are manually using the browser and copying the url to mpv manually... well that's unfortunate for them.

orders of magnitude more users which don't have any automation in place

So what was the purpose of this statement then? It doesn't make a claim that this patch isn't useful but that most people won't use it. Isn't this true for like every cli arg of mpv?

[avih]

So what was the purpose of this statement then?

To show that it only applies to a very specific set of users. Users which can automate and script and are comfortable with tools. Users which could already solve the problem with existing mpv capabilities.

[TAAPArthur]

I'm saying that the only users which have the setup and knowledge to map arbitrary file/URL X to watch-later data Y before mpv is launched are advanced users

Does anyone with cli knowledge count as an advanced user? mpv specific knowledge and/or lua wouldn't be needed with this patch.

So the point I don't understand is why watch-later feature and all of its related options were added in the first place? I think this is more useful than half of those options. But when you said average joe, yes I was filtering by these "advanced users". I think everyone I know who uses mpv would fit into this category. You know better than I, but I would have thought people who weren't comfortable with scripting would have used other player like vlc or something else with a graphical menu. I mean when you have to configure setting in a text file, is passing an extra cli flag that unreasonable.

So is if fair to say your stance is that this use case only applies to "advanced" users and we can figure it out on our own withing mpv's existing features even if said solution is hacky? And it would need to apply "non-advance" users for it to get added to mpv?

[avih]

Let's just agree to disagree.

[TAAPArthur]

Let's just agree to disagree.

What? I ask for clarification on your stance and rational and that's your response. I feel like their are 2 other people who think this is reasonable. And I'm trying to understand why you are against it. Ending the conversation with such a statement isn't helpful. I don't know what we are disagreeing on besides the conclusion.

[avih]

I don't have endless time to discuss this. I'm not convinced. That's as far as it goes for me. If any other mpv developer feels like continuing this discussion and/or whatever, they're free to do so.

[avih]

For future reference, I'm posting a solution similar to what @guidocella and @qmega suggested earlier:

To solve the problem agreed above that a file/URL REAL_URL needs to use a watch-later file as if it was file/URL WATCH_AS, and the user knows REAL_URL and WATCH_AS before launching mpv, and they launch mpv to play only this one file (not a playlist), then:

Instead of using the solution by @TAAPArthur as mentioned above and in a PR like so:

mpv --watch-later-effective-path=WATCH_AS  REAL_URL

One could use unpatched mpv as follows:

1. Do once: place this script as ~~/scripts/watch-later-path.lua:

   mp.add_hook("on_load", 50, function ()
   local realurl = mp.get_opt("real-stream-url")
   if realurl then
       mp.set_property("stream-open-filename", realurl)
   end
   end)

2. Whenever one wants to make use of this script to address the problem, they need to launch mpv like so:

   mpv --script-opts-append=real-stream-url=REAL_URL  WATCH_AS

The script has no effect unless the script-opts value real-stream-url is set to something.

EDIT - from a quick glance, it's possible that the priority 50 at the script above is lower than ytdl_hook.lua (which uses priority 10, and I think lower is higher priority), at which case the number 50 might need to be changed to something lower than 10, so that it runs before ytdl_hook.lua, and then ytdl_hook.lua can use ytdl to transform the URL forther without changing its WATCH_AS value.

[qmega]

Since this conversation got quite sidetracked, I just want to highlight, for anyone that does want to consider this, that the requested feature applies to the built-in ytdl_hook with user-specified URLs (and the hack solution is not applicable there), not only the more specific use case initially put forward. Copying my own comment:

A trivial example for youtube -- where the user calls mpv directly, with no external wrapper -- is opening a video with a t= parameter (or a playlist= parameter), saving state, then opening the same video from a fresh url without said parameter. You'd probably want mpv to resume where you left off from the first link, but it won't, because the URL string is different. The URLs could be normalized by ytdl_hook to include only the video ID, and not time / playlist / whatever else, and that would fix that use case. It can't be addressed by passing in a fake original path because there's no wrapper for mpv in this case, and because some of the parameters that we'd want to strip for the sake of watch-later are actually used by ytdl_hook for other things. This is admittedly not something I can remember needing myself, but it does seem plausible.

I think the generalized basic idea of this request is that the path or url as input is not always an ideal key for watch-later info, and either an mpv script (including ytdl_hook) or external caller of mpv may be in a position to provide a better one. Currently this is only possible for the latter, and only as a hack. Being able to set the watch later key directly as a file-local option handles every case I can think of and doesn't seem too intrusive to me.

[TAAPArthur]

I don't have endless time to discuss this. I'm not convinced. That's as far as it goes for me. If any other mpv developer feels like continuing this discussion and/or whatever, they're free to do so.

Then wouldn't leaving the issue/PR open so other devs could see be fair. Especially since other users deemed it reasonable. The majority of the discussion was done after the PR was closed because the problem statement wasn't understood. I can't imagine other devs just browse closed issues/PR. I still feel your judgment was rash since since the entirety of watch-later options could be done from scripts if one wanted.

[avih]

Then wouldn't leaving the issue/PR open so other devs could see be fair

It's fair to say that by now every dev is aware of this issue and the PR, possibly to a stage where they filter out any email with the title of this issue. Worry not, they know.

[LittleBenjiBoy]

I just wanted to vouch for @TAAPArthur's proposal. I am a user that would also like a solution to this problem. The situation that he described in his initial post and in https://github.com/mpv-player/mpv/issues/9346#issuecomment-952463091 is something that I always encounter. Having mpv use the video's title to resume the video instead of the path or filename resolves my issue. I have went through the trouble of building from source to test his commit/change at options: Add watch-later-use-title and it had exactly what I needed. Please implement this change to the original mpv so that I can get it in the Windows version of mpv rather than a built from source version of mpv that depends on the .dll files in C:\msys64\mingw64\bin, which cannot be made portable.

I have spoken more about this in https://github.com/mpv-player/mpv/pull/11020#issuecomment-1575954881.