Syncplay syncs the playhead across separate players, and its packaging tells you how little is pinned

Syncplay moves the playhead, not the file

The job is narrower than the name suggests. Syncplay synchronises the position and play state of separate media players, so when one person pauses, unpauses or seeks inside their own player, the change is replicated to every player connected to the same server and sitting in the same room, which the docs call a viewing session. A player that joins later is brought into line with the room instead of starting over. The supported list is mpv, VLC, MPC-HC, MPC-BE and mplayer2, and each machine keeps playing its own local file, which makes this a timing tool rather than a streaming one. Text chat is built in; talking with voice is left to third party Voice over IP software. VLC even gets a file of its own, vlc-help.txt, at the top level of the tree, and no page in the repository says what reads it or when.

One stated non-goal, and rooms with no stated membership rule

The section called What it doesn't do takes a single sentence: Syncplay is not a file sharing service. That is the only boundary the docs draw, and it sits directly beside the thing they never settle. Rooms are the unit people share and a server is what they connect to, yet nothing in the repository names an account, a password, an invitation or any other rule for who may join a room. This matters more here than in a typical chat tool, because every client pushes its own position and play state into whatever room it finds, so membership decides whose playhead the others obey. Anyone hosting a server for a group should settle that policy outside the software instead of assuming it has one.

The file called Makefile only forwards to gmake

The top level holds both Makefile and GNUmakefile, and the one named Makefile is four lines that hand every target to gmake:

GNU=gmake $*
all:
	@$(GNU)
.DEFAULT:
	@$(GNU)

The variable expands to gmake followed by the requested target, and both the all rule and the catch all .DEFAULT rule run it with @ in front, so the command itself is not echoed. Everything a builder actually wants lives in GNUmakefile, which no page in the repository explains. The wrapper matters on macOS, where the make that ships with the system is not GNU make, and it silently assumes gmake is on the PATH of whoever runs it.

install_requires is two files joined into one list

The dependency list is not written in the packaging script, it is read out of the repository. setup.py opens requirements.txt and requirements_gui.txt, splits both on line breaks and concatenates them into install_requires before handing the result to setuptools, which means the headless server and the graphical client ship from one metadata block. The two entry points reflect that split without splitting the package: syncplay-server is registered as a console script pointing at syncplay.ep_server:main, and syncplay as a gui script pointing at syncplay.ep_client:main. There is no separate server distribution in the tree. Three more build scripts sit beside setup.py, appdmg.py, buildPy2app.py and buildPy2exe.py, and nothing in the docs says which of them still produces anything.

The version is imported and the classifier list breaks off

setup.py never writes a version number down. It imports version from the syncplay package and passes it through, so the number in a release tag and the number inside a built artifact come from two separate places and the script cannot catch a mismatch. The same file claims Development Status :: 5 - Production/Stable, names Twisted as the framework, Cocoa for macOS and Qt for X11, and sets the floor at python_requires>=3.4. The language list is where the file stops: five entries are spelled out, English, German, Italian, Russian and Spanish, and the sixth breaks off after the letters Pr. The three most recent stable tags are v1.7.4 on 2025-03-21, v1.7.5 on 2026-02-19 and v1.7.6 on 2026-08-04, 335 days apart and then 166, with master last pushed on 2026-09-13.

Apache 2.0 in the license section, MIT in the header above it

The first lines of the README are an HTML comment that says Copyright (C) 2019 Syncplay and that the file is licensed under the MIT license, followed by the usual MIT permission text in full. Twenty lines further down, the License section states that the project, the released binaries and every file in the repository are licensed under the Apache License, version 2.0, unless stated otherwise in the header of the file. Read strictly, the header above is exactly that exception, and the repository metadata agrees with Apache-2.0. Read the way most people read it, the top of the file says MIT and nothing on that line mentions the exception. Attribution for bundled third party media is handled separately, in a file at syncplay/resources/third-party-notices.txt, which is the one path in the license text you would want to check against whatever media you actually play.

TLS packages are required and key setup is nowhere

The runtime requirements are six lines, and three of them exist to make encrypted connections possible: certifi>=2018.11.29, pem>=21.2.0 and twisted[tls]>=16.4.0. The remaining three are platform extras, appnope on macOS and pypiwin32 plus zope.interface on Windows. The floors are old, which leaves a lot of room above them, but the gap that matters is elsewhere. A certificate authority pair and a Twisted TLS stack are exactly what a server needs before it can serve encrypted traffic, and no page in the repository says where a key and certificate come from, which file holds them, or whether the server offers a plain socket by default. If you expose a Syncplay server beyond your own network, that is the first question to answer from the source.

Two projects share the name SyncPlay

The Authors section credits four roles and one of them points somewhere else. The initial concept and core internals go to Uriziel, GUI design and the current lead to Et0h, and the original SyncPlay code to Tomasz Kowalczyk (Fluxid), who developed SyncPlay at a separate GitHub address. The wording leaves the relationship between the two projects open. It does not say whether this code descends from that one, borrows from it, or carries the same name independently, and setup.py points its url and download_url at syncplay.pl rather than at the other repository, so nothing in the package metadata disambiguates them either. The two names are indistinguishable in a list of links, which is worth keeping in mind before assuming that documentation, issues or a bug you found belong to the project you are looking at.

Editorial conclusion

The synchronisation idea is sound and narrow: rooms, a playhead, a play state, and nothing else. What to check before running it is the server side, because the docs draw exactly one boundary (no file sharing) and say nothing about accounts, passwords or who may join a room, while TLS support arrives as three Python packages with no documented key. On the build side, read Makefile, GNUmakefile and setup.py first: the version is imported from the package, the dependency list is two files concatenated, and the license header at the top of the README disagrees with the license section twenty lines below it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Syncplay/syncplay on GitHub