[guidocella]

Paths like foo.mkv, ./foo.mkv .//foo.mkv, ../"$(basename "$PWD")"/foo.mkv, and C:\foo.mkv and C:/foo.mkv on Windows, use different config files for resuming playback, so if you quit-watch-later and later play the same file with a different path mpv does not resume playback. This commit normalizes the paths to fix this.

References #495

Someone needs to fix the code for Windows, and also test if the performance impact of calling GetFullPathNameW on thousands of playlist entries is acceptable. On Linux realpath is actually much slower than this normalizing function. The loop in mp_check_playlist_resume with 2330 images takes 0.012 seconds before this patch, 0.014 with it, and if I make it use realpath with /dir/../dir/* it takes 0.038 seconds.

[natural-harmonia-gropius]

Will result of mp.get_property("path") be affected by this?

[guidocella]

Will result of mp.get_property("path") be affected by this?

No, it affects the paths that determine the hashes of watch later config files.

[natural-harmonia-gropius]

No, it affects the paths that determine the hashes of watch later config files.

Could you add a normalize-path command just like expand-path?

[guidocella]

Could you add a normalize-path command just like expand-path?

That's fine if maintainers think it's worth adding, but it should be in a later PR.

[guidocella]

I made this Unix only since there is no interest in fixing it on Windows.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32

macOS

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

[N-R-K]

Untested, but seems fine code wise.

[stacyharper]

I also relate the same problem because I mount some video files in different locations, depending on the machine I am using. Because my user name differ, even if I mount my files in ~/foo, it ends up in /home/stacy/foo, or /home/willow/foo depending on the installation.

What about ignoring the path while building the hash? We could just use metadata, and/or file name?

[guidocella]

--ignore-path-in-watch-later-config

[stacyharper]

I was aware of this argument. But both with or without have pros and cons. I would prefer relying on a md5 of the complete file, rather than it's file name and/or path.

[guidocella]

mpv compares the watch later path of every playlist entry to determine what file to resume from, and it would be too slow to calculate the hash of the content of thousands of playlist entries, which can even be network URLs.

[stacyharper]

Fair points. Sorry for debating on this MR o/

[garoto]

What would be the computational considerations regarding MD5 hashing the first 4096 [1] bytes of every file the player loads? Tested with around ~900 matroskas I have laying around and found no hash collisions, and performace was acceptable disregarding OS|HW caching mechanics.

Super fast on Winblows using busybox-w32 built-in utils (head|md5sum), and I can only speculate that C code doing the same would be even less demanding. Just hide it behind an option or something.

Totally OT for this PR I know.

[1]: random bytes pulled from my a**.

[guidocella]

There are also redirect entries for directory paths which don't have any content to hash. But I guess it would be fine as an alternative option, maybe limited to current file. It would also fix mpv-android/mpv-android#542.

[kasper93]

Please add a test for mp_normalize_path in test/paths.c. Things like that can easily break, especially on different platforms.