Multi-Client (Multi-PC) Setup

Exaplay 3 supports multi-client deployments where one master PC coordinates playback and content across multiple client PCs connected on the same network. This enables large-scale projection setups, multi-screen installations, and distributed show control.

Quick Setup — Step by Step

This is the fastest path from "several PCs" to "one synchronised show". Each step links to the detailed reference further down.

1. Connect the machines. Put every PC on the same network subnet and start Exaplay on each. On the master, make sure the NETWORK tab is visible — enable Multi-Client Mode in Settings → Communication if it is not. Open the required network ports in Windows Firewall on every machine.
2. Find the clients. On the master, open the NETWORK tab. Remote instances appear automatically under Systems within a few seconds (auto-discovery). Click refresh if one is missing.
3. Make a machine a client. Select a remote system and toggle the Role checkbox to mark it as a client. Give it a friendly Name so it is easy to identify (Client Mode, Display Name). The client's own UI shows a Client Mode — Read Only banner.
4. Assign the displays. In OUTPUTS → Screens & Fields, assign each client's monitors to screens just like local outputs. For a panorama spanning two PCs, assign displays from different machines to one screen (cross-machine panorama). Do this before copying files so Smart Sync knows what each client needs.
5. Copy the project and media. Click Copy Files in the NETWORK tab. The master pushes the .vpp and the required media to every client and each client loads the project automatically (file synchronisation). Enable Smart Sync to send each client only the media its screens actually use.
6. Turn on Playback Sync. Toggle Playback Sync in the NETWORK tab so Play / Pause / Stop / Seek, composition switches, and cues are broadcast to all clients with frame-accurate latency compensation. Use the per-client checkboxes to include or exclude targets.
7. Verify. Each system card shows a sync-quality and health badge. Confirm every client reads 🟢 in-sync. After project changes, push again with Copy Files or reload everyone with Restart All.

Roles in one line: the master is the PC the operator works on; a client is a read-only PC that renders the master's content on its own displays. The rest of this page documents each step in detail.

Roles

Role	Description
Master	The PC running the main Exaplay UI where the operator works. Controls playback, assigns screens to remote displays, and pushes content.
Client	A remote PC also running Exaplay. Receives playback sync commands and renders content on its local displays. Designated via the Client Mode setting.

Client Mode

An Exaplay instance can be designated as a client by enabling Client Mode. This can be done in two ways:

1. From the client's own Settings: Settings → System → Client Mode
2. From the master's Network tab: Select the remote system in the NETWORK tab, then toggle the Role checkbox in the inspector panel.

When client mode is enabled:

• The instance is marked as a "client" in the master's NETWORK tab (green badge).
• The master's Copy Files operation automatically transfers the .vpp project file and all sync folder media to this client.
• After file transfer, the master triggers project.load so the client automatically loads the master's project.
• The client does not need to maintain its own .vpp file — it receives everything from the master.
• The local UI shows a Client Mode — Read Only banner so operators can see immediately that the machine is following a master system.
• Editing actions such as saving, timeline changes, output editing, and other project-authoring tools are disabled on the client.

If you need to break a machine out of client mode on-site, use Return to Standalone from the read-only banner or turn off Client Mode in Settings → System.

Display Name

Each remote system can be given a custom display name for easier identification:

1. From the client's own Settings: Settings → System → Display Name
2. From the master's Network tab: Select the remote system, then type a name in the Name field in the inspector panel.

The display name is stored on the remote system's configuration and persists across sessions. When set, it replaces the OS hostname in system cards and the inspector title.

The master's NETWORK tab also shows a sync status summary on each system card:

• ✓ synced — all files were transferred successfully
• ⟳ copying… — transfer is in progress
• ⚠ partial — some files transferred, some failed
• ✗ failed — all transfers failed

Getting Started

1. Start Exaplay on all PCs. Ensure they are on the same network.
2. On the master PC, enable Multi-Client Mode in Settings → Communication if the NETWORK tab is not already visible.
3. Remote instances appear automatically under Systems (auto-discovery).
4. Select a remote system and toggle the Role checkbox to designate it as a client. Optionally set a Name for easy identification.
5. Click Copy Files to transfer media and the project to all clients.
6. Configure playback sync as described below.

Step 1: Remote Display Discovery

The master PC automatically discovers all remote Exaplay instances on the network. Their displays appear in the OUTPUTS tab alongside local outputs:

• Sidebar: Remote outputs are grouped by host under a "Remote Outputs" section.
• Layout Map: Remote displays appear with a dashed purple border and a "remote" badge.
• Screen Assignment: Remote displays can be assigned to screens just like local ones.

Discovery happens automatically over the local network; remotes appear within a few seconds of being powered on.

Step 2: Remote Display Assignment

In the OUTPUTS → Screens & Fields section, displays — local or remote — can be assigned to screens the same way. Each engine manages its own displays in the background while the master UI presents a unified view.

A display can be bound either to a specific output on a remote machine, or to the machine itself by position + size (the Machine (use position + size) option in the Bind to… drop-down). Machine binding is handy when you want to place a render region on a client without pinning it to a particular monitor. See Output Setup → Displays.

Cross-machine panorama

Assign displays from different machines to one screen and Exaplay composites them into a single continuous surface — for example a panorama driven by two PCs. Each display's Position is a coordinate on its own machine's desktop; across machines the displays are arranged automatically left → right by machine (master first, then each client), so a master display and a client display read as one wide screen with playback kept in sync. In the Outputs overview each machine appears in its own host-labelled lane. See Output Setup → Coordinates are per-machine.

Step 3: Playback Synchronisation

Enable Playback Sync in the NETWORK tab to broadcast transport commands to all connected clients:

Command	Description
Play	All sync targets start playback
Pause	All sync targets pause
Stop	All sync targets stop
Seek	All sync targets jump to the specified time position

Configuration

• Enable/Disable: Toggle the "Playback Sync" button in the Network tab.
• Target Selection: Use the per-client checkboxes to include or exclude specific clients from sync.
• Sync settings persist across sessions automatically.

Frame-Accurate Sync

With Playback Sync on, the master continuously measures network latency to each client and compensates for it when starting playback. Each sync target in the NETWORK tab shows a quality badge:

Quality	Indicator
in-sync — within one frame	🟢 ●
soft-drift — a few frames behind	🟡 ◐
hard-drift — noticeable lag	🟠 ○
lost — client unreachable	🔴 ✗

Composition and Cue Sync

When the master switches composition or triggers a cue in a Playlist, the change is broadcast to all sync targets automatically so they follow along.

Version Mismatch Detection

The NETWORK tab automatically detects when client PCs are running a different version of Exaplay than the master. Version mismatches are shown with coloured badges:

Severity	Meaning	Badge
Major	Different major version (e.g. v3.x vs v2.x) — may be incompatible	🔴 ⚠ version
Minor	Different minor version (e.g. v3.2 vs v3.1) — features may differ	🟡 ⚠ version
Patch	Same major.minor, different patch — safe	🟢 (no warning)

Version mismatch badges appear on both system cards and in the inspector panel's Version field.

Remote Health Monitoring

The master periodically polls each online remote for performance data (FPS). Health is classified and shown on system cards:

Status	Criteria	Indicator
Healthy	FPS ≥ 90% of target (22.5+ at 25 fps)	🟢 ● 25 fps
Degraded	FPS 50–90% of target	🟡 ◐ 18 fps
Critical	FPS < 50% of target	🔴 ✗ 8 fps

The inspector panel shows FPS and status label when a remote is selected.

Restart All Clients

The Restart All button in the Active Sync banner reloads the project on every online client. Use it after making changes to the project on the master. Only client-mode systems are affected; standalone remotes are left alone.

Exaplay Service Integration

Every Exaplay machine also runs the Exaplay Service (the tray watchdog, reachable on the engine port + 1, e.g. 8124 for the default 8123). The NETWORK tab talks to it directly:

• svc badge — each system card shows whether the machine's service is reachable (green svc) or not, probed on every discovery cycle via the service's /info WebSocket.
• Open Service UI — the wrench button on each card opens that machine's service web UI (watchdog status, start/restart/stop, service log) in a new tab.
• Start Exaplay — when a machine's engine is offline but its service is still reachable, a ▶ Start button appears on the card. It sends exaplay:start to the service's /wdog endpoint, which launches exaplay3.exe on that machine.
• Remembered machines — the engine's discovery beacon forgets a peer ~30 s after it goes silent, which is exactly when you need its card to start it again. The NETWORK tab therefore remembers every machine it has seen (per browser, in localStorage) and keeps showing it as Offline. Use the ✕ button on an offline card to forget a machine that is gone for good.

For this to work the service port (engine port + 1, default 8124) must be allowed through the firewall on all machines.

Fleet Software Updates

The Software Updates panel at the bottom of the NETWORK tab updates every machine in the fleet from the master — no walking from PC to PC with a USB stick.

Staging (the verified place). Copy the release installer (Exaplay3_<version>.exe) into the master's update folder — Documents\Exaplay3\update\ (the panel shows the exact path). The master's Exaplay Service scans that folder and verifies the file before anything happens:

1. It must match the Exaplay3_*.exe naming pattern and carry a version resource.
2. Its Authenticode signature must be valid and issued to VIOSO GmbH. Unsigned installers are refused — unless Test Mode is enabled (below).
3. Its SHA-256 is computed and becomes the integrity anchor for every transfer.

Updating. Rollouts are orchestrated by the master's Exaplay Service, not the browser: the panel submits the job (per machine, or Update all clients) and only renders live status from the master. You can close the tab, reload, or watch from a different laptop — the rollout keeps running; a Cancel rollout button stops it after the machine currently updating. The master walks the fleet strictly one machine at a time: each machine's service downloads the installer from the master and verifies it again — hash must match the master's staged file, plus the same signature and version checks. Only then is it executed: the service hands off to a detached bootstrap, quits (stopping the engine on the way out), the installer runs silently preserving projects and settings, and the service restarts. A machine only counts as updated after its service was seen down and came back reporting the target version. Rollout status is persisted on the master — if the master's service restarts mid-rollout, the panel reports the rollout as interrupted instead of losing it.

Update the master last. Updating the master takes down the engine serving this UI — the panel warns and you reload the page once the machine is back.

Test Mode — unsigned on-site builds. When you stage an unsigned test installer, the panel offers Enable Test Mode: one click sets the update.allow-unsigned flag on the master only (through its engine, which is always up — it serves the hub page). Clients never need the flag: while Test Mode is on, each transfer the hub starts carries a per-transfer approval in the fetch request, so machines whose engine is down — the typical update-me case — are covered too, and nothing persistent is left scattered across the fleet after testing. Transfers stay SHA-256-verified against the master's staged file — only the publisher-signature requirement is waived. While Test Mode is on, the panel shows a persistent amber "test mode: unsigned allowed" badge; hit Require signatures after testing.

Notes:

• The service runs as the logged-in user; the installer requires admin rights. Each machine reports its install readiness to the hub before you start: rows show nothing when the install can run fully unattended (service elevated, or admin with UAC off), ⚠ UAC prompt on machine when the installer will pop a consent dialog on that machine's own screen (the update waits there until someone confirms), or ✗ needs admin rights when the logged-in user is not an administrator and a silent install will fail. Fix the flagged machines (auto-login an admin account, relax UAC, or run the service elevated) before a big rollout.
• After the update, the engine autostarts where show-mode is configured; otherwise use the card's ▶ Start button.
• The update endpoints (/update/info, /update/fetch, /update/run) live on the service port (engine port + 1).

Auto-Restore of Restarted Clients

When a client PC is restarted (or powered on later than the rest of the rig), it comes back with its previous configuration automatically — no manual Copy Files or display re-assignment needed. Two layers make this work:

1. Engine self-heal (fully autonomous — no UI required anywhere). A client-mode engine autoloads the show it last received on cold boot and, right after any project load, applies its own saved screen assignments from the remote-output-lists stored inside that project file (keyed by the machine's stable identity, hostname + port). A rebooted client therefore restores its displays by itself, even when no browser is open on any machine.

2. Master-side watcher (runs app-wide in the master UI). While the master UI is open — in any tab, not just NETWORK — it watches discovery for clients transitioning offline→online:

1. It waits a few seconds for discovery to stabilise, then checks whether the client already has a project loaded. A client that only had a short network dropout (or that just self-healed via layer 1) is left untouched.
2. A client that came back empty gets a project.load of the show it last received via Copy Files, its saved screen/display assignments re-applied, show mode re-enabled (when auto show mode is on), and the master's current transport state, so it joins the running show immediately.

The watcher is controlled by the Auto-Restore checkbox in the File Sync banner (default: on). A per-client cooldown prevents a flapping network link from re-triggering project loads in a loop. Media files are not re-copied automatically — they are still on the client's disk; a freshly set-up machine still needs one manual Copy Files. Only client-mode systems are restored; standalone remotes are never touched.

Step 4: File Synchronisation (Active Sync)

The NETWORK tab provides two file sync modes:

Manual Copy

Click Copy Files to transfer the sync folder and current project to every online client. Per-file progress bars show transfer status, large files are chunked and retried automatically if the network hiccups, and each client loads the new project automatically once the transfer completes.

Note: Client PCs receive the project from the master during Copy Files and load it automatically. They do not need their own .vpp file.

Smart Sync

By default Copy Files sends every media file to every client. In large installations most clients only drive a few screens and never play most of the media, so this wastes bandwidth and disk.

Enable Smart Sync (checkbox under the Sync Folder field) to copy each client only the media its assigned screens actually render:

• The master resolves which screen each clip outputs to (via its composition's screen field) and intersects that with each client's screen assignments (the output-list owner / split-cell owners).
• Clips reached only through a playlist or a cue/action still travel with the screen they play on, so nothing a client needs is left behind.
• Small assets that aren't screen-specific — VIOSO calibration (.vwf) files and panel/background images — are always copied to every client.
• Safe fallback: if a client's screen assignments can't be determined, or the master can't compute the screen→media map, that client receives the full set of files — Smart Sync never under-copies.

Tip: Assign each client's displays to their screens before running Copy Files so Smart Sync knows what each client needs. With Smart Sync off, behaviour is unchanged (all files to all clients).

Active Sync (Auto)

Enable Auto to automatically push sync folder metadata every 10 seconds:

• The master sends the folder path, file list, and timestamp to each remote.
• Remotes can use this information to stay in sync with the master's content.
• Status indicators show "✓ N files" or "✗ error" per remote.

Sync Folder

Configure the sync folder path in the text input. The default is $[exaplay]/sync.

Network Requirements

Port	Purpose
8123	Engine and file transfer
8124	Exaplay Service (watchdog) — always engine port + 1
3001	Effects controls
45454	Auto-discovery between Exaplay instances

Ensure Windows Firewall allows all these ports on all machines. See Firewall Configuration for details.

Troubleshooting

Remote not appearing in Systems list

• Verify both PCs are on the same network subnet.
• Check that the Exaplay Engine is running on the remote PC.
• Ensure UDP port 45454 is not blocked by firewall — this is required for auto-discovery.
• Ensure TCP port 8123 is not blocked by firewall — this is required for HTTP communication.
• Verify that broadcast packets are not blocked by your network switch or router (some managed switches disable UDP broadcast by default).
• Click the refresh button in the Systems panel.

Playback sync commands not received

• Verify the remote shows as "UP" in the Systems panel.
• Check that Playback Sync is enabled (toggle button shows "On").
• Ensure the target client's checkbox is checked.

File copy fails

• Verify the sync folder exists on the master PC.
• Check that the remote engine's WebSocket port (8123) is accessible.
• Monitor the per-file progress bars for error indicators (✗).