options: make --write-filename-in-watch-later-config write title as well

[yatinlala]

The History menu (CTRL-P -> History) displays the titles of previously played files, but the Watch later menu displays a list of filenames.

This PR adds --write-title-in-watch-later-config. With the option set, save-position-on-quit inserts the playing file's title in a comment below the filename in the file's watch_later entry. The Watch later picker then displays these titles instead of filenames when they are available.

Examples

• mpv --write-filename-in-watch-later-config:

# https://example.com/?v=foobar
start=35
gamma=1

• mpv --write-filename-in-watch-later-config --write-title-in-watch-later-config:

# https://example.com/?v=foobar
# FooBar (HD Video)
start=35
gamma=1

• mpv --write-title-in-watch-later-config:

start=35
gamma=1

Notes:

• --write-title-in-watch-later-config silently no-ops if --write-filename-in-watch-later config is not set. The Watch later menu is disabled without --write-filename-in-watch-later-config anyway, so this seems like a reasonable behaviour to me. If it is preferred that --write-title... automatically enables --write-filename... or emits an error, let me know.

• These changes are backwards compatible with older versions of MPV, since, forcing --write-filename... to be set ensures that a title comment will never be inserted without a filename comment above it. Title comments will never be misinterpreted as paths to a file by older versions.

• Titles are displayed instead of filenames in the Watch later menu if --write-title-in-watch-later-config is set, otherwise existing behaviour is preserved. Perhaps this should be separated out into its own option, applying to both the History and Watch later menus?

• I acknowledge this is a hacky solution. If breaking backwards compatibility is an option, it might be nice to replace the watch_later system with a structured data format in line with watch_history.jsonl.

[guidocella]

Thanks for the patch, I also thought this would be useful for web URLs and this was requested on IRC.

Some thoughts:

• Do we need a new option instead of just always saving the title with --write-filename-in-watch-later-config, like saving history always saves the title? Is there a reason to save the filename but not the title?
• Can we call format_history_entry() so the format is consistent with history? Which also allows customizing the date format

• I acknowledge this is a hacky solution. If breaking backwards compatibility is an option, it might be nice to replace the watch_later system with a structured data format in line with watch_history.jsonl.

I chose jsonl for history because it is only appended too, it is slow if you rewrite the whole file. That is why the single-file shader cache was replaced with multiple files. In fact doing the opposite was requested in
#16429 (comment)

[guidocella]

Also maybe we should prefix title= so we can add other data in the future. I know @Earnestly saves the playlist title with a custom script for selecting youtube playlists, maybe he has suggestions?

[Earnestly]

Unhelpfully I don't have an opinion on how this all might integrate with mpv's new menuing system, which is the crux of this PR. I've not really had much chance to make use of it yet, although I do intend to eventually as the playlist menu has been extremely handy.

As for my own history on this topic, here is what I can share: my old PR #13476 did something similar but preserved the redirect path instead of adding a title.

I abandoned this approach because it would end up overburdening mpv's watch_later files as I expanded the data I would want to include.

Instead I wrote my own "watch later" command as lua script. Here I can include all the data I want. It is bound as Shift+q script-message super-quit-watch-later as the script calls quit-watch-later; it acts as a superset of its functionality (hence the name). This means I still use watch_later for its purpose which is resuming playback.

(It does use JSONL as its database format, but it's managed with an external menuing script instead: superwatchlater).

As an aside, title is a little ambiguous because it can refer to multiple things; this PR uses (afaict) media-title but in my case I need both the playlist title and video title (which is what #15098 was for), this requirement was the push for me dropping captured metadata inside watch_later files; the parsing (and dependency resolution between files) became more involved than it needed to be.

[guidocella]

Ok I guess the title= prefix is not needed since the playlist title would be stored separately in the redirect entry. I think this PR can just store the video title, and a future PR can resurrect #13476 and also store the playlist title after the playlist path. Then redirect entries with a title can be added to the menu.

Also unlike with json this all breaks with paths and titles containing newlines, but they are not common anyway.

[Earnestly]

Also unlike with json this all breaks with paths and titles containing newlines, but they are not common anyway.

Newlines aren't the problem with json, however json does require valid UTF-8 which is not required by unix filenames.

[yatinlala]

Thank you for all the feedback!

• Do we need a new option instead of just always saving the title with --write-filename-in-watch-later-config, like saving history always saves the title? Is there a reason to save the filename but not the title?

You're right! Storing filename without title certainly seems pointless. I could imagine someone wanting to be able to choose between displaying titles and filenames in the menu, but it is a separate thing. I've rolled the change into --write-filename-... if that is alright with you.

• Can we call format_history_entry() so the format is consistent with history? Which also allows customizing the date format

Done.

• Ok I guess the title= prefix is not needed since the playlist title would be stored separately in the redirect entry.

I haven't added a prefix as per your discussion. It seems to me that a prefix would make it a bit nicer to add more metadata down the line, but I'm uneducated about how playlists work and what additional metadata you might want to store. Let me know if you have a contrary preference.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-aarch64-pc-windows-msvc
• mpv-i686-w64-mingw32
• mpv-x86_64-pc-windows-msvc
• mpv-x86_64-w64-mingw32

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[guidocella]

I know this is copied from the function above but is - 1 necessary?

[yatinlala]

I think we need write_title[1023] to be reserved for the null byte, so sizeof(write_title) - 1 populates the array up to write_title[1022].

[guidocella]

I haven't added a prefix as per your discussion. It seems to me that a prefix would make it a bit nicer to add more metadata down the line, but I'm uneducated about how playlists work and what additional metadata you might want to store. Let me know if you have a contrary preference.

Dunno I can't think of other metadata we may need. If you or someone else thinks a prefix is better go ahead and add it.

[yatinlala]

One last change — apologies @guidocella — 6a0454c makes select.lua check all lines after url line for # title:. This way we can have unordered metadata in the future that relies on the prefix to identify what it is, instead of hardcoding line numbers.

[guidocella]

Ok I don't think that needs to be done preemptively but whatever you prefer. Do you have other metadata to store in mind?

[yatinlala]

Nothing specific in mind. Thumbnail paths or arbitrary user metadata via the Lua API could be cool, but is perhaps unneeded. I'm not familiar enough with the project to know what is possible already and what makes sense to add. 🙂

I do think that it beats the point of a prefix to assume specific pieces of metadata are coming on specific lines (beyond perhaps better readability). If hardcoding the line number is the way to go, perhaps I should get rid of the prefix all together.

In my opinion, this way gives more forward flexibility for little cost though.