How to run content across a display network without a site visit

Picture one marketing coordinator who has ended up looking after twenty screens. A few sit in the head-office foyer; the rest across three other sites. A price changes, a promotion ends, and one site runs last month's offer for a week before anyone spots it. Loading content screen by screen, on a USB stick, stops scaling at about the third screen. A display network is built to solve that exact problem. 

Manuco Electronics supplies and specifies commercial displays, and the players that drive them, from Thomastown in Melbourne's north. The guidance here stays neutral on software brand. The aim is to help you match the way you run content to the size of your network and the kind of content you show, so you buy the right setup once. 

A content management system, or CMS, is the software that stores your content, sets when and where it plays, and sends it out to your screens. It is the part you log into. Everything else in the network takes its orders from it. 

A signage CMS does four main jobs: 

• It holds the content library, so images, video and live feeds live in one place. 

• It builds the schedule, deciding what shows on which screen and when. 

• It pushes updates out to every screen over the internet. 

• It reports back, so you can see which screens are online and playing. 

Most signage runs on a cloud CMS, where the software sits online and you reach it from a browser. A few large or security-sensitive networks run the CMS on their own servers instead, which gives more control but more to maintain. For most buyers, cloud is the simpler choice, and it is the reason a network can be run from anywhere. 

Cloud CMS software is usually priced per screen, per month, the running cost people forget when they budget for hardware. We cover the full running cost in a separate guide. Here, the CMS matters as the tool that makes a network manageable at all. 

Every screen needs something to run the content. There are two ways to provide it: an external media player, or a system-on-chip (SoC) built into the display. 

An external media player is a small box that plugs into the screen, usually by HDMI. It has its own processor, storage and network connection, and runs the content the CMS sends it. Because it is separate, you can pick a more powerful player for demanding content, and you can replace or upgrade the player without touching the screen. 

A system-on-chip display has the player built in. There is no extra box, no extra cable and one less thing to fail. It runs an operating system on the panel itself, commonly Tizen, webOS or Android. The trade-off is that the compute is tied to the screen's life. If the built-in player falls behind what your content needs, you cannot upgrade it on its own without adding an external player anyway. 

There is a middle option worth knowing. A slot-in PC fits a bay in the back of some commercial screens, built to a standard called OPS (Open Pluggable Specification). It gives you the power of an external player without a separate box hanging off the screen, and it swaps out without replacing the display. It suits sites where IT wants a full computer behind the screen but a tidy install. 

The rule of thumb is simple. SoC suits simple, standard content and tidy rollouts where every site is the same. An external player suits complex content: multi-zone layouts, several videos at once, live data, interactive touch, or a video wall driving many panels. 

Media player vs built-in SoC at a glance 

Running content across a display network well comes down to three tools the CMS gives you: scheduling, zoning and grouping. Together they let one person update many screens from a desk. 

• Scheduling decides what plays and when. Dayparting is the common version: a cafe screen shows breakfast items until 11am, then switches to lunch on its own. You set it once and the CMS handles the change every day. 

• Zoning splits a single screen into regions. A foyer display might run a full-screen video in the main zone, a news or weather strip along the bottom, and the time in a corner. Each zone updates on its own, so you can change the promo without rebuilding the whole layout. 

• Grouping is what makes scale possible. You tag screens into groups, by site, by role or by region, then push content to a whole group at once. Change the menu for all Victorian stores and every screen in that group updates together, with no site visit. This is the step that turns twenty separate screens into one network. 

Remote monitoring sits underneath all of it. A good CMS shows which screens are online and playing, so you find a black screen before a customer does. 

Sharing the job: who can publish to which screens 

Once a network is run by more than one person, the question becomes who can change what. A CMS handles this with user roles and permissions. 

• Roles decide what each user can do. A head-office manager might build and approve content for every site. A local staff member might only update their own screen, or only submit content for approval. 

• Approval steps stop the wrong thing going live. On a larger network, content can be set to need a sign-off before it publishes, so a typo in a price never reaches fifty screens. 

• Playlists are the shared building block. Instead of scheduling files one by one, you build a playlist once and drop screens or groups onto it. Update the playlist and every screen using it follows. 

For a network where several people touch the content, these controls matter as much as the hardware. They are the difference between a network that stays on-brand and one that drifts. 

Most content problems on a network come down to a screen showing content built for a different one. A few habits prevent the common ones. 

• Match content to each screen's resolution. A file made for a Full HD screen looks soft stretched onto a 4K panel. Build content at the resolution of the screen it plays on, or let the CMS scale it and check the result. 

• Set orientation before you design. A portrait screen in a shopfront needs portrait content. Designing landscape and rotating it later rarely looks right. Decide portrait or landscape per screen at the planning stage. 

• Keep file types simple. Standard MP4 video and common image formats play reliably across almost every player. Unusual codecs are the ones that stutter or fail on cheaper hardware. 

• Give each screen a reliable connection. A wired connection is steadier than WiFi for a screen that plays all day. Where WiFi is the only option, check the signal reaches the screen's spot before install. 

• Plan for the screen that drops out. Networks lose connection sometimes. A player that keeps its content in local storage keeps playing the last schedule if the internet drops, so the screen stays on rather than going black. Ask what a player does when it loses signal before you commit to it. 

The right setup follows from two things: how many screens you run, and how complex the content is. A handful of screens showing simple promos runs happily on SoC displays and a basic CMS. A larger network, or one with video walls, live data or touch, is worth building on external players with the headroom to grow. 

One decision is easy to get wrong and expensive to reverse: buying screens and players that suit today's content but not next year's. If there is any chance the network will grow, or the content will get richer, size the players for where you are heading rather than only where you start. 

If you tell Manuco how many screens you are planning, where they sit and what you want them to show, the team can recommend a player and CMS approach that fits the network now and leaves room to scale. Send through your site list and content plan to get a setup matched to the job.