--autocreate-playlist plays wrong file when filename differs in unicode or case #18765

mpv Information

mpv v0.42.0 Copyright © 2000-2026 mpv/MPlayer/mplayer2 projects
 built on Nov  5 2026 00:13:11
libplacebo version: v7.387.0 (v7.387.0-11-g0e435227-dirty)
FFmpeg version: N-128420-gbaa68e68b3
FFmpeg library versions:
   libavcodec      63.26.100
   libavdevice     63.6.100
   libavfilter     12.12.100
   libavformat     63.18.100
   libavutil       61.20.100
   libswresample   7.7.100
   libswscale      10.6.100

Other Information

- macOS version:macOS 15.8.2 (24H232)
- Source of mpv:github
- Latest known working version:unknown
- The time when the problem started to happen:noticed on 0.42.0

Reproduction Steps

I was investigating why double clicking a file in macos' finder with katakana in its basename, together with --autocreate-playlist, was opening the wrong file.

I figured out it had to do with ザ being in the filename in composed unicode form.
for example:

# が in two forms: composed U+304C, decomposed U+304B U+3099.
composed=$(printf '\343\201\214')
decomposed=$(printf '\343\201\213\343\202\231')

# create two identical videos
mpv --no-config --ao=null av://lavfi:testsrc=d=0.2 --o=a.mkv
cp a.mkv "$composed.mkv"

# both are the same file (inode is identical)
stat -f %i "$composed.mkv" "$decomposed.mkv"

mpv --no-config --vo=null --ao=null --autocreate-playlist=filter "$composed.mkv"
# Playing: .../が.mkv

mpv --no-config --vo=null --ao=null --autocreate-playlist=filter "$decomposed.mkv"
# Playing: .../a.mkv
# Playing: .../が.mkv

then I realised this is not specific to unicode. casefolding file systems outsided of macos are probably affected too.

# on a case-insensitive fs, with a.mkv and b.mkv in the directory
mpv --no-config --autocreate-playlist=filter B.mkv
# Playing: .../a.mkv
# Playing: .../b.mkv

the attached log is from the "$decomposed" command.

the underlying issue seems to be a deeper one: mpv treats a path string as the file identity, which is arguably incorrect.

some examples of what this leads to in 0.42:

• the wrong file plays with --autocreate-playlist
• one file gets two saved positions, e.g. via b.mkv and B.mkv
• mpv --sub-file=b.srt b.mkv shows b.srt as two subtitle tracks

and possibly others. all of this was tested only on macos with APFS.

related, as far as I can tell:

• Normalize filename before storing #1027 (2014): closed as a macos problem
• match decomposed/precomposed unicode strings with sub-auto=fuzzy #4016, cocoa: consistent normalisation when searching for external files #4067 (2017): fixed only for file search
• Better absolute path calculation in mp_get_playback_resume_config_filename #495, player: normalize paths for resuming playback #12303 (2014, 2024): saved positions, partially fixed

Expected Behavior

the opened file plays

Actual Behavior

the first file in the directory plays instead (or the first one with a saved position)

Log File

output.txt

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested and confirmed that the issue exists with the latest release version or newer.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.