mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
27.81k stars 2.87k forks source link

Watch-later using m3u #14642

Open avidseeker opened 1 month ago

avidseeker commented 1 month ago

Expected behavior of the wanted feature

Currently, mpv saves playing position and speed values within a file named after the md5sum of the file it was playing.

Suggestion: use m3u for that. It makes it more compatible with other media players, and offers a way for standardizing tracking audiobooks.

$ cat "$XDG_STATE_HOME"/mpv/watch_later/2AB1F29BA4B6CD60CB58FF71191813DA
start=30.207838
speed=1.440000
volume=104.000000

Use instead:

#EXTM3U
#EXTINF:30.207838, Audiobook Chapter1 - History of Lorem Ipsum
#EXT-X-HASH:MD5:2AB1F29BA4B6CD60CB58FF71191813DA
#EXT-X-SPEED:1.440000
#EXT-X-VOLUME:104.000000
path/to/file.mp4

#EXTINF:51.307838, Audiobook Chapter2 - Next chapter
...

Files with only two lines have too much fragmentation. Just check:

$ ls -1 "$XDG_STATE_HOME"/mpv/watch_later | wc -l

A playlist is a more neat and portable option (think about syncing audiobooks status between desktop and mobile by only syncing a single m3u file).

Alternative behavior of the wanted feature

No response

Log File

No response

Sample Files

No response

llyyr commented 1 month ago

mpv saves information in watch later files that can't be ported to m3u, so this idea doesn't work.

You can write a Lua script to generate m3us when mpv is quitting though

avidseeker commented 1 month ago

can't be ported

But I just gave an example on how to port it: speed=1.440000 --> #EXT-X-SPEED:1.440000.

llyyr commented 1 month ago

But I just gave an example on how to port it: speed=1.440000 --> #EXT-X-SPEED:1.440000.

That is not a real tag that's going to be understood by any other player, there's no reason why mpv should save in this format when plain text is good enough, except your niche use case.

This kind of functionality is something that should live as a script instead. iirc something like this already exists but it saves to a sqlite file instead, you'd just need to modify it to save as an m3u8.

guidocella commented 1 month ago
po5 commented 1 month ago

If you're looking for a way to browse through your history, a script like memo would be a better solution.
You can use it in conjunction with watch-later.

avidseeker commented 1 month ago

I'm more interested in a portable watch-later within an audiobook directory. This makes it easy to synchronizing pause timestamps with other devices. See: https://github.com/mpv-android/mpv-android/issues/960.

except your niche use case.

It's not a niche use case. #EXTINF:30,Artist Name – Track Title is a long established format that's used by streaming clients for resuming from last position.

If writing to a m3u file could pose some problems (privacy, performance, etc), then as a start mpv should read the essential (standard) m3u directives, including EXTINF.

I'm just pointing out that there already exist a standard for watch-later playlists, and there's no need to re-invent the wheel. The simple method mpv uses for that is fine, but as a portable and compatible playlist setup, m3u should be used.

kasper93 commented 1 month ago

Your usecase is quite specific and I will be frank, no one will refactor whole watch-later system just for this limited use. Patches are welcome.

Dudemanguy commented 1 month ago

Watch later files are not an m3u playlist nor does it really make any sense to try to awkwardly map them to one. So on that specific proposal, I would say that is a hard no. If you want a feature for mpv to natively write m3u files, that is a somewhat separate request that likely probably wouldn't be implemented but it's at least a valid ask.

kasper93 commented 1 month ago

I think it would be trivial to write lua script that dumps current playlist for m3u. Not something that is interesting to upstream though.