Digital signage on BrightSign players

A BrightSign is the most capable player on this list: real reboots, CEC panel power, dual outputs and frame-accurate video wall sync. Setup is one archive on the storage root and a power cycle.

What runs on the player

The web player, unmodified, inside an roHtmlWidget — with a small BrightScript host around it that owns the widget, keeps the identity, and executes the handful of things a page cannot do for itself.

This is not a port. A Series 5 player ran the ordinary player through 4,723 items over 12.4 hours, averaging 9.4 seconds against a 10-second slot. So the question was never whether the page runs; it was the four jobs the host exists for: rebuilding the widget when a reload would not come back, recovering from a dead server, keeping identity in the registry where it survives a content update, and reaching BrightScript-only capabilities on the page’s behalf.

One file, from your own server

Open the downloads page on your instance and download autorun.zip.

Take it from your own server, not from a release page. The archive has the server address stamped into its bytes when your instance builds it, so the copy you download is already pointed at you — nothing to edit, and no chance of imaging a batch of players against the wrong instance, which is a mistake that looks exactly like a pairing bug.

Install

Put the single file on the root of the player’s storage — a microSD card, or internal flash over SFTP — and power-cycle. The player unpacks it in place, renames it so it never extracts twice, and reboots into the player.

Two rules the format imposes, both of which fail silently if broken:

• Do not unzip it yourself and do not nest it in a folder. The player extracts to the storage root; a wrapper directory puts the host script somewhere the player never looks, and the card appears to do nothing at all.
• Do not put an autorun.brs beside the zip. Its presence stops the archive being processed. The host script belongs inside the archive, which is where ours is.

Needs BrightSign OS 7.0.60 or newer for the in-place unpack.

No card slot, or a dead one? A player boots the host from internal flash just as happily — confirmed on a unit whose microSD interface is physically dead. Push the file to /storage/flash over SFTP once SSH is enabled on the player, and reboot.

Pairing

The player shows a six-digit code. Enter it under Add Display in the dashboard.

Identity is kept in the player’s registry rather than in browser storage, so it survives reboots, content updates and a change of server origin. The hardware serial is the stable id, which means two players imaged from the same card never collide.

Provisioning a batch

A screentinker.json on the card sets the server URL, the sync backend and the output mode, and it wins over the registry and the built-in default. That is how a batch gets imaged without touching each box:

{ "server_url": "https://signage.example.com", "sync_backend": "auto", "output_mode": "single" }

Two displays from one player

output_mode is single, dual or clone. dual loads a second widget that the server hands its own playlist — two independent screens, one player. clone puts the same content on both outputs.

Confirmed multi-output: XC2055 (dual HDMI) and XC4055 (quad). Do not trust a series-level spec blurb here. The XT5 family description credits XT245, XT1145 and XT2145 with “dual HDMI outputs”, but an XT245 in hand is single-output — the phrase appears to cover HDMI in plus out. Check the individual model before enabling dual. An unsupported model keeps working as a normal single-screen player rather than failing to start.

Video wall sync: ours or BrightSign’s

Both, chosen per group. Our protocol is clock-derived, leaderless, accurate to the second, and works across a mixed estate — BrightSign, Android, web and Tizen screens in one synchronised group. BrightSign’s own BrightWall sync is frame-accurate but BrightSign-only.

Set a group to auto and native sync is used when every member is a BrightSign, ours otherwise. Three conditions force a fallback, and each is reported rather than applied quietly: a non-BrightSign member, members on different subnets (it is multicast and does not cross networks), or the elected leader being offline. A group that half-syncs is worse than one that syncs to the second everywhere — and it would be invisible from the dashboard, because the BrightSigns would look perfect while the odd panel drifted alone.

What the dashboard can do here that it cannot do to a browser

That last row is not a detail. A page-initiated reload does not reliably bring an roHtmlWidget back: on one deploy every connected player reloaded and returned, and the BrightSign was the only screen that never came back. So the page here never reloads itself — it asks the host, and the host tears the widget down and builds a new one.

On top of that the host retries a failed load with backoff, falls back to a local page that names the server and keeps probing it, and runs a watchdog: the page beats every 30 seconds and three missed beats rebuild the widget. That covers the failure a load error never reports — a page that loaded fine and then wedged.

Which players

Validated here on Series 5 — XT245 and HD1026, on BrightSign OS 9 and 10 — and listed as certified hardware. Series 6 players run the same package the same way; we have not had one on the bench, so treat that as expected rather than tested, and tell us how it goes.

A player paired before this package existed is still recognised, by its BrightSign user agent. You do not have to re-pair a fleet to adopt it.