Ask a signage vendor what happens when a screen loses its internet connection and you usually get one of two unhelpful answers: “it just keeps working”, or a change of subject.
The honest answer is that some of your content keeps playing and some of it quietly stops, and which is which depends entirely on how you built the playlist. A screen showing cached images and video runs for days without a connection and nobody notices. A screen whose main panel is a live dashboard shows an empty rectangle within minutes, and still nobody notices, because it does not look broken.
Here is what actually happens to an easyCMS player when the network goes away, and how to build a playlist that fails gracefully rather than embarrassingly. It applies to all three player platforms we support: Windows, Android and LG webOS.
The moment a player loses its connection
Nothing dramatic happens. That is the important part.
An easyCMS player does not stream its content from the CMS. It downloads media and schedules in advance, stores them on the device, and plays from that local copy. The connection exists to keep the local copy current, not to feed the screen frame by frame.
So the moment the connection drops:
- The layout on screen carries on to its end and loops as scheduled.
- The player keeps following the schedule it already holds, including time-of-day changes it has been told about.
- It keeps trying to check in on its collect interval. Each attempt fails quietly and is logged.
- In the CMS, that display’s last accessed time stops advancing, and once it has missed enough check-ins it is flagged offline. Have the CMS email you when that happens, see display monitoring.
One requirement is absolute: a player needs a connection at least once, at the start, to register with the CMS, be authorised, and pull down its first content and schedule. Before that first check-in it has nothing to play. After it, it is largely self-sufficient.
Note too that “offline” in the CMS does not mean “dark on the wall”. They are different problems, and confusing them sends people on site who need not have gone.
What keeps playing, and what quietly stops
Get this distinction right and an outage is a non-event. Get it wrong and you have paid for a screen that shows a blank box during your busiest week.
What keeps playing
Anything already downloaded to the player:
- Images in the media library
- Video files uploaded to the library
- Audio files
- PDFs
- Layouts the player has already downloaded, the full design, regions, durations, transitions and all
If your rotation is made of those, an outage changes nothing on screen.
What stops outright
Anything fetched at the exact moment it plays:
- Video streaming: anything pulled from a stream rather than a local file
- Embedded web pages: an intranet page, a booking screen, a third-party display page
- Dashboards: BI tiles, reporting embeds, anything rendered on the fly
- Social media feeds
The Xibo documentation our engine is built on is blunt about this category: such content “will not show when the internet is down.”
What goes stale rather than blank
Weather, RSS and news tickers catch people out because they do not always fail visibly. Where the last set of data reached the player before the outage, the widget can carry on showing it: a weather panel still reporting yesterday’s forecast, a ticker still scrolling headlines that stopped being news two days ago.
That is the dangerous category. Nothing throws an error and the layout looks healthy, so a manager walking past sees a screen that is on and apparently fine. The gap gets reported weeks later, or never.
Treat anything with a live data source as untrustworthy during an outage, whether it blanks or not. Go through your layouts and write down every region whose content is fetched at play time, that list is your outage exposure.
How caching works, and why the player decides your reliability
Ahead of time, the player asks the CMS what it is due to show and downloads it. How far ahead it looks is a CMS setting; the default looks roughly two days ahead. Files no longer needed are cleaned up automatically after a period, so local storage does not grow without limit.
Two consequences.
Your offline endurance is roughly your cache window. A player holding the next couple of days of scheduled content rides out an outage of about that length with no visible change. Beyond that it keeps playing what it has, but content scheduled to begin later, and any change you made in the CMS during the outage, has not reached it yet.
Reliability lives at the site, not in the CMS. The CMS being reachable matters for updates and only for updates. Playback is a local matter between the player, the display and the mains socket. When a screen goes dark, the site is almost always the cause.
There is also a push channel alongside the polling. For an urgent change, a schedule update, or pulling a promotion that has gone wrong, the CMS pushes a message telling the player to collect now rather than wait for its next interval. That channel needs the connection too. During an outage your changes are queued at the CMS, not lost.
The licence re-check on commercial players
One honest caveat, because it catches people out at exactly the wrong sites. Commercial Android and LG webOS players re-check their licence over the internet periodically, roughly every 30 days. If that check cannot happen, the player keeps playing its cached content but stops downloading new content.
For a café with flaky Wi-Fi that reconnects several times a week this is a non-issue; the check happens whenever the network is up. For a genuinely disconnected site, a vessel, a remote industrial installation, a screen on an isolated network by policy, it needs planning. Give the player a scheduled connectivity window (a phone hotspot once a month is enough), or talk to us first.
If you are planning a permanently offline deployment, email info@myeasycms.com or call +48 509 937 137 and describe the site. We would rather scope it properly than have you find the constraint after the player hardware is mounted.
Designing a playlist that degrades gracefully
None of the above is a limitation you have to live with. It is a design brief.
Keep a cached fallback in every rotation. At least one plain image or video that always plays, always works, and says something worth saying about your business. When everything else fails, the screen still looks intentional.
Never let a live widget own the whole screen. Put the weather, the ticker or the dashboard in a region, with cached content around it. A blank corner reads as a design choice. A blank screen reads as a fault.
Put perishable content where a gap is survivable. A live queue number has to be right or hidden. A social feed can simply be absent for an afternoon. Rank your live elements by how much a stale version would embarrass you.
Test by pulling the cable. On the bench, before installation: unplug the ethernet or forget the Wi-Fi network, then watch a complete loop twice. Ten minutes finds every dead region, and it is the most valuable ten minutes in the deployment. Repeat it whenever you redesign a layout.
What one dead screen actually costs
Do this arithmetic once with your own numbers. It changes what you are willing to spend on a network cable.
- A site visit. Someone’s half-day plus travel, to press a power button or re-seat an HDMI lead. Remote monitoring avoids most of these by telling you what is wrong before you drive.
- The missed promotion. The campaign, the menu change, the price update, none of it ran. If the screen was worth installing, that window has a value.
- Staff time and trust. Someone noticed, reported it, chased it. After the second failure staff stop reporting screen problems at all, which costs far more than the screen.
Set that against the fixed costs in our cost per screen breakdown. One prevented site visit usually pays for the ethernet run.
A checklist for sites with unreliable Wi-Fi
Most “the signage is unreliable” complaints are network complaints wearing a costume. In rough order of impact:
- Run wired ethernet wherever you can physically reach. It removes a whole category of fault permanently, and if an electrician is already fitting a socket behind the screen, the extra cost of a data drop is small.
- Never use the guest network. Guest Wi-Fi usually sits behind a captive portal expecting someone to click “accept” in a browser, and often expires sessions on a timer. A player will not click anything. Use a proper segment with unrestricted outbound HTTPS.
- Do a signal survey at the mounting position: behind the screen, with the screen mounted. A metal panel and a bracket sit exactly between the player’s aerial and your access point, and the difference is often two full bars.
- Reserve the IP address. A static DHCP lease per player makes the device predictable to find, to firewall and to talk someone through over the phone.
- Schedule a power cycle. A nightly or weekly reboot out of hours clears most slow-degradation faults before anyone sees them. Use a timer socket if the device has no built-in schedule.
- Turn on offline alerts so you hear about a dead screen from the CMS rather than from a customer.
When a screen goes dark, what to check first
In this order, because it goes cheapest and most likely first.
- Look at what is on the screen. Truly black, a frozen frame, “no signal” or the wrong content? Four different faults. A frozen frame is the player; “no signal” is a cable or input; the wrong content is scheduling, and nothing to do with the network.
- Power and input. The screen’s power, the player’s power, the correct HDMI input. After a cleaning shift or a power cut this is the answer more often than anything else.
- The Displays page in the CMS. A recent last-accessed time means the player is alive and talking, so the fault is downstream: the display, the cable or the layout. A stale one means a site problem.
- Request a screenshot. If the player is checking in, ask it what it is showing. That step alone decides whether anyone needs to travel.
- The player’s status window. On site, it names the problem outright in most cases, connection state, licence, recent errors.
From there, work the detailed checklists: troubleshooting offline displays for connectivity, and our 12 common digital signage faults for everything else.
The short version
Your player is built to survive without the internet, and it does: cached images, video, audio, PDFs and layouts play for as long as the power holds. What it cannot do is invent live data it never received. Anything fetched at play time is your exposure, and the fix is a design decision rather than a network upgrade.
Build a cached fallback into every rotation, keep live widgets inside regions instead of across whole screens, and pull the cable once before you install.
Every easyCMS account includes free expert support. See features, or email info@myeasycms.com with your site conditions and we will tell you straight whether the plan holds.