BrightBridge Manual

New operator modeWork down this page in order.

Read the topic first, then follow its numbered steps. Nothing changes in BrightBridge until a step explicitly tells you to select, save, start, deploy or restore.

01Choose the job you are doing 02Temporary event deployment 03Before an event or temporary install 04Change content during an event 05Pack down a temporary deployment 06Permanent installation differences

Topic 1 of 6

#Choose the job you are doing

Job	Use BrightBridge for	Important difference
Temporary event	Prepare players, deploy show content, monitor screens and restore or retire the temporary setup	Names, tags and rollback points must make sense for the event dates and venue
Permanent installation	Maintain known players and make controlled content changes	Avoid temporary names and confirm long-term schedules and ownership
Test or rehearsal	Prove content, variables and player compatibility on a limited target	Use test-labelled players and do not assume rehearsal results cover every production device
Fault check	Inspect one symptom with status, snapshot, ping, logs or Liveview	Start read-only and avoid changing the whole fleet to diagnose one screen

Topic 2 of 6

#Temporary event deployment

Click-by-clickPut approved event content on temporary players

PlayersDeploymentVerify

1
Players
Confirm every event player has a clear venue or screen label, the correct model and an agreed event tag.
2
Presentation
Upload the complete approved published output and give it an unmistakable event and version name.
3
Targets
Filter by the event tag, select the intended players and compare the selected count with the equipment list.
4
Dry run
Run a fresh preview. Read every player result, variable and overwrite warning.
5
Deploy
Deploy once, wait for each result, then allow time for players to collect the content.
6
Verify
Check fresh activity and visually confirm the important screens using a snapshot, Liveview or an on-site check.

Topic 3 of 6

#Before an event or temporary install

Player labels match the venue plan or screen list.Temporary tags use one agreed event name rather than several near-duplicates.The player model is known where compatibility matters.The presentation name includes a useful event and version identifier.Player-specific variables are approved and contain no secrets.A known-good rollback point or previous presentation is available.There is enough time for content transfer and visual verification before doors or rehearsal.

Topic 4 of 6

#Change content during an event

1
Confirm the affected player or group and the currently visible content.
2
Select the corrected approved presentation and only the intended targets.
3
Run a new dry run and read every warning.
4
Deploy once and wait for collection.
5
Visually verify the corrected screens before closing the issue.

Topic 5 of 6

#Pack down a temporary deployment

No deployment, upload, rollback or Liveview session is still running.The final content state and any faults worth retaining have been recorded outside the public wiki.Temporary players are confirmed as returned, rebuilt or retired before their records are removed.Event-only tags and presets are removed only when nobody still relies on them.Presentations needed for rollback, reporting or another event are retained.Unused library items are deleted only after their purpose and recovery value are checked.

Topic 6 of 6

#Permanent installation differences

Use stable location-based player names instead of event names that will become meaningless.
Use long-lived tags for site, room or purpose; temporary campaign tags can still be added and removed.
Check operating schedules before treating an offline player as faulty.
Keep presentation names versioned so future changes and rollback remain understandable.
Confirm long-term player-specific values before asking BrightBridge to keep them managed.