Playlists on VLC

[nnamrrehdlopoel]

If you have multiple files in queue and switch over to the next one, something bad happens:
One of the players jumps into the next file and syncs the time position with the other player. If the file is too short, it continues jumping until a long enough file is reached.
So you often end up playing another file from somewhere halfway through.

nnamrrehdlopoel

[Uriziel]

Playlists in players are not supported and they probably won't be.

We've got planned Syncplay's shared playlist though.

[Et0h]

At present Syncplay never automatically rewinds without being told to, but if one person has a file that is shorter than everyone else's then their player will be rewinding other people's players. So for now what you have to do is pause at the end, seek to 0:00, all change files, then resume. If one person rewinds it then never gets to the end of the playlist for other people, we could make it ignore rewind commands under circumstances, but that could result in inconsistent behaviour (which is bad).

Some times people may want to change the file simply because they had the wrong file open, or because they want to open an alternative version (e.g. move from 1080 to 720 file if it is running slowly), so it is not safe to assume that they always want themselves and others to be rewinded and paused. Trying to guess if it is the next file in a sequence based on filename would result in inconsistent behaviour (which is, as I said earlier, bad).

We could make it so that if you change a file at the end of playback it rewinds for everyone, but often people may change episode at the start of the credits rather than at the end of a file, so then it would have to guess whether the person is at the end and may not advance people on their playlist, resulting in inconsistent behaviour (still bad).

We could make it so if you opened the file through Syncplay in a special way then it would know it was a new file and rewind, but that would not work for playlists and once again would not change files for other people. We could make it automatically change file for other people if they selected to allow for it, but as Uriziel mentioned we're already planning on a shared playlist feature.

[DerGenaue]

The difference is that a restart should happen,
if all the people in the room change file at nearly the same time (~1s)
eg. They both have set VLC to the same Playlist, therefore both Players should change file at the same time.
I'm still thinking about the best way for Syncplay to detect this...

[Et0h]

Potential (but not necessarily insurmountable or showstopper) problems with that approach:

1. It requires everyone to have the same playlist.
2. It may never get to the end for some people (e.g. because it will pause or rewind before they get to the end of their playlist).
3. It is hard to determine whether everyone is changing at once, potentially resulting in inconsistent behaviour.

[DerGenaue]

Exactly what I'm thinking about.

Solutions might be:

1. This is expectable. Elsewise the whole idea wouldn't make any sense. If not, what do we care (see below).
2. This is one problem I found my own solution to:
   I changed the VLC .lua to ignore any jump orders in the last and first seconds of a file. This works for us hearing an audio book together without any problems (so far)
   True solution:
   The client shouldn't post a rewind-command to the server when loading a new file. (as it does now).
   He just waits for 1sec or so before adjusting his own position to the global one. The last player doing this (during this second) sees that all the other have their time already set to beginning and therefore sets the global time to his local time. This would make sure that all together move to the new file. Of course they all need to have the same playlist and auto-play enabled; but see below
3. see 2.

Please notice:

1. my idea would be a "silent" implementation meaning it just works but is not a central element
2. I haven't yet fully understood the way Syncplay works, so please excuse wrong assumptions:
   Taken assumptions:
   Every client can see everyones position plus the global one (I don't yet understand how Syncplay works at this point)

PS: I'm currently working on a German translation

[Uriziel]

We gave it a thought some time ago and had similar ideas, but overall shared playlist inside the Syncplay is way more reasonable than any of those.

[Et0h]

A German translation? Neat. I guess I should get around to moving all messages to messages.py and allowing language selection...

[DerGenaue]

I've got one central question I don't yet fully understand:

Does the server only work as a communication platform for the clients or does he also alter values?

In this case:

Could the Server see when all Clients have the same time set that is different from the global time or is that something to be implemented Client-side?

(Idea: when all simultaneously change their local time, global time should be changed, too)

[Uriziel]

Well, there is no 'global time' value. Clients are synced to the slowest time in a room, server knows all the values of people's local times, yes.

Time is altered server side too, taking age of the set-up in consideration.

References:
https://github.com/Uriziel/syncplay/blob/newServerCode/syncplay/server.py#L191
https://github.com/Uriziel/syncplay/blob/newServerCode/syncplay/server.py#L277
https://github.com/Uriziel/syncplay/blob/newServerCode/syncplay/server.py#L325

[Uriziel]

Your idea doesn't work as clients never simultaneously change their time, there's always some difference (at least taking latency in mind).

While we have some ideas how it would be possible to implement player playlist support, I really can't see the point of doing that over implementing shared Syncplay playlist (changing files on-demand for all clients, one person can create list for everyone else, you can see files you're missing/are different).

Could you point any advantages of implementing that?

[DerGenaue]

You're probably right.
I thought it might be easier to implement and more direct for the users.
Maybe one could implement the client to wait one sec after opening a new file before seeking to the current time. If after this second all the other have changed file, too (time -> 0) then he doesn't need to seek anymore. This should be small and easy and should not affect other functions and would work in the way most users probably expect this to work.
But actually I still cannot see the overall picture so it's better if you decide what is right.

*Note: This would not make shared Playlists unnecessary, it just adds support for wanted sudden file-changes (maybe even through another plug-in or so)

I'm really looking forward to get to know Syncplay better as this is the first "big" project I actually take a look at the Sourcecode to.
At the moment I'm a little busy (school graduation exams, today Maths) but in a month or so I might have time to do some contributions to Syncplay.

[Uriziel]

By the way, if you have any questions about Syncplay behaviour or code the easiest place to get answers from would be the IRC.

[Et0h]

For sudden changes of files we could potentially make it rewind to 0 if you hold shift or control when you drag a file into Syncplay. This would be a consistent behaviour and would not duplicate the upcoming playlist feature. Good luck with your exams. When it comes to Syncplay developers, it is the more the merrier :)

[Et0h]

Shift+Drag (i.e. move) should now rewind the file (although if it doesn't then please let us know): 6b80c49 + 77b5c73

[Et0h]

DerGenaue: Regarding a German translation, Syncplay can now do a better job of handling multiple languages. In addition to messages.py we will also need text for the Windows installer (currently stored in buildPy2exe.py, although that may move).

[DerGenaue]

Hey Et0h and Uriziel,

now, half a year later I've got some more time, especially to do the translation job.
I'm now studying Informatics in Munich.
I will see what I can do the next few weeks

[Et0h]

Cool. We're currently working on Syncplay 1.3.0 which will have controlled rooms, so a few more messages to translate.

We've now got it so you can select a language when you install Syncplay and it will then use that language when you run Syncplay.

You can then change the language choice by changing the Syncplay config file or using the --language command line switch, but we're also going to allow users to change language through the configuration UI.

Another user is also currently working on a Russian translation: #44

[co3xist]

Hey, just going to drop in and add my support for playlists. A few friends and I are going to set up a service that involves Syncplay, that kind of feature would be incredibly useful.

[Et0h]

Thanks for the feedback. We are currently working on controlled rooms, improved mpv support, and incorporating translations of Syncplay into more languages (with supporting code for better language selection). After that our focus will likely be improved OS X support and an 'are you ready' feature. While shared playlist remains a key feature we hope to implement, unless we get more developers it might take a while. What sort of service are you going to be making?

[co3xist]

Controlled rooms like one person controls it all? Because that would be fantastic for the service I'm planning. That would be far more important than playlists to me - you would have my unending support if that is made available.

We want to do a sort of public movie night. People submit what they want to watch, then vote on what's been submitted and a time to watch it. Once that's all been done and people have acquired the film that we want to watch together, the movie starts at the previously selected time. Movie nights on a global scale, really. This would either be entirely server-moderated or would require some administrator input.

Some people involved in this want to be able to do TV shows and transition between episodes easily. I'm no great developer, but I'm working on improving my Python (experience now: near zero) and if my project starts getting dedicated or popular you can bet that I'll be helping out in whatever way I can.

[Et0h]

Controlled rooms means only the person who created the controlled room (and others authorised by that individual) can pause, play and seek in that room - see #45 for progress.

[Marcuzzz]

Nice work guys. New feature request do:
Sync playlists and the ability to loop/repeat them.
So we can have multiple screens, playing synced content.
Thx!

[Et0h]

The draft Shared Playlist spec is available from: http://syncplay.pl/Syncplay_Shared_Playlist_Draft_Spec.txt

One of the big questions is how Syncplay should handle persistence of shared playlists. If everyone leaves the room, does it stay attached to that room, and if so for how long? Should the length of persistence if everyone leaves be something that is specified server-side, with a default of an hour? Should it be remembered if you close the server and open it again? Should it forget as soon as everyone leaves the room, and rely on restorable client-side backups? Should shared playlists belong to a specific user, and then you can specify that a room subscribes to that user's playlist? Your thoughts are welcomed.

[Et0h]

Release Candidate 1 of Syncplay 1.4.0 with its shared playlists feature is out now! http://syncplay.pl/syncplay-1-4-0/