Run multi-site signage as store-and-forward: keep the master library on your own server, put one synced player behind each screen or one multi-output mini PC per site of three, pull updates hourly over plain protocols, and let every screen play from its local copy when a site line drops. The article compares five layouts, sizes the sync traffic with worked numbers, and gives the decision for each case.
A chain of ten sites with three menu screens each, 30 screens today and 45 within the year, is a store-and-forward problem. Keep the master files on the server you already own, give every screen a player that pulls a full copy of its library, and let playback run from that local copy. The store's internet line then carries updates instead of carrying the show. This article answers the layout question: what hardware sits behind each screen, where the files live, what the sync traffic costs, and what changes on screen when a site's line goes down.
One synced copy behind every screen
Self-hosted multi-site signage runs on pull sync, and it needs nothing exotic. The master library lives on the NAS in your office. At each site, every screen has its own player: an Android-class box, a small PC, or a display with the player built in. On a schedule, each player connects to your server and pulls new or changed files over protocols a NAS already serves: HTTP, FTP, WebDAV or SFTP. Playback always runs from the local copy, so the sync link can drop for a day and the loop keeps going. The basics of digital menu boards with no monthly fee apply at every site.
Keep the endpoint off the open internet: terminate the sync in a site-to-site VPN or a single HTTPS host, issue one credential set per site, and never publish raw FTP to the web. Set the schedule by content change rate. Menus change weekly, so an hourly pull per site is generous, and even twice a day keeps any store within a day of head office. Size the store link for a full library pull, not for delta transfers; the worked example below puts a full three-screen pull at about two minutes on a 50 Mbps line.
The five layouts side by side
For 10 sites of 3 screens, the realistic layouts are:
| Layout | Hardware at 10 sites x 3 screens | Playback when the site line is down | Recurring cost | Main weakness |
|---|---|---|---|---|
| Cloud CMS subscription, one player per screen | 30 small players | Stops on a cloud-only plan; continues where the plan keeps a local cache | Per-screen monthly fee | Every screen and site added multiplies the fee |
| Free sync app on an Android box per screen | 30 boxes | Full local copy keeps playing | None | You own monitoring and updates |
| Open-source CMS hosted on your own server | 30 players | Scheduled pull leaves a full local copy | None | You run the CMS, its updates and its backups |
| One multi-output mini PC per site | 15 PCs, three outputs each | The loop plays from the PC's own disk | None | One failure blanks all three screens at that site |
| Display with the player built in, one per screen | 30 displays | Pulls a playlist from your own server on a timer, or plays from card | None | Content changes stay per-screen and manual |
Read the table by the third column first: every layout that keeps a full local copy treats an outage as a non-event. The real differences are who runs what, and what each screen you add costs over its life.
Where each layout wins
A cloud CMS wins when nobody at head office should ever touch a server. Uptime, updates and the player app are the vendor's job, and a browser is the whole interface. The trade is the per-screen monthly fee multiplied across 45 screens, and playback that follows the vendor's cloud model.
A free sync app on Android boxes wins at exactly this profile. You already produce the content, the NAS is bought, and 30 media-player boxes are a one-time hardware buy with no license. What you give up is telemetry: a dead box looks like any other TV until someone walks past it, and sync connections that quietly drop are the common failure. The article on an Android signage player that keeps losing its CMS connection covers how that failure looks and what to check before you trust the schedule.
A self-hosted open-source CMS wins when central control matters. Per-screen schedules, accounts for the marketing team, and a report confirming each screen actually updated are what it adds. It is the same store-and-forward playback with a management layer, and you become its systems administrator, patches and backups included.
A multi-output mini PC wins where the three screens hang within one cable run of a cabinet and play the same loop. One power feed, three HDMI outputs, one device to sync. At 1080p, passive HDMI runs are good to about 5 m; longer runs need active cables or extenders. The trade is concentration risk, one dead PC blanking the whole site, and three screens locked to one schedule. If the one-device-versus-one-per-screen decision is still open, the SoC versus external player versus mini PC comparison works through it.
A display with the player built in wins for single-screen sites and new fit-outs. Our panel-mount screens sit in this group: the included player is free with no subscription, starts the show by itself at power-on, and can pull a playlist from your own web server on a timer, or play JPG, PNG and MP4 files from microSD or USB where there is no network at all. Menu boards are the typical job here; the digital menu boards with no monthly fee category shows that setup.
Worked example: sizing one 3-screen store
Take one new store: three screens playing the same loop of 12 clips, averaging 30 seconds each, encoded as H.264 MP4 at 1080p and 6 Mbps, a common good-quality encode for that resolution.
Clip size: 6 Mbps / 8 bits per byte = 0.75 MB per second of video. One 30-second clip: 0.75 x 30 = 22.5 MB. The full loop: 12 x 22.5 MB = 270 MB per screen.
First fill: three players each pull their own 270 MB copy, so the store moves 3 x 270 = 810 MB. A 50 Mbps store line carries 6.25 MB per second, so the fill takes 810 / 6.25 = about 130 seconds. Even a 20 Mbps line finishes in 810 x 8 / 20 = 324 seconds, just over 5 minutes.
Weekly change: replacing two clips moves 2 x 22.5 = 45 MB per screen, so 135 MB per store, which is 1080 Mb, or about 22 seconds on the 50 Mbps line. At one hourly pull, the store's weekly sync traffic stays under 1 GB, which no broadband line notices.
Storage and playback: 270 MB fits any player-class storage, so storage never enters this decision. Once a copy is local, the line can drop for a week without the loop noticing; the only queue is at head office.
What a site outage actually changes
When the store line drops, the screens show no change, because playback runs from the local copy. What stops is delivery and visibility. New clips wait at head office until the line returns and the next scheduled pull runs, and remote status goes blind. Two habits make outages dull. First, load at least a week of fresh material with every update, so a multi-day outage never shows a stale menu, and decide how long the cached library should carry the screen; offline schedule caching is covered in its own article. Second, confirm every player boots straight back into its loop after a power cut, because every outage ends with one; the article on power loss recovery for offline displays lists the checks.
The decision for each case
Decide by screen layout, in this order:
- Three screens within one cable run of a cabinet, playing the same loop: one multi-output mini PC per site, synced on the same pull schedule.
- Screens spread through the store, different content, or more than three per site: one Android-class sync player per screen, pulling from the NAS over the VPN.
- Central schedules, user accounts and update reports with no per-screen fees: the same per-screen players, with an open-source CMS hosted on the NAS.
- New single screens, kiosks or refreshes of small units: a display with the player built in, pulling from your own server on a timer or playing from card offline.
- Sites nobody will ever service, where head office wants a vendor to call: the cloud CMS, accepting the recurring per-screen cost and the cloud-only playback dependence.
Recommendation
Recommendation: For 10 sites of three screens today and five more within a year, put one Android-class sync player behind every screen, pull the library from the office NAS over HTTP inside a site-to-site VPN on an hourly schedule, and size each store line for a full 270 MB pull per screen, about 130 seconds on a 50 Mbps connection. Keep the multi-output mini PC for the rare site where all three screens hang within one 5 m cable run and play the same loop. Start with the free sync app for flat image-and-video loops, and move to a self-hosted open-source CMS the day you need per-screen schedules or confirmation that every screen updated.
Questions
How many players can one NAS sync at once?
Plan the concurrency, then forget it. Thirty players each pulling a 270 MB library is 30 x 270 = 8.1 GB of total traffic. If all 30 pulled at once, a NAS with a gigabit LAN port, which moves roughly 110 MB/s, would serve the lot in 8100 / 110 = about 74 seconds, and even an entry-level NAS reads from disk faster than that. Stagger the schedules so a few sites pull in each hour and the load becomes unmeasurable.
Do the TVs already on the wall need replacing?
Usually no. A consumer TV works as the panel as long as the player's output resolution matches the panel's native resolution, typically 1920 x 1080. The differences that matter at this scale are brightness in a bright dining room and how many hours a day the screen is on over a multi-year menu board life, where commercial panels carry longer rated panel life. Replace a TV when its brightness or panel life runs out, not for the player change.
What stops working first when a site line is down for a week?
Delivery and reporting, in that order. Playback keeps running, because each player holds its full library locally. New content queues at head office until the line returns and the next scheduled pull runs. Remote status goes blind at the same time, so a site with a dead player and a dead line looks identical to a site with a dead line and a playing player. That ambiguity is the case for a weekly walk-through past every screen.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.