New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

autoload.lua Loads files incorrectly and behaves erratically #5618

Closed
Samillion opened this Issue Mar 10, 2018 · 22 comments

Comments

Projects
None yet
3 participants
@Samillion

Samillion commented Mar 10, 2018

mpv version and platform

mpv 0.28.0 on Windows 10 x64

Reproduction steps

Have autoload.lua active and place video files in a folder with different names and extensions, for example:

Video of - 2 Trees & a swing.avi
Beach day on - Friday 2014.mp4
534235.avi
421353.flv
462114.mp4
Video - File.wmv Day around CITY.LAM.mp4
Finding the #lost tire ~around _city.LAM.flv
G_31_In the box_-_in_the_house.avi
TT_1343566771321.MP4
TT_56524664fAFG4.MP4
Test_file#4313; Phase one_b.MP4
Cave_in_(2012) --Street 43.flv
...etc

Expected behavior

Video files would play one after the other, in order.

Actual behavior

Random order of playing, and the same files are appended over and over to the playlist if you keep triggering "play next" a few times. So let's say the folder contains 300 video files, with "play next" a few times, it plays in random order or completely restarts order, then the playlist will indicate that it now contains 600 entries, then 900 and so on.

I keep track of playlist by displaying ${playlist-pos-1}/${playlist-count} in the OSD.

Log file

https://paste.ubuntu.com/p/SKJfRNCd4G/

autoload.lua

Currently using the latest stable release of autoload.lua, unmodified.

Further explanation:

The reason I listed examples of the filenames is because I'm not really sure what's causing the problem, different extensions, specific characters used in filenames, the number of files or a mixture of all.

I've tried to represent some of the weird filenames exactly because there are definitely weirdly named files in there, though the total files is 305 in one of my folders, but it occurs in other folders as well with more files.

@wiiaboo

This comment has been minimized.

Member

wiiaboo commented Mar 10, 2018

Maybe a log file with the script actually doing some work, preferably?

@Samillion

This comment has been minimized.

Samillion commented Mar 10, 2018

Ah, my bad.

Here is an update. I have a folder with 64 video files, the name syntax is normal. Example: Fullmetal Alchemist BrotherHood 01.mkv goes up to 64.

Same behavior as I mentioned earlier, all with the same file extension and normal file names.

Log file:

https://0x0.st/sm0E.txt

Preview of behavior: (Screen Capture - MP4 - 1.7 MB)

https://0x0.st/sm0U.mp4

As you can see from the preview, when I playnext on 03 it starts 03 again and the playlist becomes bigger, if I keep triggering play next a few times, same thing happens again.

@Samillion

This comment has been minimized.

Samillion commented Mar 10, 2018

Just wanted to add a note, this behavior isn't constant in all folders. By that I mean, in other folders/files it behaves normally.

Not sure if that would be of any help identifying the issue.

Edit:

Also tested on Debian Stretch, mpv 0.27.2 (deb-multimedia). Same behavior. Can upload screen capture for this as well if needed.

@wiiaboo

This comment has been minimized.

Member

wiiaboo commented Mar 10, 2018

Is drive Y: maybe a network mount?

@Samillion

This comment has been minimized.

Samillion commented Mar 10, 2018

It is, yes. Since you implied it could be a network mount issue, I copied that folder to my E: drive (HDD), and the problem didn't occur. Everything works well.

I guess this happens over network mounts. (tested on Windows 10 and Debian Stretch)

Any suggested solution? Or do you need me to provide more information?

@wiiaboo

This comment has been minimized.

Member

wiiaboo commented Mar 10, 2018

Run this version of autoload with log-file as well. I can't reproduce it here.

@Samillion

This comment has been minimized.

Samillion commented Mar 10, 2018

Done. Problem still occurs.

Log file: https://0x0.st/smGg.txt

@Samillion

This comment has been minimized.

Samillion commented Mar 10, 2018

Also, just in case, this is my mpv.conf.

@wiiaboo

This comment has been minimized.

Member

wiiaboo commented Mar 10, 2018

Could you run this version? Should be the last one needed.

@Samillion

This comment has been minimized.

Samillion commented Mar 10, 2018

Done.

Log: https://0x0.st/smG0.txt

Problem still occurs.

I'm up for testing as many files as you'd need. If this is a problem not just isolated to me, I'll gladly help.

@wiiaboo

This comment has been minimized.

Member

wiiaboo commented Mar 10, 2018

I guess it's because the sort order comes all random from readdir(). @rossy @wm4 any idea if this is a bug in readdir or autoload.lua just needs to sort the files table too?

@wiiaboo

This comment has been minimized.

Member

wiiaboo commented Mar 10, 2018

Wait, nevermind, files are already sorted, but for some reason when you change to episode 04 it thinks it's still in position 3.

Run this version again, please.

@Samillion

This comment has been minimized.

Samillion commented Mar 10, 2018

Still occurs.

Log: https://0x0.st/smDi.txt

The behavior is really odd. When I start the first file, the playlist only consists of that file (1/1). When I trigger play next the playlist then gets generated correctly in the correct position (2/64).

When I reach the third file (fourth on Linux) the playlist gets bigger, from 64 to 128, 187 and so on.

@wiiaboo

This comment has been minimized.

Member

wiiaboo commented Mar 10, 2018

I wonder if it's because you move to the next playlist item before the script finishes. It takes a whole second to run readdir() probably because it's a network mount. Could you try waiting like 3 seconds before changing to the next file and see if it still triggers the issue?

@Samillion

This comment has been minimized.

Samillion commented Mar 10, 2018

Aha. You are absolutely right. I tested with the latest autoload.lua you posted and the unmodified stable one, works on both.

Waiting 3-4 seconds between each file before triggering "play next" makes autoload.lua behave normally.

I have no idea if this matters, but I'm on a Gigabit network, read/write speeds from that NAS averages around 600Mbps (60MB). Does that mean I need to find a way to optimize my mounts specifically for mpv/autoload.lua?

@wiiaboo

This comment has been minimized.

Member

wiiaboo commented Mar 10, 2018

I'll try to move some things around in order to not be affected by readdir speed.

Could you check if it still happens with this version and fast cycling?
And if it still happens, then try with this one.

@Samillion

This comment has been minimized.

Samillion commented Mar 10, 2018

Both work perfectly, problem is fixed completely. Which one do you think I should stick with?

Also, do you need the log files for those as well?

Side note, have to say, thanks so much for the response time and the effort. I'm beyond impressed,

@wiiaboo wiiaboo closed this in 7d0285b Mar 10, 2018

@wiiaboo

This comment has been minimized.

Member

wiiaboo commented Mar 10, 2018

No need for logfiles, thanks for testing. I went with the first one. Less changes and less global variable usage.

deu added a commit to deu/mpv that referenced this issue Mar 20, 2018

TOOLS/autoload: be more robust with slow directory listings
Overall, just shuffled code around and added a few debugging messages
for future issues.

The issue could be reproduced easily by quickly navigating through the
playlist inside a network mount.

Closes mpv-player#5618
@thisisshihan

This comment has been minimized.

thisisshihan commented Nov 11, 2018

Still happens when fast cycling in Linux,
screenshot from 2018-11-11 22-00-29

@wiiaboo

This comment has been minimized.

Member

wiiaboo commented Nov 11, 2018

The screenshot doesn't specify what version you're using.

@thisisshihan

This comment has been minimized.

thisisshihan commented Nov 12, 2018

The screenshot doesn't specify what version you're using.

I'm using version 0.29.0-88-317d3ac266 in Windows, in windows also i'm having same issue.

Thanks,

@thisisshihan

This comment has been minimized.

thisisshihan commented Nov 12, 2018

Linux version - git-2018-07-22-45beb70

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment