// INSIGHTS
Digital signage that updates live across a whole venue
6 min read
A four-hall expo with 38 screens has one hard requirement. When the session grid changes at 11:00, every screen shows the new grid within a minute. That is not a content problem. It is a distribution problem with a network under it. We build venue signage that plays from a local bundle, updates over the venue LAN, and holds a known-good slide when the feed goes quiet. The internet is optional, and we design as if it will not be there.
Screens are a distribution problem
Most signage failures are not design failures. The deck looks fine on a laptop. It fails because 38 players in four halls are each pulling a 4K file over a shared uplink at 10:40, ten minutes before the session change. A 1080p H.264 loop at 8 Mbps is manageable. The same loop at 4K and 35 Mbps, times 38 screens, is over a gigabit of simultaneous pull that no temporary venue uplink will carry.
So we stop pulling from the internet. Content lives on a local content server on the venue LAN, usually a small box in the network rack beside the core switch. Players resolve that server through local DNS, so the signage URL works with the WAN cable pulled out. Each player holds the full content package on local storage and plays from disk. The LAN carries update deltas and heartbeats, not video.
Live then means something specific. A session-grid change is a few kilobytes of JSON, not a new video file. We publish a new immutable hashed release to the content server. Players see a new hash on their next poll, fetch it, verify it, and swap at the next loop boundary. If the hash does not verify, the player keeps showing what it already has. Rollback to the last known-good bundle is one command and lands on every screen in under a minute.
Numbers we build to
The bundle, not the stream
Local content server
One box on the venue LAN holds every release. Players fetch it over gigabit copper, so playback never depends on the uplink staying alive.
Immutable hashed releases
Every build carries a content hash that players verify before swapping. The previous bundle stays on disk, so rollback is instant.
Per-screen zone targeting
Screens are grouped by hall, foyer, registration and back-of-house. A hall 3 override changes nine screens and leaves the other 29 untouched.
Heartbeat and last-seen
Each player reports every 30 seconds. A failed HDMI extender shows up on the dashboard in a minute rather than at the next floor walk.
Deployment order
Survey and mount plan
We walk the floor, measure cable runs and mark portrait versus landscape per position. Any run past the 15m HDMI limit gets a CAT6 extender pair and a line in the rack schedule.
Rack, power and network
Content server, switch and players sit on the same UPS-backed circuit wherever the venue allows it. Every port is labelled and every screen is mapped to its DG phase.
Bundle build and dry run
We build the content package with the real session grid and run it on the actual hardware for several hours. That is when burn-prone static elements and undersized fonts get caught.
Show-day operations
One operator holds the override console. Scheduled playlists carry the day, event-driven overrides handle the rest, and every screen has a static holding slide as failover.
What usually goes wrong
The most common Indian venue failure is power, not software. A DG changeover drops the hall for four to eight seconds. Panels come back before the switch does, players boot before the content server has finished starting, and thirty screens sit on a no-signal banner while everything else looks fine. The fix is sequencing: server and switch on UPS with a five-minute hold, players on delayed start, and a boot-time retry loop that keeps asking local DNS for two minutes before falling back to the on-disk bundle. Smart-TV built-in players are the worst offenders here, because you cannot control their boot order or suppress a vendor splash screen.
The second failure is that nobody is watching. Heartbeats only help if a person reads them. A screen that lost HDMI at 09:15 can sit black for six hours if the dashboard is open on a laptop in a locked office. The third is heat and light. A foyer screen at 350 nits behind glass at 2pm in Jaipur is simply unreadable, and in Dubai an entrance-adjacent panel will thermal-derate and dim itself before it ever shuts down. Burn is real too. A static sponsor bar sitting in the same 200 pixels for three days leaves a ghost. Move it on a slow cycle, or accept that the panel is a consumable.
Common questions
Can we use the screens' built-in players instead of separate boxes?
Sometimes. Built-in players are cheaper and remove one HDMI link, and for a two-day loop with no live data they are fine. They boot slowly, resist sequencing after a power event, and their app support varies by model and firmware. For anything with a live session grid, or more than about twelve screens, we spec external players.
Do we need 4K?
Rarely. At normal expo viewing distance of three metres or more, 1080p on a 55-inch panel is indistinguishable from 4K. Going to 4K quadruples file size and encode time for content most people glance at for four seconds. We reserve it for close-viewed wayfinding and product detail screens.
What happens if the internet dies mid-show?
Nothing visible. Players run from the on-disk bundle and resolve the content server through local DNS, so playback and LAN-side updates continue with no WAN at all. What stops is anything sourced from outside, such as live social feeds or a remote CMS push. Those are exactly the panels we design a fallback slide for up front.
Signage that holds when the venue does not
Send us your hall plan and screen count and we will come back with a player, cabling and bundle spec.
