OS X: syncplay does not run on macOS Sierra 10.12

[albertosottile]

Syncplay (1.3 and 1.4) does not run on macOS Sierra 10.12 . After pressing the button "store configuration and run Syncplay", the console gives this error:

ValueError: time data '@variant(' does not match format '%Y-%m-%d %H:%M:%S.%f'

The first window does not close and the syncplay media windows nor VLC do not start at all. If the button is then pushed again, the same error keeps showing up.

Tracing back the error, it points to the comparison in syncplay/resources/ui/GuiConfiguration.py line 281
if self.lastCheckedForUpdates > datetime.strptime(self.config["lastCheckedForUpdates"], "%Y-%m-%d %H:%M:%S.%f"):

If printed, both the variables self.config["lastCheckedForUpdates"] and self.lastCheckedForUpdates contain @variant( . I have no idea why, but it seems that macOS 10.12 changed how these settings are stored/read from config files and/or the UI. I tried to correct this bug by myself but I am not a python developer, I did not find a way to alter or restore these values.

I "patched" the bug by disabling entirely this update check, by commenting lines from 279 to 284 in GuiConfiguration.py. With this edit, Syncplay and VLC start correctly, but then crash with a similar error, this time in gui.py, line 1326. This can be "solved" by disabling update check from the UI or commenting lines between 1325 and 1334. This way syncplay runs on macOS 10.12.

I understand that you do not have a macOS test system, so please let me know if I can assist you in fixing this bug for real.

Thanks for all your work, syncplay is amazing!

[Et0h]

Cheers, I'll look into whether the code can simply be disabled for OSX users without causing other problems.

[albertosottile]

Nevermind, Syncplay is actually unusable with macOS 10.12 Sierra. I guess lot of stuff were stored in these way, not only lastCheckedForUpdates , and apparently they are all broken. The program "seems" to run, but gives a lot of errors and constantly goes out of sync. Here there is a log from a session that I attempted to run today

18:47:25] unpaused
[18:48:35] Warning: The media player took 9 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.
[18:48:46] Rewinded due to time difference with
[18:48:46] Slowing down due to time difference with
[18:48:56] Rewinded due to time difference with
[18:48:56] Rewinded due to time difference with
[18:48:56] Rewinded due to time difference with
[18:48:56] Rewinded due to time difference with
[18:48:56] Rewinded due to time difference with
[18:49:06] Connection with server lost, attempting to reconnect
[18:49:10] Attempting to connect to syncplay.pl:8995
[18:49:20] Connection with server timed out
[18:49:20] Connection with server lost, attempting to reconnect
[18:49:32] Attempting to connect to syncplay.pl:8995
[18:49:34] has joined the room: 'room'

Hello Alby,

The Syncplay latest is available from http://syncplay.pl/

[18:49:34] Successfully connected to server
[18:49:34] is playing 'filename.mkv' (20:32) in room: 'room'`

It does this every 2 or 3 minutes. I am going to try if syncplay portable can run in a Wine bottle and if not, I am going to downgrade back to 10.11 or give up and abandon Syncplay entirely. Please, at least state clear on the website and on Github that syncplay is NOT compatible with macOS 10.12 Sierra at all, so that no one else will have to go through this.

Thanks

[Et0h]

Thanks for your work on this - the website has now been updated. If you can get it to work with Wine please write some instructions to go on the website.

[albertosottile]

I tried with Crossover 15.3 (basically Wine), but the bottle crashed after pushing "Store configuration and run Syncplay". I already downgraded to macOS 10.11.6 where everything is fine. I think part of the problem (if not all of it) is due to the pyside and qt4 support on 10.12. Maybe in the future there will be updates fro these packages and syncplay will then work seamlessly. I think I will give it another try on 10.12 in the next few months.

[Hamuko]

I think part of the problem (if not all of it) is due to the pyside and qt4 support on 10.12. Maybe in the future there will be updates fro these packages and syncplay will then work seamlessly.

Homebrew devs currently consider Qt4 a deprecated product, as it's currently dead on upstream and has been broken on OS X for a couple of major versions as of now. For Qt4 to work on OS X 10.11, the formula had to be patched before building and for 10.12, there's even more patches to be applied. The devs do not consider cutting features one at a time from Qt4 as a viable strategy, so it will probably not be supported past 10.11.

You can find more information as well as the fix to install Qt4 on 10.12 via Homebrew at Homebrew/homebrew-core#5216. It does definitely work to get Qt4 and PySide working on 10.12, as I tried it out yesterday. However, the Syncplay core worked as well for me with mpv as it did on 10.9, that is to say not at all. But I guess if you formerly had Syncplay working on OS X, you could fix the client this way.

The long-term solution would be to switch to Qt5, but as far as I know, PySide does not work with Qt5 and PySide2 is far from production ready. PyQt would work with Qt5, but that requires the entire project to be converted to GPL. So as far as I see it, there just isn't a good strategy to get the Qt GUI working on current and future versions of OS X.

[albertosottile]

I am aware of this, I used the tap from @cartr to install qt4 and pyside on 10.12, without that it would have been impossible to even run Syncplay with a GUI on 10.12. We could try to file an issue on his tap ( https://github.com/cartr/homebrew-qt4 ) but we need a test system with 10.12 and currently I downgraded to 10.11 to be able to use Syncplay again. Also, i think that we need a POC code that just uses ConfigDialog and reproduces the issue, to help the developer to fix the bug.

Moreover, this effort will only fix the UI bugs that I addressed by commenting the code, but not the loss of sync that I experienced later. To be honest, I have no idea of why that happened, and we cannot have any input from Syncplay's developers because they do not have a Mac. So I don't see an easy way to solve these problems. Speaking of that, if any of you has any idea of what (qt related or not) could have caused the problems described in the third comment, please share.

[Hamuko]

From what I could tell from testing Syncplay on macOS, it seems that there's just absolutely no communication between mpv and Syncplay. I joined a room and it would not announce a file and it would not sync up the player at all. I had a quick look at how the mpv integration is built, but I was not really able to get a good grasp at what the working logic of it was.

Of course, this doesn't really relate to your problems with VLC, since I don't use it and have even less of a clue as to how that operates. However, I am not really aware of any other fact about macOS that causes the lack of sync other than the player communication. When I first tested Syncplay on OS X (10.9), I could not get VLC or mpv to communicate properly with the client, although VLC would at least do something, even though it seemed to result in lots of seeking and resets quite early.

Since I don't really have an idea as to how to fix Syncplay for my own usage, I decided on Tuesday to start working on my own implementation of the client software using the protocol documentation. I'm also using a different method of communicating with mpv (as far as I can tell), which seems to result in better syncing of the file and playback information. However, I don't think that the implementation is at all portable for other operating systems, Windows in particular. It also might not be just the player integration, as I am rewriting all of the protocol communication as well.

[albertosottile]

I have never experienced these problems with VLC on macOS before updating to 10.12, I am quite surprised that you had with VLC. I used syncplay both with conda and with installed packages (via homebrew or macports) and never had any sync issues with VLC up to macOS 10.11. I even have a packaged .app I made for myself a while ago (syncplay 1.3.0) that works with VLC (up to 2.2.3, did not try 2.2.4 yet) with macOS from 10.9 to 10.11. If you are interested, I can send it to you.

[Hamuko]

Not really even interested, since VLC is a shit player all in all. I was surprised to see this week that I even had it on my computer, seemingly left over from my testing of Syncplay probably around last summer.

But as far as I remember the event, it would actually communicate the file information to the server, the playback would start with the rest of the people, but within a few minutes (at max), there would be tons of speed modifications and skipping. Pretty sure at some point the video just skipped right to the beginning. It was so terrible that we just decided to post "START" in IRC and watch them all independently.

[albertosottile]

This is weird, I wonder if I got lucky or if you had some extra troubles on your system... I am using that .app since February 2015 with no sync issues, even during movies (so 2h+ length), although I have to admit I am using it only with one person and never tried groups.

[albertosottile]

I started digging on this issue (even though I do not have a 10.12 Sierra system to test at the moment) and for now I focused on the '@variant(' problem. In the pyside 1.2.1 documentation, in the method PySide.QtCore.QSettings.value(key[, defaultValue=None]) there is this warning:
http://pyside.github.io/docs/pyside/PySide/QtCore/QSettings.html#PySide.QtCore.PySide.QtCore.QSettings.value

Warning: QSettings.value can return different types (QVariant types) depending on the platform it’s running on, so the safest way to use it is always casting the result to the desired type, e.g.: int(settings.value(“myKey”))

I am writing to the syncplay developers now. It could be possible for you to cast explicitly all the calls of this QSettings.value method in the code? I tried to look at the code and this method is not called that often, but I still have some difficulties in find the right type on my own (thanks Python). If you could make this cast this should solve at least the first bug (caused by this incorrect casting) and maybe also the others, without breaking the support for other platforms.

[Et0h]

Thanks for that research. I'll look into adding proper Variant typing when I next have some free time. In the meantime, it might worth checking out Hamuko's work on an OS X Python 3 alternative client for Syncplay users: https://github.com/Hamuko/Sopu

[Hamuko]

I'd like to point out that my alternative client is far from finished currently. A major feature missing from it currently is the ability to seek the video. But I have used it to watch TV episodes with a friend using the official client quite nicely, so you should at least be able to participate in the viewing.

[albertosottile]

This qt4 on Sierra bug has been reproduced (and patched) by Qt developers, but only for qt5 ( qt/qtbase@764f5bf ). Other developers have successfully backported this patch to qt4 ( mumble-voip/mumble#2638 ). So the next step would be to patch qt4 source code in this way, compile it on 10.12 and see how Syncplay behaves with this patch. Unfortunately, I uninstalled 10.12 precisely because I need a working copy of Syncplay on my system... If anyone else could try if this works, that would be great.