Sync fails some times

[Flova]

[Flova]

Bug description

Youtube

• Open two clients with a youtube video
• Start the Video on the first one
• The scond one needs an interaction (autoplay block), so you also click start
• Both play in sync
• Stop the second player
• Both stop
• Start the second player
• Only the second player starts, the first one ist still paused
• If you start/stop any player one more time the problem is fixed and does not occure anymore A bit of debugging shows that the second player is falsely in the "Skip next play" state after starting the video. This results in an skip of the next play as it is observed. My assumtion is that some things went wrong with the "state skiping" initalisation if the player is the second one.

L2G

• Open two clients with a lecture2go video
• Start the Video on the first one
• The scond one needs an interaction (autoplay block), so you also click start
• Both play in sync
• Stop the second player
• Only the second player stops, the first one ist still paused
• If you start/stop any player one more time the problem is fixed and does not occure anymore A bit of debugging shows that the second player is falsely in the "Skip next pause" state after starting the video. This results in an skip of the next pause as it is observed. My assumtion is that some things went wrong with the "state skiping" initalisation if the player is the second one.

[vesper8]

Hi @Flova

Cool project! I'm interested in it as I'm working on something similar but more related to music.

I noticed quite a few sync issues, most of which are mentioned in this issue here. I also thought that there is no way around needing the 2nd client to start the video because it needs user interaction.

However I was a bit surprised to find a similar project to yours here https://github.com/ubclaunchpad/sync that doesn't have these issues

If you try their demo here: https://sync.ubclaunchpad.com

Create a room, paste a youtube video, then open that room url in a 2nd browser.. you'll see that starting the video on the 1st screen effectively starts it on the 2nd as well. And that pausing on the 2nd also pauses on the first.

So somehow they've found a way around the problems described in this issue. Maybe it can help you bring this solution to your project too : )

Cheers!

[Flova]

Hi @vesper8

Thanks for the feedback and the infos. Also thanks for sharing the other project with us.

There is indeed a user interaction needed for the second client. But the problem described in this issue seems related to the video javascript library video.js. It does not distinguish between a manual interaction and an interaction via api therefore we need to stop listening while setting a state in the api. Otherwise, this state change gets published again by video.js as user interaction and we have an endless loop between the clients. To prohibit this behavior we drop user inputs occurring shortly after an incoming state change. Sadly this is a bit hacky and somehow sometimes a bit broken (the real user interaction gets blocked long after a state change). We definitely have a look, which library is used in the project you shared with us.

Cheers!