Playlist shuffle behaviour needs changing (but to what?)

[Et0h]

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.

[xNinjaKittyx]

This is what I suggest

Have two different buttons for shuffling

1. Have a button that shuffles everything after the current selected file. This should be the default behavior. It should not interrupt the current playing file whatsoever (should be same index anyways)
2. Have another button that shuffles the entire playlist and rewind to 0. Make the selected file the first file. This is kind of a "shuffle-all" behavior.

[xNinjaKittyx]

This is what I suggest

Have two different buttons for shuffling

1. Have a button that shuffles everything after the current selected file. This should be the default behavior. It should not interrupt the current playing file whatsoever (should be same index anyways)
2. Have another button that shuffles the entire playlist and rewind to 0. Make the selected file the first file. This is kind of a "shuffle-all" behavior.

[Et0h]

That sounds like a good way of doing it @xNinjaKittyx 👍

[Et0h]

That sounds like a good way of doing it @xNinjaKittyx 👍

[Et0h]

@xNinjaKittyx - Is the implementation of your suggestion correct?

[Et0h]

@xNinjaKittyx - Is the implementation of your suggestion correct?

[xNinjaKittyx]

I checked it out. Looks fine to me. Would be nice to have 2 buttons though instead of having to right click.

[xNinjaKittyx]

I checked it out. Looks fine to me. Would be nice to have 2 buttons though instead of having to right click.

[QuestofIranon]

Would it be feasible for a random playback option, where the playlist isn't shuffled but the next played item is randomly selected?

[QuestofIranon]

Would it be feasible for a random playback option, where the playlist isn't shuffled but the next played item is randomly selected?

[Et0h]

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.

[Et0h]

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.

[Et0h]

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').

[Et0h]

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').