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

Syncplay breaks syncing on jump. #161

Closed
LShirohana opened this Issue Nov 21, 2017 · 12 comments

Comments

Projects
None yet
4 participants
@LShirohana

LShirohana commented Nov 21, 2017

Friend is on Arch Linux, syncplay version 1.5.0
I am on Win10, syncplay version 1.5.0
Server that I host is running 1.5.0

When he jumps around, pauses, etc, it works just fine.
If I pause, it is fine, we are still synced.

If I jump/skip around, it instantly desyncs. He no longer gets pauses/jumps from me and cannot send any to me, and I am forced to stay at the time I jumped from.

I assume this is a VLC issue (?) due to the fact I can syncplay other friends without issue, but my friend cannot with me. Nightly builds and switching versions do not seem to work. I can only assume that syncplay.lua has something that is breaking jumping.

RIP Syncplay

As you can see, he can jump, pause, etc, and I receive it (and VLC runs it), but the instant I jumped, friends's player desynced and would drag me back to 0:52. He could no longer pause/jump around with me. Only on his own.

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Nov 21, 2017

Contributor

I have not been able to reproduce your issue using mpv and VLC (2.2.6 and 3) on the same Windows 10 PC. Some things to try:

  1. Rename your syncplay.ini file in %APPDATA% to see if it is a non-default-configuration issue.
  2. Double check you using syncplay.lua version 0.3.3 and that it isn't warning you of using an older version.
  3. Trying to (back up and) resetting VLC preferences
  4. Run Syncplay in --debug mode and check out the .syncplay.log file in %APPDATA%
  5. Trying with mpv on both computers to confirm issue is with VLC.
  6. Provide more detailed reproduction instructions
Contributor

Et0h commented Nov 21, 2017

I have not been able to reproduce your issue using mpv and VLC (2.2.6 and 3) on the same Windows 10 PC. Some things to try:

  1. Rename your syncplay.ini file in %APPDATA% to see if it is a non-default-configuration issue.
  2. Double check you using syncplay.lua version 0.3.3 and that it isn't warning you of using an older version.
  3. Trying to (back up and) resetting VLC preferences
  4. Run Syncplay in --debug mode and check out the .syncplay.log file in %APPDATA%
  5. Trying with mpv on both computers to confirm issue is with VLC.
  6. Provide more detailed reproduction instructions
@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 9, 2017

Contributor

@LShirohana I've updated syncplay.lua which might resolve your issue if you were using VLC 4. Latest version is now available from https://raw.githubusercontent.com/Syncplay/syncplay/master/resources/lua/intf/syncplay.lua - please put it in whatever folder you currently have syncplay.lua in and tell me it resolves the issue. If it doesn't then refer back to my previous queries.

Contributor

Et0h commented Dec 9, 2017

@LShirohana I've updated syncplay.lua which might resolve your issue if you were using VLC 4. Latest version is now available from https://raw.githubusercontent.com/Syncplay/syncplay/master/resources/lua/intf/syncplay.lua - please put it in whatever folder you currently have syncplay.lua in and tell me it resolves the issue. If it doesn't then refer back to my previous queries.

@Et0h Et0h added bug and removed Unable to reproduce labels Dec 9, 2017

Et0h added a commit that referenced this issue Dec 9, 2017

@LShirohana

This comment has been minimized.

Show comment
Hide comment
@LShirohana

LShirohana Dec 13, 2017

Some notes

If my friend uses MPV, we can use syncplay successfully without issue. If we use VLC, regardless of version, it desyncs as usual.

The updated syncplay.lua did not change anything, as far as we can tell.

I think this might be an arch-linux/vlc issue, as we did this just fine until my friend started using arch linux, now it breaks.

Ill do some debugging once I finish finals this week.

LShirohana commented Dec 13, 2017

Some notes

If my friend uses MPV, we can use syncplay successfully without issue. If we use VLC, regardless of version, it desyncs as usual.

The updated syncplay.lua did not change anything, as far as we can tell.

I think this might be an arch-linux/vlc issue, as we did this just fine until my friend started using arch linux, now it breaks.

Ill do some debugging once I finish finals this week.

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 14, 2017

Contributor

Thanks for the update. Hopefully your debugging can help us figure stuff out. Your 'RIP Syncplay' link no longer works.

Message for @blaenk - the maintainer of https://aur.archlinux.org/packages/syncplay/ - Have you had any problems with Syncplay 1.5.0 and VLC on arch-linux? Do you have any idea what is wrong?

Contributor

Et0h commented Dec 14, 2017

Thanks for the update. Hopefully your debugging can help us figure stuff out. Your 'RIP Syncplay' link no longer works.

Message for @blaenk - the maintainer of https://aur.archlinux.org/packages/syncplay/ - Have you had any problems with Syncplay 1.5.0 and VLC on arch-linux? Do you have any idea what is wrong?

@LShirohana

This comment has been minimized.

Show comment
Hide comment
@LShirohana

LShirohana Dec 14, 2017

The RIP Syncplay link was simply showing that that once I skip, I no longer get any syncplay actions from him. EG if I skip to 02:00, and then he pauses (or skips, or anything else), usually it'll show in the syncplay log in the main program, but this is not the case, it's almost as if he's disconnected from me entirely, yet shows in the server.

I will be debugging when my arch friend gets home, as I do not have control of his arch PC. I'll make a pullrequest on syncplay.lua if I find the issue and can fix it, otherwise I'll give you an update.

LShirohana commented Dec 14, 2017

The RIP Syncplay link was simply showing that that once I skip, I no longer get any syncplay actions from him. EG if I skip to 02:00, and then he pauses (or skips, or anything else), usually it'll show in the syncplay log in the main program, but this is not the case, it's almost as if he's disconnected from me entirely, yet shows in the server.

I will be debugging when my arch friend gets home, as I do not have control of his arch PC. I'll make a pullrequest on syncplay.lua if I find the issue and can fix it, otherwise I'll give you an update.

@blaenk

This comment has been minimized.

Show comment
Hide comment
@blaenk

blaenk Dec 14, 2017

Contributor

I don't actually use VLC on Linux (I use MPV) but I'm happy to help if I can.

Did it ever work? If so, around when did it last work? Or what version of Syncplay and/or VLC?

Just to be sure, although you've described the issue already, can you provide clear and concise steps to reproduce? Something like:

  1. Windows load file
  2. ArchVLC load file
  3. ArchVLC skip to 2:00
  4. Windows observes skip to 2:00
  5. Windows skip to 4:00
  6. ArchVLC does not observe skip to 4:00
  7. Windows skip to 6:00
  8. ArchVLC does not observe skip to 6:00
  9. ArchVLC skip to 8:00
  10. Windows does not observe skip to 8:00, but it does appear in the log?
  11. Windows attempt to skip to 10:00, but gets sent back to 2:00?

I'm having trouble interpreting the complete details of the issue, so rather than fixing my interpretation, it would be helpful if you could write out each step and each observation at each step (e.g. "player didn't react but it did show in the log", "when I skipped it sent me back to position that ArchVLC last observed", etc).

Preferably something explicit enough to remove any possibility of me doing something different.

I'm not familiar with the VLC script, but it seems like something with respect to receiving events or processing received events. Arch tends to have bleeding edge packages so it may be a bug/regression that manifests in the latest versions of VLC.

Can you please have your friend give us the version numbers of the VLC and Syncplay packages? Perhaps something like this, since I'm not sure which package they have installed which provides each of those:

$ pacman -Qo $(which vlc)
$ pacman -Qo $(which syncplay)
Contributor

blaenk commented Dec 14, 2017

I don't actually use VLC on Linux (I use MPV) but I'm happy to help if I can.

Did it ever work? If so, around when did it last work? Or what version of Syncplay and/or VLC?

Just to be sure, although you've described the issue already, can you provide clear and concise steps to reproduce? Something like:

  1. Windows load file
  2. ArchVLC load file
  3. ArchVLC skip to 2:00
  4. Windows observes skip to 2:00
  5. Windows skip to 4:00
  6. ArchVLC does not observe skip to 4:00
  7. Windows skip to 6:00
  8. ArchVLC does not observe skip to 6:00
  9. ArchVLC skip to 8:00
  10. Windows does not observe skip to 8:00, but it does appear in the log?
  11. Windows attempt to skip to 10:00, but gets sent back to 2:00?

I'm having trouble interpreting the complete details of the issue, so rather than fixing my interpretation, it would be helpful if you could write out each step and each observation at each step (e.g. "player didn't react but it did show in the log", "when I skipped it sent me back to position that ArchVLC last observed", etc).

Preferably something explicit enough to remove any possibility of me doing something different.

I'm not familiar with the VLC script, but it seems like something with respect to receiving events or processing received events. Arch tends to have bleeding edge packages so it may be a bug/regression that manifests in the latest versions of VLC.

Can you please have your friend give us the version numbers of the VLC and Syncplay packages? Perhaps something like this, since I'm not sure which package they have installed which provides each of those:

$ pacman -Qo $(which vlc)
$ pacman -Qo $(which syncplay)
@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 15, 2017

Contributor

Please ensure that:

  1. There is only one copy of syncplay.lua on the computer
  2. The syncplay.lua file is the latest version of the interface (0.3.4)
  3. The syncplay.lua file is in the same folder as the VLC .luac files

If that doesn't solve anything then try resetting VLC preferences.

Contributor

Et0h commented Dec 15, 2017

Please ensure that:

  1. There is only one copy of syncplay.lua on the computer
  2. The syncplay.lua file is the latest version of the interface (0.3.4)
  3. The syncplay.lua file is in the same folder as the VLC .luac files

If that doesn't solve anything then try resetting VLC preferences.

@LShirohana

This comment has been minimized.

Show comment
Hide comment
@LShirohana

LShirohana Dec 18, 2017

Following all instructions, we generated the following .syncplay.log (which doesnt work on arch unless you do syncplay --debug >> .syncplay.log since it defaults to logging to appdata which doesnt exist on linux for obvious reasons. Found that bug out while debugging another, haha.

https://csgofoodreviews.com/bp/.syncplay.log

Our steps of reproduction managed to identify a few things as well as a guaranteed reproduction rate.

Steps:

Client A runs latest Syncplay on ArchLinux using VLC.
Client B runs latest Syncplay on Windows10 using VLC.
Both have updated syncplay.lua, one copy, and are connected to a server running the latest copy of syncplay.

Client A can move, pause, and skip (skip while paused or playing) and do any other action and nothing will go wrong.
Client B can skip while paused, pause/play without an issue. If Client B skips while the video is currently playing, it will desync. By desync, It seems, from our observation and other tests, VLC stops communicating with the syncplay application. Client B, from his perspective, can jump move and do whatever, but none of it is reported to the syncplay application and is not reflected on client A's side. Client A cannot see anything, as if Client B is not there anymore.

For proof of this, we conducted some tests such as pausing/playing via the syncplay window, not vlc. This worked correctly, even when desynced. Controlling video (unready, ready, pause, play, rewind) via the syncplay application worked as expected, but could not be controlled from the VLC player itself. As once you skip while a video is playing, it all breaks down.

Some random logs/debug info we managed to grab if interested.

[10:52:49 PM] Rewinded due to time difference with
[10:52:50 PM] jumped from 12:08 to 08:40
[10:52:50 PM] jumped from 12:08 to 09:47
[10:52:50 PM] Rewinded due to time difference with
[10:52:51 PM] Rewinded due to time difference with
[10:52:52 PM] Rewinded due to time difference with
[10:52:53 PM] Rewinded due to time difference with
[10:52:54 PM] Rewinded due to time difference with
[10:52:55 PM] Rewinded due to time difference with
[10:52:56 PM] Rewinded due to time difference with
[10:52:57 PM] Rewinded due to time difference with
[10:52:59 PM] Rewinded due to time difference with
[10:52:59 PM] jumped from 09:56 to 12:08
[10:53:01 PM] Warning: The media player took 2 seconds to respond. If you experience syncing issues then close applications to free up system res


[000@$$$ ~]$ pacman -Qo $(which vlc)
/usr/bin/vlc is owned by vlc-git 3.0.0.r15452.g32b60c9838-1
[000@$$$ ~]$ pacman -Qo $(which syncplay)
/usr/bin/syncplay is owned by syncplay 1.5.0.rc1-1


[10:53:28 PM] Warning: The media player took 29 seconds to respond. If you experience syncing issues then close applications to free up system resources, and if that doesn't work then try a different media player.

I've concluded that the issue is with the syncplay.lua file. As it seems to no longer communicate with syncplay application once desynced and does not correct itself.

Tell me if you need anything else, thanks!

LShirohana commented Dec 18, 2017

Following all instructions, we generated the following .syncplay.log (which doesnt work on arch unless you do syncplay --debug >> .syncplay.log since it defaults to logging to appdata which doesnt exist on linux for obvious reasons. Found that bug out while debugging another, haha.

https://csgofoodreviews.com/bp/.syncplay.log

Our steps of reproduction managed to identify a few things as well as a guaranteed reproduction rate.

Steps:

Client A runs latest Syncplay on ArchLinux using VLC.
Client B runs latest Syncplay on Windows10 using VLC.
Both have updated syncplay.lua, one copy, and are connected to a server running the latest copy of syncplay.

Client A can move, pause, and skip (skip while paused or playing) and do any other action and nothing will go wrong.
Client B can skip while paused, pause/play without an issue. If Client B skips while the video is currently playing, it will desync. By desync, It seems, from our observation and other tests, VLC stops communicating with the syncplay application. Client B, from his perspective, can jump move and do whatever, but none of it is reported to the syncplay application and is not reflected on client A's side. Client A cannot see anything, as if Client B is not there anymore.

For proof of this, we conducted some tests such as pausing/playing via the syncplay window, not vlc. This worked correctly, even when desynced. Controlling video (unready, ready, pause, play, rewind) via the syncplay application worked as expected, but could not be controlled from the VLC player itself. As once you skip while a video is playing, it all breaks down.

Some random logs/debug info we managed to grab if interested.

[10:52:49 PM] Rewinded due to time difference with
[10:52:50 PM] jumped from 12:08 to 08:40
[10:52:50 PM] jumped from 12:08 to 09:47
[10:52:50 PM] Rewinded due to time difference with
[10:52:51 PM] Rewinded due to time difference with
[10:52:52 PM] Rewinded due to time difference with
[10:52:53 PM] Rewinded due to time difference with
[10:52:54 PM] Rewinded due to time difference with
[10:52:55 PM] Rewinded due to time difference with
[10:52:56 PM] Rewinded due to time difference with
[10:52:57 PM] Rewinded due to time difference with
[10:52:59 PM] Rewinded due to time difference with
[10:52:59 PM] jumped from 09:56 to 12:08
[10:53:01 PM] Warning: The media player took 2 seconds to respond. If you experience syncing issues then close applications to free up system res


[000@$$$ ~]$ pacman -Qo $(which vlc)
/usr/bin/vlc is owned by vlc-git 3.0.0.r15452.g32b60c9838-1
[000@$$$ ~]$ pacman -Qo $(which syncplay)
/usr/bin/syncplay is owned by syncplay 1.5.0.rc1-1


[10:53:28 PM] Warning: The media player took 29 seconds to respond. If you experience syncing issues then close applications to free up system resources, and if that doesn't work then try a different media player.

I've concluded that the issue is with the syncplay.lua file. As it seems to no longer communicate with syncplay application once desynced and does not correct itself.

Tell me if you need anything else, thanks!

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Dec 19, 2017

Contributor

Thanks for your invesigations.

From the Syncplay log it looks like after "[11:13:12 PM] player >> set-position: 603.125059405 / [11:13:12 PM] player >> display-osd: top-right, 3, jumped from 04:14 to 10:03" VLC just goes completely silent.

It might be worthwhile using VLC's debug facility to see if it gives any Lua errors. If you set VLC settings mode to 'All' then under 'Advanced' is 'Logger' where I think you can set it to log to a file and choose where that file is. You can then look for references to lua or syncplay in the log file. You might need to tweak the verbosity level to get it to work.

You might also want to try disabling the OSD from Syncplay->Show more settings->Enable OSD Messages to see if that is the problem.

Contributor

Et0h commented Dec 19, 2017

Thanks for your invesigations.

From the Syncplay log it looks like after "[11:13:12 PM] player >> set-position: 603.125059405 / [11:13:12 PM] player >> display-osd: top-right, 3, jumped from 04:14 to 10:03" VLC just goes completely silent.

It might be worthwhile using VLC's debug facility to see if it gives any Lua errors. If you set VLC settings mode to 'All' then under 'Advanced' is 'Logger' where I think you can set it to log to a file and choose where that file is. You can then look for references to lua or syncplay in the log file. You might need to tweak the verbosity level to get it to work.

You might also want to try disabling the OSD from Syncplay->Show more settings->Enable OSD Messages to see if that is the problem.

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Mar 3, 2018

Contributor

@LShirohana Any luck with trying to debug the issue?

Contributor

Et0h commented Mar 3, 2018

@LShirohana Any luck with trying to debug the issue?

@LShirohana

This comment has been minimized.

Show comment
Hide comment
@LShirohana

LShirohana Mar 27, 2018

Tried with my friend on arch and we never managed to get any more info than we already have. We do not know if it desyncs on 1.5.2, as we have yet to test, but our 'solution' was just moving to MPV, or at least, he did. It works fine on mpv and we've been using it since.

Apologies for the delay, school is busy.

LShirohana commented Mar 27, 2018

Tried with my friend on arch and we never managed to get any more info than we already have. We do not know if it desyncs on 1.5.2, as we have yet to test, but our 'solution' was just moving to MPV, or at least, he did. It works fine on mpv and we've been using it since.

Apologies for the delay, school is busy.

@Et0h

This comment has been minimized.

Show comment
Hide comment
@Et0h

Et0h Apr 26, 2018

Contributor

I guess the solution for anyone having trouble with VLC is to use MPV.

Contributor

Et0h commented Apr 26, 2018

I guess the solution for anyone having trouble with VLC is to use MPV.

@Et0h Et0h closed this Apr 26, 2018

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