mpv opens next file-handle prematurely

[globalshrug]

mpv Information

mpv v0.40.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
libplacebo version: v7.351.0
FFmpeg version: 7.1.1
FFmpeg library versions:
   libavcodec      61.19.101
   libavdevice     61.3.100
   libavfilter     10.4.100
   libavformat     61.7.100
   libavutil       59.39.100
   libswresample   5.3.100
   libswscale      8.3.100

Other Information

- macOS version: macOS 15.5 (24F74)
- Source of mpv: Homebrew
- Latest known working version: latest homebrew version prior to v0.40.0
- Issue started after the following happened: updated mpv through homebrew.

Reproduction Steps

• Get some test video files together
• Run find dir -type f -print0 | xargs -0 mpv --no-config -- or mpv dir/* or whatever - the point is to cue them all up in mpv.
• Run lsof -p $(pgrep mpv) | grep $pwd and see (probably) only the one video file that's currently playing. Set loop-mode to inf and skip to 90%+ of the file - somewhere near the very end.
• Allow it to loop and start playing the same file again.
• Re-run the lsof command - you'll find (sometimes) that mpv has opened the next video file in anticipation.

Now, this doesn't sound like an issue per-se, except that I have scripts that use lsof output to figure out which file mpv has open and allow me to tag that file.

Those scripts depend on either:
only one video being held open by mpv; or
the smaller file descriptor corresponding with the first file opened.

I've come to learn that my second assumption is not necessarily true, unfortunately - after hitting fd 10 I watched mpv open the next file in the playlist (that it hadn't started playing yet) and that file got fd 9.
Fair enough, the fd is probably arbitrarily given to the process by the OS and that's not going to change.

But, my question is, is there either a better way to get the current video being watched from the mpv process, OR can we consider this a regression? I've only started seeing this behaviour since the recent update.

Note: attached log file is heavily edited - was about 11Mb until I removed hundreds of aac errors. I do not believe that is related to this issue as it is reproducible across a wide variety of files.
Here is one sample of the (only) repeated line that I excised:
[ 18.284][d][ffmpeg/audio] aac: ChannelElement 2.3 missing

Expected Behavior

lsof reflects only the currently-playing media.

Actual Behavior

lsof sometimes reflects that mpv is reading the next file in the playlist, but only when the end of the current file has been reached and file-loop is on.

Log File

1749612051.txt

Sample Files

No response

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

• I tested with the latest mpv version to validate that the issue is not already fixed.
• 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.

[layercak3]

--prefetch-playlist defaults to yes in 0.40.0, you can turn it off.

I would get the path property from JSON IPC to get the currently played file from an external process. For more complicated things like archives/optical discs path will have a protocol prefix and you might need to do a bit of parsing to extract individual components out of it.

[guidocella]

You can just use a Lua script to get the current file.

[globalshrug]

--prefetch-playlist defaults to yes in 0.40.0, you can turn it off.

I would get the path property from JSON IPC to get the currently played file from an external process. For more complicated things like archives/optical discs path will have a protocol prefix and you might need to do a bit of parsing to extract individual components out of it.

Ah, not a bug then. Didn't know about that option, thank you.