Syncplay breaks syncing on jump.

[LShirohana]

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.

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]

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]

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

[LShirohana]

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]

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]

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]

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]

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]

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]

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]

@LShirohana Any luck with trying to debug the issue?

[LShirohana]

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]

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