The `shuffle` option built into mpv doesn't shuffle playlist playback, but instead just randomizes the order of every new opened playlist. So when you enable this after opening a playlist, it does nothing. If you enable it before opening a playlist, it'll randomize its list order, so you can't browse alphabetically. None wants this, none expects this. And since its is expected from a ui such as uosc to provide a shuffle button that works like in any other media player on the planet, I had to simulate it.
It decides on the next file 300ms before the end, so it can potentially cut out punchlines from short videos such as those from r/perfectlycutscreams. But this is necessary because a lot of files actually end like ~100ms or more before their duration, but on corrupted files or files where stream ended prematurely, this can happen way before that. If file is force ended by mpv before our timer kicks in, our simulated `file-end` event won't fire, and uosc is unable to take over to decide to play the next one.
I couldn't figure out a better way to implement this. There's no 'fil-reached-end' even in mpv. There are only 'im-unloading-the-file' events (`file-end`, `on_unload`, ... etc), which is useless here because it triggers even when user opens a different file during playback.
Implementing `shuffle` allowed for trivial `next_file_on_end`, so that got added as well. It load next file in directory when current file ends.
Directory navigation now also adheres to `shuffle` uosc option, and `playlist-loop`, `playlist-repeat`, & `loop-file` mpv options.
Additionally, the `<has_playlist>` disposition was removed from the `shuffle` and `loop-playlist` control bar buttons as they now affect directory navigation as well.
closes#235
d2dd7e4415