frame-back-step stops working after a few frames (when opening smb:// url)

[pjotrek-b]

Important Information

Provide following Information:

• mpv version: v0.37.0-484-g665a472098 (built Debian-package with libsmbclient support manually enabled)
• Linux Distribution and Version: Xubuntu 20.04.6 (64bit)
• Source of the mpv binary: mpv-build (github)
• If known which version of mpv introduced the problem: already in v0.32.0-1ubuntu1
• Window Manager and version: X11

Reproduction steps

Open a videofile from a Samba (CIFS) share, using the "smb://" URL prefix: $ mpv --no-config smb://guest@hostname/share/folder

1. Seek to a position far enough, so you could frame-seek backwards for at least a minute or so.

2. Now use "," to seek backwards 1 frame: Hold "," until the video stops rewinding

3. Now neither "," nor "." has any effect anymore. The player seems "stuck".

4. However, pressing left/right arrow keys, or seeking manually (clicking) to any other position works.

5. After this "re-seeking", frame-seeking (,.) works again.

Until seeking back again (=repeat step 2).

Expected behavior

The same as opening the same video file directly from the local filesystem: Use frame-seeking back-and-forth without the player getting stuck.

Actual behavior

The player gets stuck, so that frame-seeking seems disabled/broken - until re-setting the player's playback position in any other way (keyboard or GUI).

Sample files

I've generated one (i-frames only to avoid GOP causing the issue), using ffmpeg: ffmpeg -f lavfi -i testsrc=size=1920x1080 -t 300 -r 25 -pix_fmt yuv422p10le -c:v ffv1 -level 3 -an test.mkv

[pjotrek-b]

I think I found the reason: The cache settings matter. :partying_face: (but they don't fix it)

Because my original issue was with an SD VHS recording as FFV1/PCM/MKV (720x576@25i, gopsize=1), but the synthetic ffmpeg-testsrc sample worked flawlessly - and displayed more seconds in cache (!).

It seems that the player runs out of cache (drops to 0/0, shown in the terminal) and shows the following line - but without any action - in the logs (for each keypress):

[cplayer] Run command: frame-back-step, flags=73, args=[]

So I tried setting my cache values higher in /etc/mpv/mpv.conf, copy-pasting the suggestion from man mpv:

[big-cache]
cache=yes
demuxer-max-bytes=512MiB
demuxer-readahead-secs=20

Higher demuxer cache values don't completely fix the freeze, but it seems that when waiting for the cache to have pre-loaded, frame-back-step works "longer".

But: With all cache options, sooner or later it gets stuck on frame-back-step. :disappointed:

[pjotrek-b]

Sorry: forgot the logfile! smb_frameseek_stuck.log

[pjotrek-b]

We've found the pattern! :smile: My colleague saw that the line displaying the cache in relationship to the playback position was an indicator:

If there is no cache before the playback position: freeze problem. If there is cache before the playback position: works!

I've consulted man mpv and for the time being setting "demuxer-seekable-cache=no" seems to work for us.

Is there any option to "force" starting to cache data before the playback position?

As far as I understood the docs, "demuxer-max-back-bytes" only keeps existing cache before the playback position - but cannot be used to pre-read it when jumping directly to a certain offset.

[pjotrek-b]

No cache before playback position: frame-back-step will get stuck:

Some cache left before the playback position: Works fine!

[KaFu74]

Maybe this setting will help? --demuxer-max-back-bytes= https://mpv.io/manual/stable/#options-demuxer-max-back-bytes

[pjotrek-b]

@KaFu74 : Was hoping the same, but unfortunately not.

Quote from man mpv:

"This controls how much past data the demuxer is allowed to preserve."

Since demuxer-max-back-bytes only allows to keep bytes cached - but does not initialize loading the cache "starting before the current playback position".

[MarjaE2]

The same bug occurs with local files, though.