Real time, offline resilience, old screens: how it's built
A playlist change reaches the screen in a few seconds, playback keeps going when the network drops, and a screen bought eight years ago is still supported. Here's the mechanics behind that, and what they cost.
Real-time control — the platform and the screen
Your turn — Zoom, rotate, apply an effect: the screen follows, and the platform sends you back what it's showing.
Screen "Reception hall"
Every setting reaches the screen instantly — no redeployment, no on-site intervention.
Screen cast — from phone to the room's screen
Your turn — Enter the code shown on screen, choose what you're sharing, broadcast: the phone then mirrors what the room sees.
Screen sharing
Salle Confluence
Open smart-signage.app/cast
then enter the code
K7F2
Screen "Confluence Room" — playlist playing
Code shown on screen
Share
Real time: push, rather than poll
The usual way to update a screen is to have it poll the server at a fixed interval: every five minutes, every fifteen minutes. Content eventually arrives, but delayed by whatever's left of the current cycle, and every screen consumes network bandwidth even when nothing has changed.
Smart-Signage works the other way around. The platform keeps a permanent channel open to each screen, using Server-Sent Events, and pushes the event the moment it happens. You edit a playlist or a schedule: the change goes out immediately and the screen applies it within seconds. There's no refresh cycle to wait for, and nothing travels over the wire while nothing is changing.
That choice has infrastructure consequences. It means holding a large number of connections open at all times, which isn't the default regime a web server is tuned for. The Caddy reverse proxy was chosen in particular for how well it handles these long-lived connections.
The channel works both ways, and that's what makes monitoring honest:
- every screen sends a regular heartbeat, signalling that it's alive;
- the platform shows the fleet's real status, screen by screen: online, silent, and what each one is actually playing at that moment;
- a screen that stops sending becomes visible immediately, with no one having to go check in person.
When the network drops, and when an update goes wrong
A screen that depends on the network is a black screen waiting to happen. Content is therefore cached locally by a Service Worker: if the connection disappears, playback continues with what's already on hand, and the screen resyncs as soon as the network returns. No one needs to step in on site.
One real-world constraint calls for a precaution worth naming: Android WebViews cap the size of files they'll agree to keep in cache. A large video loaded as a single block exceeds that cap and would never get cached, so it would never be available offline. For that reason, large media files are read in successive chunks rather than all at once. That splitting is what makes offline mode genuinely reliable on this kind of hardware.
The second risk isn't a network outage, it's the update itself. A supervisor written in ES5 JavaScript runs ahead of the application code and drives the Service Worker. If three consecutive startups aren't healthy, the screen rolls itself back to the last known-good version automatically. A safeguard also caps automatic reloads at two per minute, ruling out a screen stuck flickering in a loop. The practical result: a failed deployment doesn't take down an installed fleet — it repairs itself.
An existing fleet isn't a fleet to throw away
This is the point we give the least ground on: the software adapts to the hardware already in place, not the other way around. The player ships in two versions built from the same source code, a modern version for recent devices and an ES5 version for old embedded browsers. Same functions, same product; what changes is how the code is compiled and served.
The real-world fleet in digital signage isn't a recent one. Many screens installed five, eight or ten years ago run a browser frozen at its original version, one nobody will ever update. Chrome 44 and later versions are supported. LG webOS 4 embeds an engine equivalent to Chromium 53, which doesn't know CSS Grid: these devices receive fallback layouts written specifically for them, so the composition holds together instead of stacking up at random.
This work has a cost, and we own it: every interface change has to be verified against the old baseline before it ships. In exchange, switching signage software doesn't force you to replace the screens, and the hardware budget drops out of the decision entirely.
What's supported:
- the Web, on any device with a browser;
- Android, with a dedicated app, including on old WebViews;
- LG webOS, older generations included;
- no proprietary hardware imposed: the choice of screen supplier remains yours.
What an IT department will want to check before signing
Hosting is provided by OVH, on servers located in the European Union. No data is hosted outside the EU, and GDPR compliance is documented.
On the network side, the screen only needs outbound access to the platform. The permanent channel is an ordinary connection initiated by the screen itself: there's no inbound flow to authorise into your premises, and no server to install on your own infrastructure.
There's still a trade-off, because there always is one. Targeting old browsers rules out using new Web features as soon as they ship, and requires validating two baselines instead of one: development is slower, and some interface refinements get dropped because they wouldn't work everywhere. We'd rather ship a slightly plainer interface that displays on every screen than a flashy one that leaves some of the fleet behind. A digital signage buyer changes software far more often than they change hardware, and that's the relationship this architecture protects.
Questions fréquentes
How long does it take for a change to reach the screen?
A few seconds. The platform doesn't have the screen poll the server at a fixed interval: it keeps a permanent channel open to each screen, using Server-Sent Events, and pushes the change the moment it's saved. There's no refresh cycle to wait for on a playlist or schedule change.
Do existing screens need to be replaced to use Smart-Signage?
No. The player ships in two versions built from the same source code: a modern version for recent devices and an ES5 version for old embedded browsers. Chrome 44 and later versions are supported, as is LG webOS 4, whose engine is equivalent to Chromium 53 and receives fallback layouts in the absence of CSS Grid. A screen bought eight years ago remains usable.
What happens if the network drops or an update fails?
During a network outage, the screen keeps playing content cached locally by a Service Worker, then resyncs once the connection returns. In case of a faulty update, a supervisor written in ES5 JavaScript, running ahead of the application code, detects three consecutive unhealthy startups and rolls the screen back to the last known-good version, with a cap of two automatic reloads per minute.
Where is data hosted, and what systems does the player run on?
Data is hosted at OVH, on servers located in the European Union; no data is hosted outside the EU and GDPR compliance is documented. The player runs on the Web, on Android with a dedicated app, and on LG webOS, with no proprietary hardware imposed.