Closed ddevault closed 7 years ago
Not heard anyone else with this issue. Running Syncplay with --debug switch sometimes gives more details. Could it be a firewall/permissions issue? Does the main syncplay.pl website work through your browser?
Oh, and are you using mpv? If not, try with mpv.
I am using mpv.
~ > syncplay --debug
:0: UserWarning: You do not have a working installation of the service_identity module: 'No module named service_identity'. Please install it from <https://pypi.python.org/pypi/service_identity> and make sure all of its dependencies are satisfied. Without the service_identity module and a recent enough pyOpenSSL to support it, Twisted can perform only rudimentary TLS client hostname verification. Many valid certificate/hostname mappings may be rejected.
[01:09:26 PM] player >> no-osd set pause yes
[01:09:26 PM] <mpv> Throttling message send, so sleeping for 0.05
[01:09:26 PM] player >> print_text ANS_pause=${pause}
print_text ANS_time-pos=${=time-pos}
[01:09:26 PM] File not loaded so using GlobalPosition for getCalculatedPosition(0.0)
[01:09:26 PM] player >> print_text ANS_pause=${pause}
print_text ANS_time-pos=${=time-pos}
[01:09:26 PM] player << [vo/opengl] retrieving framebuffer depth: OpenGL error INVALID_OPERATION.
[01:09:26 PM] <mpv> Ready to send: True
[01:09:26 PM] player << ANS_pause=yes
[01:09:26 PM] player << ANS_time-pos=
[01:09:26 PM] player << ANS_pause=yes
[01:09:26 PM] player << ANS_time-pos=
[01:09:26 PM] File not loaded so using GlobalPosition for getCalculatedPosition(0.0)
[01:09:26 PM] player >> quit
[01:09:26 PM] player << Exiting... (Quit)
[01:09:26 PM] <mpv> Throttling message send, so sleeping for 0.05
[01:09:26 PM] player >> quit
[01:09:26 PM] <mpv> Throttling message send, so sleeping for 0.05
[01:09:26 PM] player >> quit
I can reach to the server in question just fine, the issue is definitely with syncplay. It's not firewall related for sure. Where's all your error logging man?
Is the issue that you don't have service_identity installed? What OS/set-up are using?
I mentioned that in my initial comments. I'm using Arch Linux, tried both the package from the arch repositories and compiling syncplay myself from HEAD. service_identity isn't the issue - installing it doesn't fix the problem, and it wasn't installed when syncplay worked fine in the past.
The AUR syncplay-git package was updated to include the latest HEAD. It worked for me with both vlc and mpv, albeit on a server hosted on localhost. Note that the systemd unit file for the server is now of the systemctl start syncplay@youruser
format.
@SirCmpwn: Can you confirm whether or not that fixed it? @blaenk: Since you've updated your Arch package, is there anything which we need to done our end, e.g. update any website documentation?
Are you referring to the fact that I changed the systemd unit file? If so there shouldn't be anything needed on your end, and it's a pretty trivial change that people should pick up on easily, if not they can comment on the package page for clarification.
To clarify, this change was done after viewing this issue, that is to say, it's not that the update to the package caused this issue, since I made the change after, and it simply changes things so that the server runs as the specified user instead. Aside from that it incorporates any changes made to syncplay up until the package was updated (in the case of the -git package which tracks the repo/master).
I'll have to check it out later, incompetent package maintainers on arch broke a lot of Python stuff today.
Tried it out yet @SirCmpwn?
Sorry for abandoning this issue, it's been working for a while now. Don't know what the cause was.
I cannot connect to any of the default servers, nor my own server (running HEAD), with either the latest arch client or the HEAD client. There are no useful error messages anywhere (unable to connect in client, no logging whatsoever on server). My buddy can reproduce.