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

Playlists on VLC #40

Closed
nnamrrehdlopoel opened this Issue May 11, 2014 · 24 comments

Comments

Projects
None yet
6 participants
@nnamrrehdlopoel

nnamrrehdlopoel commented May 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Uriziel

Uriziel May 11, 2014

Contributor

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

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

Contributor

Uriziel commented May 11, 2014

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

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

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h May 11, 2014

Contributor

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.

Contributor

Et0h commented May 11, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DerGenaue

DerGenaue May 12, 2014

Contributor

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

Contributor

DerGenaue commented May 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h May 12, 2014

Contributor

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

Et0h commented May 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DerGenaue

DerGenaue May 12, 2014

Contributor

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

Contributor

DerGenaue commented May 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Uriziel

Uriziel May 12, 2014

Contributor

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.

Contributor

Uriziel commented May 12, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h May 12, 2014

Contributor

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

Contributor

Et0h commented May 12, 2014

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

@DerGenaue

This comment has been minimized.

Show comment
Hide comment
@DerGenaue

DerGenaue May 13, 2014

Contributor

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)

Contributor

DerGenaue commented May 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Uriziel

Uriziel May 13, 2014

Contributor

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

Contributor

Uriziel commented May 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Uriziel

Uriziel May 13, 2014

Contributor

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?

Contributor

Uriziel commented May 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DerGenaue

DerGenaue May 13, 2014

Contributor

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.

Contributor

DerGenaue commented May 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Uriziel

Uriziel May 13, 2014

Contributor

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

Contributor

Uriziel commented May 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h May 13, 2014

Contributor

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 :)

Contributor

Et0h commented May 13, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h May 21, 2014

Contributor

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

Contributor

Et0h commented May 21, 2014

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

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Jun 29, 2014

Contributor

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

Contributor

Et0h commented Jun 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@DerGenaue

DerGenaue Oct 28, 2014

Contributor

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

Contributor

DerGenaue commented Oct 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Nov 2, 2014

Contributor

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

Contributor

Et0h commented Nov 2, 2014

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

This comment has been minimized.

Show comment
Hide comment
@co3xist

co3xist Nov 19, 2014

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.

co3xist commented Nov 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Nov 19, 2014

Contributor

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?

Contributor

Et0h commented Nov 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@co3xist

co3xist Nov 19, 2014

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.

co3xist commented Nov 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Nov 19, 2014

Contributor

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.

Contributor

Et0h commented Nov 19, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Marcuzzz

Marcuzzz Nov 23, 2014

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!

Marcuzzz commented Nov 23, 2014

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Feb 17, 2015

Contributor

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.

Contributor

Et0h commented Feb 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Jul 3, 2016

Contributor

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

Contributor

Et0h commented Jul 3, 2016

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

@Et0h Et0h closed this Jul 7, 2016

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