Skip to content
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

Feature Request: Update Video Player when Shared Playlist updates #472

Closed
Zefferis opened this issue Oct 21, 2021 · 6 comments
Closed

Feature Request: Update Video Player when Shared Playlist updates #472

Zefferis opened this issue Oct 21, 2021 · 6 comments

Comments

@Zefferis
Copy link

Zefferis commented Oct 21, 2021

When using a Shared Playlist and playing a video in MPV*, if the shared playlist has reached it's end and the player has paused on EOF (End of File), when a new file/URL has been added to the end of the Shared Playlist, the MPV Player does not automatically load the next file/url.

*Not tested in other media player applications

To update the shared playlist a user must either go back in MPV to restart the file in order to play -> trigger EOF again;; or go into SyncPlay and manually open the next playlist item.

Within MPV a user is able to run:
/qa <URL/FilePath>
This updates the playlist in SyncPlay, but not within MPV, and does not trigger play of this newly added file/url if they are already at EOF of the latest shared playlist item.


Recommendation:

  1. If a file is already paused on EOF and at the end of the shared playlist, trigger movement to the next shared playlist item if one is added / if the shared playlist is updated.

OR

  1. Update MPV's Playlist to reflect that of the SyncPlay Playlist when the playlist is updated.

Image of issue:
image

@Et0h
Copy link
Contributor

Et0h commented Oct 27, 2021

Thanks for this suggestion. I would be interested to hear what others think about whether or not it should auto-advance in that circumstance (i.e. when you were at the end of the playlist and paused at EOF and then new items are added below the current item on the playlsit).

The expected behaviour for playlist advancement on EOF in #315 is that "When yet to the end of a file with shared playlists are enabled it should advances to the next file, resets to 0:00". However, this doesn't specify what should happen if there isn't a file at that point but one is added to the playlist subsequently.

In favour of changing:

  • Convenience for those using /qa in mpv who want to add to the playlist who want to move onto the next item in the playlist.
  • This would arguably be consistent with the behaviour for when you open Syncplay without anything in the playlist and add a new file to the empty playlist and it automatically switches to that file.

Against changing:

  • This would take development time to develop and test. The playlist advancement code is complex, so changing it is time-consuming and any modification could result in new bugs being introduced that are hard to identify and fix.
  • If someone has an older client but sometimes joins rooms with people who have a newer client then they would experience inconsistent behaviour because sometimes adding a playlist item after EOF would do nothing and sometimes one of the users would auto-switch.
  • People might be used to the current behaviour and rely on it for some reason. Without feedback it's hard to know how many people (if any) might want the status quo to be retained and for what reason. The best use case I can think of is that someone might sometimes add 'one more show to watch' to the playlist as a suggestion of what to watch but without intending for Syncplay to auto-switch to the file and if they had auto-play enabled it might then start playing the next episode which would then require corrective action from the user (and negating the benefit of them having waited until the EOF of the last playlist item before adding the file to the playlist).

@Zefferis
Copy link
Author

Zefferis commented Oct 27, 2021

Oh my gosh, thank you so much for a thorough response to the suggestion.

After thinking about the differences one client may have with another, perhaps a more minimal change could be an alternative.

I mentioned

"/qa <>" because it allowed for in-player actions without additional thought, this does add an item either within MPV or SyncPlay Client to the bottom of the playlist

However you would not immediately know what the latest playlist item's "index" number is if using the

"qs " command

Would it be possible for a later version of syncplay to include:

"/qs <index|last>" (adding "last" to indicate the last item in the playlist without needing to count

Within the client an individual could perform a "/qa <URL|FILE" followed by "/qs last" to skip to this new item.

Or combine the activities with a command such as "/qas <URL|FILE>" which would indicate that someone wants to add an item to the end of the playlist and play it?

Et0h added a commit that referenced this issue Oct 28, 2021
@Et0h
Copy link
Contributor

Et0h commented Oct 28, 2021

@Zefferis I have now added '/qas' functionality to Syncplay in response to your suggestion.

Please get the relevant pre-release development snapshot from https://github.com/Syncplay/syncplay/releases/tag/v1.7.0-snapshot1 and let me know if it works.

@Zefferis
Copy link
Author

Zefferis commented Nov 1, 2021

@Et0h I'm so sorry for the delay in responding, I've been out of town until today;

I'll be using 1.7.0 with my group today and I'll provide additional feedback tomorrow. Thank you for adding the "/qas" command!

@Zefferis
Copy link
Author

Hey @Et0h my friends are very happy with the /qas command, it's been super helpful and useful for us!

We haven't seen any issues pop up with any of our uses!

@Et0h
Copy link
Contributor

Et0h commented Nov 13, 2021

Thanks for letting me know @Zefferis. In that case I'll close this issue and the new feature will be included in Syncplay 1.7.0.

@Et0h Et0h closed this as completed Nov 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants