Loading next/previous item gets progressively slower with longer playlists

[jfolz]

mpv Information

mpv 0.39.0 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
libplacebo version: v7.349.0
FFmpeg version: 7.0.2
FFmpeg library versions:
   libavcodec      61.3.100
   libavdevice     61.1.100
   libavfilter     10.1.100
   libavformat     61.1.100
   libavutil       59.8.100
   libswresample   5.1.100
   libswscale      8.1.100

Other Information

- Linux version: Fedora Linux 41 (Workstation Edition)
- Kernel Version: Linux fedora 6.11.5-300.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Oct 22 20:11:15 UTC 2024 x86_64 GNU/Linux
- GPU Model: 33:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] [1002:1681] (rev d1)
- Mesa/GPU Driver Version: OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.2.5
- Window Manager and Version: GNOME 47
- Source mpv: Fedora repository, Flathub
- Introduced in version: 0.39.0

Reproduction Steps

After updating to mpv 0.39.0 (Fedora 41), I noticed that loading the next/previous item takes progressively more time as playlists get longer. This was not the case with 0.37.0 (Fedora 40).
To replicate, simply create a long playlist and pipe into mpv like so:

yes $'image1.jpg\nimage2.jpg' | head -200000 | mpv --playlist=- --no-config --profile=fast

With reasonable-sized images and a short playlist, loading is effectively instant. The same images take several seconds to load with 200k items in the playlist.

I'm using images to test, since I find it easier to judge loading times, but the issue is present with videos as well.
The issue is also present in the Flathub version of mpv.

Expected Behavior

Loading the next/previous playlist item is always fast, irrespective of playlist length.

Actual Behavior

Loading the next/previous playlist item seems to correlate with playlist length.

Log File

output.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.

[llyyr]

Bisected to de08494 (yes, it's not a mistake).

I'll need some time to figure out the "why" though

More specifically, mp.observe_property("playlist", "native", request_init) is what causes it. Reverting it back to nil type fixes the issue.

[llyyr]

The PR fixes the issue, you can either wait for the fix to make its way into a release or disable the built in osc with osc=no in your config and put the new osc.lua in your scripts folder and loading it that way.

[jfolz]

Can confirm, osc=no restores the usual speediness. Thanks so much!