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

Playlist shuffle behaviour needs changing (but to what?) #153

Closed
Et0h opened this Issue Oct 19, 2017 · 7 comments

Comments

Projects
None yet
3 participants
@Et0h
Contributor

Et0h commented Oct 19, 2017

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.

@Et0h Et0h added bug question labels Oct 19, 2017

@Et0h Et0h changed the title from Incorrect shuffle behaviour to Incorrect shuffle behaviour (+discussion on what correct behaviour should be) Oct 19, 2017

@Et0h Et0h changed the title from Incorrect shuffle behaviour (+discussion on what correct behaviour should be) to Playlist shuffle behaviour needs changing (but to what?) Oct 19, 2017

@xNinjaKittyx

This comment has been minimized.

Show comment
Hide comment
@xNinjaKittyx

xNinjaKittyx Oct 27, 2017

Contributor

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.
Contributor

xNinjaKittyx commented Oct 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Oct 27, 2017

Contributor

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

Contributor

Et0h commented Oct 27, 2017

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

Et0h added a commit that referenced this issue Nov 5, 2017

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Nov 5, 2017

Contributor

@xNinjaKittyx - Is the implementation of your suggestion correct?

Contributor

Et0h commented Nov 5, 2017

@xNinjaKittyx - Is the implementation of your suggestion correct?

@xNinjaKittyx

This comment has been minimized.

Show comment
Hide comment
@xNinjaKittyx

xNinjaKittyx Nov 10, 2017

Contributor

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

Contributor

xNinjaKittyx commented Nov 10, 2017

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

@QuestofIranon

This comment has been minimized.

Show comment
Hide comment
@QuestofIranon

QuestofIranon Nov 11, 2017

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

QuestofIranon commented Nov 11, 2017

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

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Nov 12, 2017

Contributor

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.

Contributor

Et0h commented Nov 12, 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.

@Et0h Et0h closed this Nov 12, 2017

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Nov 12, 2017

Contributor

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

Contributor

Et0h commented Nov 12, 2017

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

albertosottile added a commit to albertosottile/syncplay that referenced this issue Nov 12, 2017

albertosottile added a commit to albertosottile/syncplay that referenced this issue Nov 12, 2017

albertosottile added a commit to albertosottile/syncplay that referenced this issue Nov 12, 2017

albertosottile added a commit to albertosottile/syncplay that referenced this issue Nov 12, 2017

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