Explanation/discussion of intended sync behaviour (playlists, play/pause, seeking, etc)

[Et0h]

My work on #280 has resulted in me reviewing what the 'correct' behaviour should be in terms of when to change the play/pause state, the playlist, the currently playing file, and the position. I am both codifying what the previous behaviour was intended to be (even if this didn't always work for some media players) and provide on what the behaviour should be in certain situations where at the moment it either is not consistent or the previous behaviour was emergent rather than intentional.

A summary of my initial thoughts on the anticipated/proposed Syncplay behaviour (assuming you can control the room you are in):

• Launch Syncplay with shared playlists disabled: Media opens (if specified in launch options), and if nobody else is in the room it starts as paused at 0:00 (and otherwise follows the room's paused status and playback position).
• Join a room later, after having connected: If nobody else is in the room it starts as paused at 0:00 (and otherwise follows the room's paused status and playback position). If shared playlists are enabled, it changes file to the one playing in the room if it can be located.
• Launch Syncplay with media specified to join a room with empty playlist: Add media to playlist, open at 0:00 and pause.
• Launch Syncplay with media specified to join a room with an existing playlist: The file is added to the end of the playlist if it is not already there. If the currently playing file in the playlist is one you do not have and the file you specified is not in the playlist then it will alternatively assume you are trying to watch with an alternative version of that file and load it in the media player without changing the playlist. Either way, you will be synced to the current pause/position state of the room.
• Get to the end of a file with shared playlists are enabled It advances to the next file, resets to 0:00. Then auto-plays after 3 seconds unless someone in the room is set to not being 'ready' (or unless you are the only one in the room).
• Select a different file from the playlist Changes playlist selection, resets to 0:00 without changing the play/pause state (so it will continue playing/paused if that was what was previously happening).
• Manually open a new media file through the media player or through Syncplay, with shared playlists enabled If in the playlist it will change to this file. If the file is not in the playlist it will open it but not change the playlist or change the playback/position state. If someone updates the playlist or the playlist file was previously unavaiable and becomes available then Syncplay may automatically change back to the file in the playlists if the file can be accessed. Generally it is not a great idea to open a new file not in the playlist while Syncplay is running if you have shared playlists except for if you have the wrong filename for the currently playing file and want to open it.

Note: The original behaviour of joining the room with a file never had a defined behaviour for what happens if you join a room with a file selected which differs to what is in the shared playlist. This led to some erratic behaviour, with it sometimes changing you to what is on the playlist and sometimes changing the playlist to what you opened. For increased consistency, the version set out above will always assume that if you open Syncplay with a file selected it is because you want to watch that video, but not necessarily straight away. This is why it will add it to the playlist if it is not already there, but if another file is currently playing through the shared playlist feature then it will not interrupt that playback so as to minimise disruption. For those who do not want this behaviour they can disable shared playlists in their configuration window

To help understand the decisions made in relation to Syncplay behaviour, here are a few guiding principles (in no particular order):

• Simplicity. Unnecessary complexity can lead to unpredictable behaviour, features people never use, and a harder to manage (and therefore more likely to be buggy/unreliable) code base. We want to cover the main uses cases, not every possible circumstance (especially where there are reasonable workarounds).
• Consistency/Predictability. It is usually better for behaviour to be intuitive, and that usually means always doing the same things when the circumstances observable by the user are the same. This also means that where there is an established behaviour then it should not be changed without good reason.
• Intentionality. If a user takes an optional action then it is usually because they want something to happen. The main exception might be if they are not aware of something, e.g. do not know that a file is already in the playlist. When Syncplay might does not respond how the user expects is is usually a good idea to have some sort of notification so that the user knows why.
• Disruption minimisation. Try to minimise erroneous actions that can be quite disruptive, e.g. changing the currently playing file in the middle of a video's playback. If there is a less disruptive interpretation then this is often the preferred behaviour.
• Functionality. The main reason we have many of these features and behaviours is to help improve the Syncplay experience and to help people focus on watching videos rather than managing Syncplay.
• Responsiveness. When a user performs an action, it is good for it to be acted upon sooner rather than later so that they know that it worked and because quick responses generally provide a better user experience. This also ties in with providing errors if what the user wants to do is not possible, so that even if they do not get the response they wanted they at least know that Syncplay understood what they were trying to do.
• Privacy. Try to avoid giving the user/client the ability to easily share their private information unintentionally, especially material from the user's clipboard.
• Compatibility. Forwards and backwards compatibility are both generally a good thing. As such, breaking compatibility should be the exception rather than the rule. However, in some cases it may be appropriate to drop support for older versions of media players, etc., in the interests of code simplicity and maintainability. There may also be security reasons to drop support for older media player builds or older operating systems.