Feature Request: Update Video Player when Shared Playlist updates

[Zefferis]

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

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

Image of issue:

[Et0h]

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]

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]

@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]

@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]

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]

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.