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, enable Multi-Client Mode in Settings → Communication — the toggle asks for an access code (multi-client is an early-access feature; contact VIOSO if you don't have one). This unlocks the fleet panels in the NETWORK tab; while the switch is off, the NETWORK tab says so and offers an Open Settings → Communication button that lands on the switch. 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 set its Role selector to client (a confirmation dialog explains the consequences). 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 the STAGE tab, 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, which then hold a common playhead. Pick a client and use Follows master in the inspector to include or exclude it. (Playback Sync also enables itself when the first client comes online, unless you have explicitly switched it off.)
7. Verify. Each system card shows a sync-quality and health badge. Confirm every client reads 🟢 in-sync. From here on the fleet keeps itself current — value changes apply live and structural changes go out when you save the show (Clients keep themselves up to date); Copy Files is only needed for a deliberate full push.

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 its Role in the master's NETWORK tab.

Client Mode

An Exaplay instance is designated as a client from the master's NETWORK tab: select the remote system, then set the Role selector in the inspector panel to client (the same selector also offers standalone and master; a confirmation dialog appears because changing a role is disruptive mid-show). There is no role setting inside the client's own Settings dialog.

A client needs a master. If you pick client for a machine while the machine you are working on is still standalone and no other machine on the network is the master, the confirmation offers to make this machine the master and pair the client in one step. If another machine already is the master, assign roles from that machine's interface instead — a second master is never offered. The NETWORK tab also warns when client-role machines exist without any master (those machines stay dark) and offers Make this machine the master right there.

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. The banner also says which master it follows (following MASTER-PC), or no master found on this network when nothing drives it — a client renders only what a master sends, so a client without a master stays dark until one is assigned or the machine is returned to standalone.
• The header's Sync button is not shown on a client — pushing the show is the master's job.
• Editing actions such as saving, timeline changes, output editing, and other project-authoring tools are disabled on the client.

If you need to work on a client on-site without pulling it out of the fleet, use Unlock GUI from the read-only banner (a confirmation dialog appears). The interface becomes usable while the machine stays a client: the master keeps managing it, so changes made locally can be overwritten by the master's next sync, and the lock returns automatically on reload. The banner collapses to a small pill at the bottom of the screen with a Lock GUI action to re-lock at any time.

If you need to break a machine out of client mode entirely, use Return to Standalone from the same banner (a confirmation dialog appears — this pulls the machine out of the fleet), or change its Role from the master's NETWORK tab.

Display Name

Each remote system can be given a custom display name for easier identification: on 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

How the NETWORK tab is laid out

Three columns, left to right: your machines, the rig, the selected machine.

The left rail lists every machine Exaplay can see, one row each: a status dot, the name with its role, and one line saying how it is — this machine · master, in sync, behind, copying…, offline. That line is the whole point of the rail: you can tell at a glance whether the rig is healthy without opening anything. Click a row to select the machine.

The middle column holds everything that belongs to the whole rig — the setup note, Sync Health, File Sync, Software Updates, Playback Sync. The toolbar above it carries the machine count, how many are online, and the Edit / Play switch.

The right column is the inspector for whichever machine is selected. What it shows first is what you read to answer is this machine all right — its name and role, client status, and whether it follows the master for playback. Everything you set once when a machine is commissioned — storage, GPU, PIN, host and network, displays, the VIOSO Platform pairing — is behind Machine setup, one click away. Collapse the whole column with the chevron at its bottom; the vertical Show Inspector strip brings it back, and the state is remembered.

Explanations are on demand throughout the tab: where a line is short and the cursor turns into a question mark, hovering it gives you the full detail — what a warning means, what a setting does, what a sync will and will not move.

The rig-wide panels still list every machine, and clicking a machine there — in Playback Sync or in Sync Health — selects it, so its own settings are always one click away.

Site Setup

Selecting a machine in the NETWORK tab fills the inspector on the right with everything about that machine, as one list of sections. The setup-time ones — Site Setup — are the sections a PIN can lock, and they cover:

Host & Network

Rename the machine's Windows computer name and manage its network adapters (static IP, mask, gateway, DNS) directly from the NETWORK tab, without needing physical or remote-desktop access to that PC. Requires the Exaplay Service to be reachable on the target machine.

Windows Displays

Lists the machine's attached desktop displays with their resolution, refresh rate, and orientation. Change display mode or orientation directly from the panel; a scale badge flags displays not running at 100% Windows scaling (change that in Windows Display Settings — Exaplay only reports it).

VIOSO Cloud Platform

Connect this machine to the VIOSO Cloud Platform (site name, pairing code, connection status) directly from Site Setup — see VIOSO Cloud for what the Platform connection itself provides.

PIN Lock

Protects a system's own Exaplay UI and its Site Setup fields behind a PIN, so a shared or publicly-reachable machine can't be reconfigured by anyone who opens its browser tab.

• Setting a PIN: In Site Setup → PIN Lock, toggle Lock with PIN on and enter a PIN of up to 8 letters/digits. Save it — the lock takes effect immediately for that system. The same lock can also be set on any machine locally — including standalone systems that never open the NETWORK tab — under Settings → Interface → Protect interface with PIN.
• What it locks: With the PIN set, the system's Exaplay UI shows a full-screen lock prompt on load, and (independently) the Host & Network, Windows Displays, and VIOSO Cloud Platform sections in Site Setup stay disabled until the PIN is entered in the PIN Lock section itself.
• Unlocking: Enter the PIN once per browser session — a red banner in the PIN Lock section explains that Site Setup stays disabled until you do. Unlocking is per-tab/session and does not persist across a page reload.
• Changing or removing it: Once unlocked, use Change PIN to set a new one, or turn Lock with PIN off to remove it — no PIN is required to turn the lock off from an already-unlocked session.
• Scope: The PIN is per-system — each machine in the fleet has its own independent PIN (or none). It is not related to the User Panel PIN, which protects individual operator control panels and is unaffected by this setting.

Note: The PIN is checked by the browser against the value stored in that system's own configuration file — it deters casual access but is not a strong access-control mechanism (there is no server-side login). Don't reuse a sensitive password as an Exaplay PIN.

Locked out? If a PIN is lost or forgotten, see Resetting a Forgotten PIN below.

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 (early-access — the toggle asks for an access code) to unlock the fleet panels in the NETWORK tab.
3. Remote instances appear automatically under Systems (auto-discovery).
4. Select a remote system and set its Role selector to 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 outputs appear in the STAGE tab alongside local outputs:

• Mapping to outputs tab (the panel under the canvas): remote outputs are listed by host name, after this machine's own outputs.
• The canvas (on the Mapping to outputs tab): remote outputs carry their machine's name as a badge (amber and dimmed when the machine is offline) and are otherwise drawn exactly like local ones — the map is one picture of the whole rig, not two.
• Screen Assignment: Remote outputs can be assigned to screens just like local ones.

The map's outline tells you what an output will do, whichever machine it is on:

Outline	Meaning
Solid, tinted in the screen's colour	Assigned to that screen — it will show content
Dashed and grey	Not assigned to any screen — it will stay dark
Dashed and dimmed, amber badge	The machine is offline (its assignment is still stored)

Each screen also draws a coloured frame around the outputs it owns, so a panorama split across several machines reads as one surface.

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

Offline machines stay in the project

Every machine's outputs — including their screen assignments — are saved inside the project file whenever the output configuration is saved. When a client can no longer be reached (powered off, network unplugged, or the project was opened while the machine is down), its outputs do not disappear: the machine stays on the Mapping to outputs tab, marked OFFLINE, with its full output set restored from the project. You always see how many projectors the show was designed for.

Offline outputs remain assignable: toggling a screen assignment on an offline output is stored in the project and applied automatically the moment the machine reconnects (via the client's own self-heal on boot and the master's auto-restore — see Auto-Restore of Restarted Clients). This also means a show can be pre-programmed before all render nodes are physically present.

A machine that is gone for good can be removed with the ✕ button on its offline host label on the Mapping to outputs tab — this deletes the machine's saved outputs and assignments from the project (after confirmation). If the machine later reappears on the network it is re-discovered as a fresh client, but its screen assignments must be made again.

Step 2: Remote Output Assignment

In the STAGE tab, outputs — local or remote — can be assigned to screens the same way. Each engine manages its own outputs in the background while the master UI presents a unified view.

Remote outputs are the client's detected monitors and NDI streams; they are assigned to screens exactly like local ones, and their place on the show canvas is arranged on the Stage (see Output Setup → Cross-machine panorama).

Cross-machine panorama

Assign outputs from different machines to one screen and Exaplay composites them into a single continuous surface — for example a panorama driven by two PCs. Each output's Desktop position is a coordinate on its own machine's desktop; across machines the outputs are arranged automatically left → right by machine (master first, then each client), so a master output and a client output read as one wide screen with playback kept in sync. On the Stage's Mapping to outputs tab the machines appear edge-to-edge, exactly as they will render — what you see is the real canvas, with no artificial spacing between local and remote outputs. See Output Setup → Coordinates are per-machine.

To change the order, drag the output boxes on the Stage's Mapping to outputs tab (on the master — the ? button in the Stage header lists the gestures; a single machine lays out its own outputs the same way). It works like Windows display settings: drag any output — local or on a client — left / right / above / below the others; edges snap together so the layout stays gap-free. Dropping saves immediately: the layout is stored in the project file the moment you release; there is no Apply button. By itself a drag only arranges the picture — every screen keeps laying its outputs out automatically (master first, then each client). To make a screen render from the layout you arranged, so a client output can sit left of or above the master's, set that screen's Canvas layout to Custom in its inspector (the header's Layout: chip jumps there): its content offsets are then computed from the arrangement and pushed to every reachable engine. Reset view… in the Stage's header puts the boxes of automatic screens back to the automatic order and leaves a custom screen's layout alone; set that screen back to Automatic to unmap it. Offline machines can be arranged too — their layout is applied automatically when they reconnect. Outputs excluded from the show (Include in show off) don't appear on the canvas, and split outputs drag as one whole-monitor box.

During a show: on a screen with a Custom canvas layout a drop applies and pushes straight away, so a stray drag on the Mapping to outputs tab moves projectors live. Stay off the Stage tab while the show is running.

This works the same for screens built entirely from remote outputs (no master output involved): the clients' outputs are laid out left → right by machine and the screen's size is the combined canvas. To deliberately show the same content on several machines instead (a mirror), drag the machines' boxes on top of each other on the Mapping to outputs tab so they share the same position.

VIOSO calibration across machines

A screen's VIOSO calibration (.vwf) works on a cross-machine screen too: the file is copied to every client automatically (see File Synchronisation below), and each machine renders only the calibration channels that belong to it.

Both ways of producing the calibration work, and Exaplay picks the right handling automatically.

One calibration per machine (VIOSO network calibration — show_DC-1.vwf, show_DC-2.vwf, …). VIOSO records each machine's hostname in the channels it captured there, so every machine picks exactly its own channels and places them at their real desktop positions — the same way a calibration behaves on a single machine. Channel order in the file does not matter, the machines may have different numbers of projectors (say five on one and six on the other), and projectors stacked in rows rather than one long line still land correctly. The files are handled as one calibration and all of them are copied to every machine.

One big calibration covering every projector. A single calibration captured across the whole canvas stores one shared coordinate space, and every machine gets the slice that matches its position in the machine arrangement. This is the long-standing behaviour and is unchanged — make sure the channel order in the calibration matches the left → right order of your machines.

Exaplay tells the two apart by whether the calibration names more than one machine, so you do not have to configure anything. The Identity Mapping switch in a screen's Projection Calibration group (on by default) only exists to force the older handling; leave it on.

Renamed machines. The hostname stored in a calibration is the machine's name at calibration time. Rename a render node afterwards and its per-machine calibration no longer matches, so the rig quietly drops back to the order-based layout. If you rename machines, re-run the calibration — or make sure the channel order still matches the machine order.

Which rule is in use is reported per screen in the VIOSO panel (the screen's Projection Calibration → VIOSO…) and next to the Calibration channel picker in the output editor: identity (hostname match — the normal case), packed (fallback order-based layout), explicit (manual pinning), absolute or desktop. Check this first if a projector shows the wrong part of the image. The panel also lists every output of the screen — the master's and each client's — with the channel it renders, read back from the engine that draws it: a client places its own channels, so its rows come from the client, not from the master's guess.

Manual pinning — Calibration channel. When the automatic handling puts the wrong slice on a projector, say which channel that output renders instead of trying to make the inference agree. Select the output on the STAGE tab (the Mapping to outputs tab of the panel under the canvas lists this machine's outputs and every remote machine's) and pick a channel under Calibration channel, in the inspector's More settings fold — or use the Outputs of this screen list in the screen's VIOSO panel, which shows the same picker next to the channel each output actually renders; the list shows the channels of the calibration loaded on that output's screen, by their number in the file (#0 is the first), name and the machine that captured them. The control only appears for outputs whose screen actually has a .vwf.

Automatic is the default and means "work it out" (identity mapping, or the order-based fallback). You normally only pin one output: the screen's other outputs take the channels nobody pinned, in list order — so on a two-projector screen naming the odd one out is enough. Pinning applies immediately, with no reload, and switching an output back to Automatic releases it.

The pin is stored in the project, per output, and is re-applied to a client automatically after a reboot, a project load or a Copy Files — it does not have to be set again on the machine itself. This is also the tool for rigs no automatic rule can infer, such as dome stacks where every projector covers the whole canvas: there, pin every output.

Split displays. A monitor split into cells is one graphics output feeding several projectors through a splitter — Windows still sees one monitor, so each cell is its own projector and gets its own channel. A client's output is split from the master: select it on the STAGE tab and set Columns × Rows under Splitting, in the properties panel's essentials, exactly like a local output (the client's own UI still works too). The grid is pushed to the client at once, stored in the project and re-applied by the client itself after a reboot or a project load. A small selector appears in each cell of the split preview, for local outputs and for a client's, and the pins are stored and restored per cell like any other.

Exaplay also reads the split information VIOSO writes into the calibration itself. In a split calibration every channel records the parent display's desktop position, with its real place given as a cell index in the split grid; Exaplay resolves that, so the channels of a split display are placed by position like any other calibration instead of falling back to their order in the file. Channels resolved this way are marked split cell in the channel list, which is the quickest way to confirm on site that the split was recognised.

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. Playback Sync also enables itself automatically when the first client-role machine comes online — unless you explicitly switched it off, which is always respected.
• Target Selection: Pick the machine — on its card, in the Playback Sync list or in Sync Health — and use Follows master in the inspector on the right to include or exclude it. The Playback Sync list says included / excluded for every online remote at a glance; the control itself lives with that machine's other settings, so there is only ever one of it.
• Sync settings persist per browser (they are stored in the browser you operate from, not on the master engine) — opening the master UI from a different laptop starts with that browser's own settings.

Playback Sync Quality

With Playback Sync on, the master streams its playhead to every client continuously and each client corrects itself whenever it drifts further than the tolerance (80 ms by default). Each sync target in the NETWORK tab shows a quality badge based on the measured difference:

Quality	Measured difference	Indicator
in-sync	within 40 ms	🟢 ●
soft-drift	up to 120 ms	🟡 ◐
hard-drift	up to 1 s	🟠 ○
lost	client unreachable	🔴 ✗

What this is and isn't. Machines are kept to a common playhead, not frame-locked: each machine presents on its own vsync phase. The playhead itself is held far tighter than the badge thresholds suggest: the master stamps each playhead sample with its age, so a client compares the two playheads at the same instant rather than as two readings that are each up to one frame old, and holds the difference to about a millisecond (older masters or clients fall back to the previous, frame-averaged loop, which holds to a few milliseconds). What remains is each machine's own vsync phase. That is right for a panorama or a multi-room installation; content that depends on exact frame coincidence across machines (e.g. active stereo) needs the sync hardware described in Frame lock and sync hardware or the timecode master/slave path.

A drift correction is a real seek, so a client that keeps crossing the tolerance will show small audio gaps. If you see that, the network is the thing to fix.

Frame lock and sync hardware

Playback Sync aligns the playhead — which source frame each machine shows. Aligning the scanout — the instant each output actually presents that frame — is a hardware property, and the rigs Exaplay ships on come in two kinds:

Server	Sync hardware	What a fleet of them can do
Four-output server (one GPU, no sync card)	none	The four outputs of one machine share one vblank, so a single box is frame-coincident on its own. Across machines only the playhead is aligned; the machines' outputs cannot be frame-locked to each other.
Eight-output server (two GPUs with a sync card, e.g. RTX PRO Sync / Quadro Sync)	swap barriers, house sync	The card genlocks every output of the box at driver level. Across machines the hardware can frame-lock — this is the tier a swap barrier is for. Combine the outputs of both GPUs with NVIDIA Mosaic; without Mosaic the second GPU's outputs sit outside anything the engine could lock.

Which tier a machine is in is reported by the engine itself: open System Information (burger menu) and read the Output Sync section. It names the graphics card, whether the driver exposes the swap-group extension, the number of swap groups and swap barriers the driver reports (barriers above zero mean a sync card is present), the output/monitor topology (and whether it is a Mosaic surface), and what the engine currently does with it. The same facts are in /cmd?req=diagnostics under system.output_sync.swap_group, with tier = single-box / sync-card / none / unknown.

Today the engine does not yet join a swap group — the report is the measurement, taken so that a mixed fleet can be planned honestly: an eight-output node waiting in a barrier that a four-output node can never enter would stall, so any future barrier is per-machine opt-in and only on machines whose report shows barriers. Until then every tier is playhead-locked as described above.

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.

Show Mode follows the master

Show Mode is the switch that decides whether the output windows show anything at all, so on a multi-PC rig it belongs to the show, not to one machine. Switching it on the master switches it on every client, and switching it off blacks the whole rig out — whichever way you do it:

• the Show Mode button in the header,
• Start presentation / End presentation in the SHOW view,
• a Show Mode item on a User Panel or a customer-built web page,
• system.showmode=on|off over TCP/UDP, /global/showmode over OSC,
• a cue with Show Mode on in its play action.

The last two are handled by the master engine itself, so an unattended rig driven by a show controller needs no browser open anywhere. Clients only follow their master: a client that receives the switch applies it and never sends it on, and a standalone machine never touches the network.

Set the roles first — a machine still set to standalone is not part of any fleet and is neither commanded nor commanding. Excluding a client from Playback Sync in the NETWORK tab keeps the master's browser from writing to it, but the master engine's own fan-out still reaches every online client of the fleet — exactly like the playhead stream. A rig whose clients must run their outputs independently switches the fan-out off on the master with sync.showmode-fanout = false in its Communication config.

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 Clients button in the File Sync panel 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).

Leave an updating machine alone. While a machine installs, its Exaplay is down and the panel row reads installing, restarts itself… — that is a status, not a request. Do not start Exaplay on that machine: the installer replaces several hundred megabytes of files over ~20 seconds, and a process that starts meanwhile locks one of them. The installer then refuses that single file and rolls the whole update back, so the machine comes back on its old version. The master now clears Exaplay and its helper processes before each attempt, lets the installer force-close anything else holding a file, and retries the install once by itself — but a hand-started Exaplay mid-install is still the surest way to lose an update.

If a machine comes back on its OLD version. The bootstrap on that machine ran (the service went down, the engine with it) but the installer did not apply. The master notices within about 20 seconds of the service reappearing — the restarted service carries a new process id, so a reappearance is never inferred from a lost poll — and fails the machine with the verdict of that machine's own Documents\Exaplay3\update\install.log: 'X' was locked by another process means the case above (the log names the file the installer gave up on, and the failed attempt is kept as install-attempt1.log beside it); no fresh install.log means the bootstrap never reached the installer (the service was not started by the logged-in user, or cmd.exe is not on its PATH); needs a Windows restart means files were in use and Windows wants a reboot to finish; a quoted installer log: line is the installer's own error (typically an elevation refusal — see the readiness notes above). Fix the cause and press Update on that machine again. There are no files to delete: the staged installer stays in the update folder on purpose, and the next attempt re-verifies it.

"a rollout is already running" means exactly that: the master's service is still walking a rollout — usually the previous machine in its come-back wait — and the message names the machine and its phase. The panel adopts that rollout when it sees the message (it shows the machine rows and a Cancel rollout button), so wait for it to finish or cancel it; nothing on disk needs cleaning up. Before this the master waited its full 10-minute deadline for a machine whose install had silently not applied, and every press meanwhile answered this error with nothing naming the machine.

Quick Sync — putting a test build on the fleet

Between two test builds nothing changes except the binaries, so cutting a signed installer just to try something out is a great deal of work for no benefit. Quick sync copies the master's own exaplay3.exe, exaplay3-service.exe and html\ onto every client and restarts it — no installer, no release build. Update the master however you normally do, then press one button.

It sits in the Software Updates panel and appears only while Test Mode is on, because it ships unsigned binaries. Everything else about it is the ordinary rollout: the master builds one package, each machine downloads it from the master and verifies its SHA-256 before anything is copied, and the master's service walks the fleet one machine at a time while the panel only renders status — closing the tab does not interrupt it.

What it does, and what it does not. A quick sync makes those files identical to the master's. That is the whole promise:

• It does not touch DLLs, redists, the registry, the uninstall entry or the version in Add/Remove Programs. A build whose dependencies moved needs also send DLLs ticked; a build that needs a new redist or a registry change needs the installer.
• It still needs admin rights on every machine, exactly like the installer — the files live under Program Files. The same readiness flags apply (⚠ UAC prompt on machine, ✗ needs admin rights).
• It is for testing. Ship real versions with the installer.

The DLL check runs before you press. Every machine reports a digest of its own DLLs\ folder, and the panel names the ones that differ from the master's: with also send DLLs off it says a quick sync cannot make those machines match, with it on it says they will. A machine whose service is too old to report the digest is listed as could not compare rather than assumed either way — it is still synced.

A failed copy puts the machine back. Before copying, each machine backs up exactly the files the package replaces; if the copy fails it restores them and comes back on the binaries it was running. The row then names the reason from that machine's own Documents\Exaplay3\update\quick\quick.log: rolled back, the copy was denied (admin rights), a file was still locked (something started Exaplay mid-copy), or neither tar.exe nor Expand-Archive unpacked the package.

How a machine counts as done. Not by its version — testers rebuild the same version all day, so a version match would call a machine on which nothing was copied "synced". The bootstrap stamps the package's own SHA-256 on the machine after a successful copy, and the master waits for that.

Leave a syncing machine alone, same as for an installer rollout: starting Exaplay on it locks the very files being replaced.

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.

Powering On the Whole Rig (Autostart)

Set the show to start automatically on the master — the rocket button in the SHOW view, or Startup in System config (Autoplay at Startup + startup project, composition, cue and delay) — and the clients follow it. Switch the rig on and every machine comes up in the same show, in show mode, playing the same composition from the same cue. No browser has to be open anywhere.

What the master pushes to each online client (persisted in the client's own config, so it applies at the client's next boot):

Setting	On the client
Autoplay at Startup	mirrored from the master
Startup composition / cue / delay	mirrored from the master
Startup project	the same show inside the client's own sync folder — the master's own path (C:\Shows\opening.vpp) does not exist on a client, so it is translated to $[sync]/opening.vpp, exactly where Copy Files puts it
UI startup mode / frameless	mirrored from the master (see below)

Nothing is started or relaunched when the settings are pushed — a push during a running show never opens a window or starts playback on a render node.

Reconciliation happens whenever the master saves its settings, runs Copy Files or a project push, changes the autoload show, or automatically re-integrates a reconnected client. A client already in agreement is not written to at all.

Important: the client must have the show. The autostart points each client at its own sync-folder copy, so run Copy Files after choosing the autoload show. If that file is missing, the client falls back to the last show it received from the master and still starts playing, rather than coming up dark.

Per-client opt-out. A machine that must keep its own startup behaviour — a render node that should stay headless, or a box pointed at a different show — turns Follow master's startup settings off in its own Interface settings. The master then skips it entirely, for both the UI shell and the autostart.

Deliberately not synced: the client's Startup URL (the thin-client pointer at a remote engine — cloning the master's would repoint every box) and its startup media paths.

Step 4: File Synchronisation

Clients keep themselves up to date

You do not have to push the fleet after every change. There are two kinds of edit, and they travel differently:

Values reach the clients immediately. Anything you change on an existing object — loop on or off, fade times, volume, crop, size, position, scaling, orientation, effects, a realtime source's parameters — is applied on every client as you make it, with no save and no push. Move a source in the Layout Designer and it moves on the wall while you drag.

Structural changes need a save, and nothing more. Adding a clip, a cue, a track or a whole composition creates something the clients have never heard of, so it can only reach them inside the show file. Save the project (from any tab — the SHOW view, the header, a User Panel, or a show controller over TCP/OSC) and the master sends the updated .vpp to every client that needs it and reloads them, usually within a few seconds. Media that the new content references is copied at the same time.

The File Sync header shows what is happening:

Chip	Meaning
in sync	every client holds the show and its media
syncing the show file	your save is on its way to the clients
syncing N files	media is being copied
… out of date	there is a difference, and it is not being copied right now — the tooltip says why (almost always: a show is running)
N unknown	a machine could not be reached or could not say what it renders. Never treated as in sync

You do not have to be on the NETWORK tab to see any of this: whenever something is outstanding, a small sync pill appears in the bottom-right corner of the window on every tab — syncing the show file — 62% while a transfer runs, or the outstanding state when one is being held back. It disappears once the fleet is current. Click it to jump to the NETWORK tab for the per-file detail.

Nothing is ever copied while something is playing. Updating a client means reloading its project, so the whole mechanism holds off during a show and reports the difference instead. Saving mid-show is safe: the clients stay on what they are playing, the chip shows the fleet is behind, and the update goes out as soon as playback stops. "Stopped" means every composition is actually on Stop — a paused composition holds a frame on the wall and counts as on air, and turning show mode off only blanks the outputs while playback keeps running underneath, so neither releases the update. To push right now instead, press Copy Files: its confirmation stops playback on every machine first, then copies.

Turn the whole thing off with Keep Clients In Sync in the master's System config; then Copy Files is the only way the fleet is updated.

Media is copied ahead of the save. The moment a clip is in the master's project, the clients that need it start receiving it — before you save. It only becomes visible on them when you save (a client renders from its own copy of the show file), so the usual result is that the bytes are already there and the save takes effect immediately. A client is only reloaded when the reload actually achieves something: the show file changed, or that machine was waiting for the file. Adding clip after clip does not restart your render nodes.

Differences are found by content, not file size, so a re-save that happens to produce a file of the same length is still detected. A machine running an older Exaplay build cannot answer the content check; its files are re-copied in full rather than assumed to be current.

Copy Files

Click Copy Files to transfer the sync folder and current project to every online client. The confirmation dialog stops playback on every machine first (the master's global stop, carried to the clients by the playback sync), so a deliberate mid-show push is deterministic: no client is re-joined into a half-copied show, and after the copy the fleet sits stopped on the new show, ready to start. The transfer runs as a job on the master engine (engine → engine): once started it keeps running even if you close the browser tab or the operator laptop sleeps, and a Cancel button stops it cleanly. Per-file progress bars show transfer status, interrupted transfers resume where they stopped, failed transfers are retried automatically, and each client loads the new project automatically once its file set has landed (a client whose files failed is not told to load, so it never silently runs a show with missing media).

Each remote's sync badge ("✓ N files / Last synced", "⟳ syncing…", "✗ error") reflects the outcome of the last Copy Files run for that machine.

Files are compared by content, not just by size. A file the client already has is skipped only when a sampled content check says it is the same file. This matters because a replacement often has exactly the same byte count as the one it replaces — re-exporting a clip with different settings, re-rendering a title, or recalibrating the same projector rig into the same .vwf. Those are now re-copied instead of being mistaken for files the client already has. The check reads a small fixed amount of each file (regardless of whether it is 100 MB or 100 GB), so it costs no meaningful time; a client running an older Exaplay build cannot answer it, and its files are re-copied in full to stay on the safe side.

Note: Setting sync.server-copy to false in the master's System config reverts to the legacy browser-driven transfer (the browser tab then is the data path and must stay open). If the master engine is too old to run the copy job, Copy Files stops with an error rather than quietly switching to that path — update all machines to the same build, or set the option deliberately.

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

Sync Folder

Configure the master media source folder in the File Sync text input. The default $[sync] resolves to the master's own configured sync folder. This field selects what the master sends; it is not copied as a literal destination path to the clients.

For fleets where each client uses a different local SSD, open NETWORK → Site Setup, select a client, and set its File Storage → Sync Folder. For example, one client can use D:\ExaplaySync while another uses E:\Shows. Keep the fleet-level Copy Files folder set to $[sync]; each receiving engine resolves that token to its own configured folder. An empty per-machine value uses the default $[exaplay]/sync location.

The client-local path is also used for the copied .vpp, automatic project load, startup/autoplay, Restart Clients, reconnect restore, resumable copy-job journals, drift auto-heal and missing-media fallback. The master's source path is never saved as a client destination, so these recovery paths continue to work when clients use different drive letters.

Main / Backup Failover

A backup machine is an ordinary client that renders nothing: it is kept in sync with the master — show file, media, playback position, live edits — stays dark, and can take the show over if the master fails.

Set it up on the backup machine only, in Settings → Communication:

Setting	What it does
Backup Machine	Marks this client as the designated backup. Nothing else on this list has any effect without it.
Promote Automatically	Allows the machine to promote itself when the master falls silent. Off = promotion by command only.
Require Arming	While on, an automatic promotion additionally needs the backup to be armed. Arming is deliberately not remembered across a restart.
Dead Time (s)	How long the master must be silent on every channel before an automatic promotion. Default 10 s.
On Promotion Send	The OSC> / TCP> / UDP> lines to fire when this machine takes over — one per line, the same syntax a cue uses. This is where the video-matrix command goes.

The master needs no configuration at all.

Taking over

Promotion does two things: the machine becomes the master (Instance Role, persisted, so it stays the master if it reboots) and show mode goes on, so its outputs light up. Then the configured actions are sent.

You can trigger it at any time, and this manual override always works — it is not gated on any of the settings above, so it is still there when the configuration is wrong:

OSC   <prefix>/global/failover promote
REST  POST /failover  {"action":"promote"}

arm and disarm are the same two channels. GET /failover reports the current state and, when the machine has not taken over, why — the reason names the setting to look at.

What it will not do

• It never promotes twice. Sending promote again, or an automatic rule firing while your own switch does, promotes once and sends the actions once.
• It never demotes. When a failed master comes back, both machines are masters until you decide which one keeps the show. Set the other one back to Client in Settings, or restart it.
• It never promotes against a master it has never heard. A backup on a bench, in the wrong fleet, or with the beacon blocked at a switch looks exactly like a dead master — so these stay dark and say so instead.
• It does not promote in the first 30 seconds after the engine starts, so a rig powering on together does not race.

Liveness is measured on two independent channels — the master's ~1 Hz OSC identity/keepalive stream and the discovery beacon — and the freshest one decides. A master that is stopped, or one whose stream is blocked by a firewall, is still alive.

Network Requirements

Port	Purpose
8123	Engine and file transfer
8124	Exaplay Service (watchdog) — always engine port + 1
45454	Auto-discovery between Exaplay instances (UDP)
45455	Fleet heartbeat — client health, sync quality and drift (UDP)

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

Troubleshooting

Remote not appearing in Systems list

• Read the note at the top of the NETWORK tab's right-hand panel: while nothing is discovered it names the ports and the checks below, and its Add machine by IP… button reaches a machine that discovery cannot (another subnet, blocked UDP broadcast).
• 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.

Two machines with the same hostname

Fleet machines are identified by hostname + port. Render nodes imaged from the same Windows image share a hostname, so the second machine collides with the first: it is dropped from the fleet and never appears in the Systems list or Sync Health. When this happens the master shows a warning naming the conflicting machine's IP address ("Two machines are using the identity …"). Fix it by giving each machine a unique Windows computer name — this can be done remotely from Site Setup → Host & Network.

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 (✗).

Resetting a Forgotten PIN

If a system's PIN Lock code is lost or forgotten, it can be cleared by editing that machine's configuration file directly on disk — this requires local (or remote-desktop) file access to the locked machine itself; it cannot be done from the browser.

1. On the locked machine, close Exaplay (or at least the browser tab showing it — the file can be edited while the engine is running, but restart Exaplay afterwards so it re-reads the file).
2. Open Documents\Exaplay3\config\config_system.json in a text editor.
3. Find the ui.pin-lock block:

{
  "ui": {
    "pin-lock": {
      "enabled": true,
      "code": "aB3xy9Z1"
    }
  }
}

4. Set "enabled" to false (or delete the "pin-lock" block entirely). Save the file.
5. Restart Exaplay on that machine, or reload the browser tab once the engine has re-read the config.

Warning: config_system.json holds this machine's full System configuration, not just the PIN — edit only the pin-lock block and leave the rest of the file untouched. Make a copy of the file before editing if you're unsure.

The lock is per-system, so this only needs to be done on the machine that is actually locked — other systems in the fleet are unaffected.