A cloud signage player that has downloaded its media and schedule keeps playing with the network down. Playback ends when the cached schedule runs out, and the default layout takes over. The cache window follows the schedule look-ahead setting, 2 days ahead by default in common setups, with the player expected to check in every 15 days.
You publish a week of content through a cloud CMS, the site's router dies, and one question follows: how long does the screen keep playing? A player that has already downloaded its media and its schedule keeps playing with no internet. Playback reads from the device's own storage, so the outage changes nothing at first. What ends scheduled playback is not the outage. It is the cache window: the device only holds schedule data a fixed distance ahead of its last successful check-in, commonly 2 days. Once that window is spent, the default layout takes over. This page explains both clocks, works the arithmetic for a weekend outage, and shows when a card-fed player with no window at all is the better fit.
What the player holds when the network drops
A cloud CMS player downloads two things while it is online. The first is media: the images and video files the layouts use. The second is the schedule itself, the list that says which layout plays at which time. Both sit on the device, which answers a question that comes up often: yes, the schedule is downloaded too, and that is why an outage does not blank the plan.
While the network is down, playback runs from that local copy. Playing a cached schedule needs no connection. Two clocks can still end it. The first is written into the schedule: an event ends at its scheduled end time, for example 21:00. The second is the cache window, which decides how far ahead the device knows the plan at all.
Power cuts are a separate interruption with their own behaviour. What a screen does when the supply returns is its own subject, covered in power loss recovery for offline displays.
The look-ahead setting decides the cache window
The cache window comes from a CMS setting usually called the schedule look-ahead; on CMS settings pages it often appears as "required files and schedule look ahead". It sets how far ahead of each check-in the player downloads schedule data, plus the media that data needs. The common default is 2 days.
The rule to plan with: scheduled playback lasts from the last successful check-in to that check-in plus the look-ahead. A screen that checked in at 22:00 on the 2-day default is covered to 22:00 two days later. Offline, that horizon is frozen. Events published on the server cannot move it, because the device has not heard about them. Only a fresh check-in extends the window.
Scheduled playback ends at whichever the device reaches first: the scheduled end time of the last event it holds, or that horizon. Either ending hands the screen to the default layout.
What plays when the cached schedule ends
The default layout, assigned to the display in the CMS, plays next. It is a real layout, not a black screen, unless you build it black. If the default layout's own media is missing, the player falls one step further, to its splash or startup screen, so it is worth checking the default layout's media before you rely on it.
Treat the default layout as the offline poster: opening hours, address, the core menu, the safety notice, content that is still true whenever the network next returns. That also answers the other common question, whether a display can run with no default layout at all. Assign one whose content you are happy to show for as long as the outage lasts. It behaves as the resting screen you chose.
Example: a café loses its internet on Friday night
A café menu board runs on a cloud CMS with the look-ahead at the 2-day default. The player's last successful check-in is Friday 22:00. The router fails at 23:00 and the line comes back on Monday at 08:00, so the screen is offline for 57 hours. A weekend brunch campaign is scheduled for Saturday 09:00 to 21:00, and all of its media was downloaded by Friday 22:00.
- Cache horizon: Friday 22:00 + 2 days = Sunday 22:00.
- Saturday 09:00 to 21:00: the brunch campaign plays in full, 12 hours on screen, entirely from the local copy.
- Saturday 21:00: the campaign reaches its scheduled end and no later event sits inside the cached window, so the default layout takes over.
- Sunday 22:00: the horizon passes and nothing changes on screen, because the default layout has been playing since Saturday evening. A Monday 09:00 event would have been unavailable either way, since Monday 09:00 lies past Sunday 22:00, outside the window.
- Monday 08:00: the line returns, the player checks in, and the new horizon is Monday 08:00 + 2 days = Wednesday 08:00.
Run the same outage with the look-ahead raised to 14 days and a fortnight of scheduled campaigns downloaded on the Friday. The horizon becomes Friday 22:00 + 14 days, the weekend plays as scheduled, and the default layout never appears. The 57-hour outage costs nothing on screen.
Recommendation: set the look-ahead above the longest outage you are willing to show the default layout through, and download media for every day in that window. With the 2-day default, budget on 2 days of scheduled playback per check-in. A café, salon or shop that cannot accept a weekend fallback should run 14 days of look-ahead with 14 days of media downloaded.
The 15-day check-in is the second clock
Players of this kind are commonly required to connect to their CMS at least every 15 days. The check-in does two jobs: it reports the display to the server, and it is the only moment the cache window can be extended. A missed check-in does not stop the screen. Playback continues from storage, and the CMS lists the display as not checked in since its last connection.
Which clock binds first depends on the settings. With the 2-day default, the window ends scheduled playback after 2 days offline, far inside 15 days, so the look-ahead is the number that matters. Raise the look-ahead to 60 days and the relationship flips: the screen holds 60 days of scheduled content, and keeping the server's record fresh means bringing every display back onto the network within 15 days.
A screen whose window has already expired can be revived without touching the router: a phone hotspot beside the screen is enough to check in and pull a fresh schedule, as updating an offline signage screen with a phone hotspot describes.
When the card is the schedule
Some screens have no reason to hold a live schedule: a factory notice board, an elevator lobby panel, a counter screen showing one menu. For those, the whole cache question disappears when the player reads its media from a card. A card-fed player has no look-ahead, no check-in and no default layout to manage, because no server schedule exists to expire. The card is the schedule, and playback continues until someone loads a new one.
Our player works this way. It is included with our panel-mount displays, with no subscription. It plays images and MP4 video from microSD or USB with no network, and it keeps a copy in internal memory, so the show carries on when the card comes out. Rotation between portrait and landscape is one setting. If the app stops, it is designed to start again within seconds and go back to playing. A daily on time and off time is built in. Timed switching between a morning, lunch and evening playlist is not offered, so a screen that must change content by the clock is the CMS case from the sections above. On a card, the way to get timed changes is to build the sequence into a single video, with the content switching at the right minutes.
The basics of choosing between the two models are in offline or cloud signage: how to choose. For the card workflow, setting up offline playlist autostart covers the power-on behaviour, and the details of what the player reads are collected on our signage player page.
Questions
Can I change the content while the screen is offline?
No. With the network down there is no path from the CMS to the device, so the screen plays the schedule it last downloaded. Changes you publish wait on the server until the next successful check-in. This is why the look-ahead matters: it decides how much future the device already holds when the connection goes.
How far ahead can the schedule look-ahead be set?
It is a setting in the CMS, not a fixed limit. Set it past the longest gap between check-ins you are willing to ride out, then confirm the CMS has downloaded media for every day in that window. A 60-day look-ahead with 60 days of media downloaded keeps a screen on scheduled content through a two-month closure. The costs are storage on the device and a longer first download after you assign the schedule.
How much storage does a long cache window need?
Add the file sizes of every layout in the window. Example: a menu board of 20 JPG slides at 2 MB each plus one 3-minute MP4 at 30 MB comes to 70 MB per day of unique content. Thirty days of daily menus at that size is 70 MB x 30 = 2.1 GB. Leave headroom on the device for the system software and the schedule data.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.