Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Playlist shuffle behaviour needs changing (but to what?) #153
If shuffling the playlist moves the currently playing item then it will switch to the new file but then seek to the old position rather than rewinding to 0.
I am not sure if it is better to rewind the new file or stick with the old file, but either way the current behaviour is incorrect.
changed the title from
Incorrect shuffle behaviour
Incorrect shuffle behaviour (+discussion on what correct behaviour should be)
Oct 19, 2017
This is what I suggest
Have two different buttons for shuffling
added a commit
Nov 5, 2017
That's an interesting idea @QuestofIranon but I don't think it would be particularly feasible given how Syncplay works.
Different people might expect different behaviours of how the next file would be 'randomly' selected, with some expecting a file to be randomly chosen per file advance (with the possibility of replaying the same episode possible, even the episode you had just watched) while others would want measures to ensure the same file was not played twice. But how precisely would Syncplay know a file had already been played? It'd need a whole new tracking system, and if that went wrong people would have no idea because the playlist would be hidden. It seems like it adds way too much complexity to Syncplay.
We try to maintain a high level of backwards and forwards compatibility with Syncplay, so even if those issues could be overcome for new versions the fact that it would cause problems if some were on older versions is a major barrier. Simply changing how the playlist is shuffled doesn't affect compatibility because it changes the playlist for all users and doesn't need any changes to the protocol, but changing how to select the next file could be more problematic if some people are still on older clients.
Given that the shuffling issue which I raised seems to have been resolved, I'm closing this issue. If anyone has detailed proposals in the future for changing the behaviour then they are free to start a new issue which refers back to this one, but keep in mind the general desire for simplicity, predictability, and interversion compatibility.
Oh, I forgot to address one suggestion: @xNinjaKittyx I don't have any buttons for any of the playlist features. I could add them in the future, but that always has the disadvantage of adding clutter to the main GUI screen which can be intimidating for new users. If I added it, it'd therefore likely be as an optional extra which you could enable through the 'Window' menu in the same way as the optional playback control buttons. I don't have any major aversion to unobtrusive playlist control buttons being added, but given that they will need programming and testing I'll not make it a top priority - but if someone else wanted to add them before I get to it then they are free to do so and make a pull request (so long as they make them 'optional').