When an edit lands while screens are playing, the player needs a rule for the swap. Finish the current loop and apply the new revision at the next loop boundary: on a 12-item playlist of 10-second images that is a 120-second worst-case wait on top of one poll interval. Keep a force refresh for mistakes such as a wrongly scheduled 30-minute video.
You change a price on the menu playlist at 10:07. Six screens are playing that playlist and each one is somewhere inside the loop. The edit is already safe on the server; what is undecided is the moment each screen swaps to the new revision. Players handle this four ways: switch at once, finish the current item, finish the whole loop, or a mix of these. The rules differ in exactly two things: how long the edit takes to reach the glass, and whether something a visitor is reading gets cut off. This page puts numbers on both, then gives a default: swap at the next loop boundary, interrupt only for items the new revision removes, and keep a force refresh for genuine mistakes.
Two waits, not one
An edit reaches the screen in two stages, and both have to be counted.
Delivery is how the revision gets from the publishing tool to the player. Most systems poll: the player asks for changes on a timer. The operations guide of one large enterprise signage director sets the default poll at 120 seconds, and cloud platforms commonly poll on similar minute-scale timers; your own CMS prints its interval in its settings. So a save can sit unseen for up to one poll interval, 120 seconds on that default.
Application is the rule the player runs once it holds the revision: switch now, or wait for an edge. The two waits add. A 120-second poll plus a 120-second loop means an edit is on screen within 240 seconds, 4 minutes, at worst.
On the IMD Signage Player the delivery stage is the optional HTTPS sync, which pulls a playlist from your own web server on a timer; the timer you set is the delivery wait. A screen with no network at all needs another road for the files, and one is updating it through a phone hotspot. How long playback lasts once updates stop arriving is a separate question with its own answer, covered in offline schedule caching: how long playback lasts.
The four apply rules
Switch at once. The player jumps to whatever the new revision says should be on screen. Nothing waits past the poll, so this is the fastest rule and the only one that can cut a slide or a video in half. A visitor loses the sentence they were reading, and two screens that polled a minute apart show different items for that minute.
Finish the current item. The player lets the slide or video on screen run out its old duration, then starts the new revision at the next item edge. The extra wait is bounded by the longest item: a 10-second slide costs at most 10 seconds, a 20-second clip costs at most 20. Players usually fetch the next file ahead of time so an edge swap starts without a gap, and an edge is exactly where that file is ready.
Finish the loop. The player runs the old revision to its end and starts the new revision from the top at the loop edge. The extra wait is bounded by the whole loop, so this is the slowest rule that never cuts anything. What it buys is shape: every swap lands on an item edge, so nobody anywhere sees a slide or a video stopped early. The first screen the new revision shows is set when you publish; choosing the playlist's first screen at startup covers that pick.
The hybrids. Two earn their place. Interrupt when removed: run finish-current-item normally, but if the new revision has dropped the item on screen, cut at once; that is the rule for pulled promotions and withdrawn notices. Force refresh: a person triggers the swap from the publishing side and the player cuts whatever is playing; that is the rule for mistakes.
Side by side
| Rule | Cuts an item mid-show | Wait after save, worst | Wait, average | Best for |
|---|---|---|---|---|
| Switch at once | Yes | one poll, 120 s | 60 s | Takedowns, wrong or unsafe content |
| Finish current item | No | poll + longest item, 130 s | 65 s | Single screens with short items |
| Finish the loop | No | poll + loop, 240 s | 120 s | Estates that must stay smooth |
| Interrupt if removed | Only the removed item | at most 130 s | 65 s | A pulled item that must vanish |
| Force refresh | Yes | one poll, 120 s | 60 s | The wrongly scheduled long video |
The numbers assume the cafe loop below: a 120-second poll and a 120-second loop of 10-second slides. A save landing at a random moment leaves on average half the poll interval and half the loop or item to run, so each average is half its worst case plus the shorter remainder.
Where each rule wins
Scheduled changes. Breakfast to lunch menus, opening hours at 17:00, a weekend promotion: none of these should interrupt anything. Publish the revision with a start time that falls between services, and the swap is invisible no matter which rule the player runs. Players without dayparting, ours included, keep only a daily on time and off time, so the timed swap belongs to the publishing side.
Estates that must stay smooth. A museum floor, a transport concourse, a row of shop windows: the audience is always mid-read somewhere, so finish the loop. Holding many screens on the same item at the same moment is a stricter job again; why sync-group screens play video out of sync covers that.
Corrections that must land now. A wrong price, an item pulled by the supplier, a notice that is no longer true: switch at once or interrupt when removed, and treat the cut as the cost of being correct.
Mistakes. A 30-minute video scheduled into a loop of 10-second slides: force refresh, then fix the schedule.
Single screens with short items. Finish the current item and nothing more is needed; with 10-second slides the whole difference from finish-the-loop is 110 seconds.
Example: a 12-item cafe menu loop
A cafe runs one playlist: 12 slides, each held 10 seconds, built in the card builder from images prepared as in preparing images and video for a sign. One loop is 12 x 10 s = 120 s.
The manager corrects a menu item at 10:07:00. Delivery takes 0 to 120 s on the 120-second poll. Application takes 0 to 120 s more, because each screen finishes its current loop first; on average that is 60 s. Worst case from save to glass: 120 + 120 = 240 s, 4 minutes. Average: 60 + 60 = 120 s, 2 minutes. No slide is cut, on any screen.
Now the bad save: a 30-minute training video, 1800 s, scheduled into the loop by accident. The loop becomes 11 x 10 s + 1800 s = 1910 s. A boundary swap now waits up to 1910 + 120 = 2030 s, about 34 minutes, with the wrong item filling most of every loop. This is the case the force refresh exists for: one poll, 120 s at worst, and the wrong video stops. The cheaper prevention sits on the publishing side: anything longer than 60 s in a loop this short gets a second look before it is scheduled.
How long a loop you can afford
Decide the longest time an edit may take from save to screen; call it T. Subtract the poll interval P, because delivery eats its share first. The loop must fit in what is left: L <= T - P.
Say edits must be visible within 5 minutes, T = 300 s, and the CMS polls every 120 s, so P = 120 s. Then L <= 300 - 120 = 180 s. At 10 seconds per slide that is 180 / 10 = 18 items. The cafe's 12-item, 120-second loop sits inside it with room to spare, which is why that example lands in 4 minutes.
If your publishing tool pushes revisions instead of waiting for a poll, the whole budget goes to the loop, and the same 5-minute promise allows L = 300 s, or 30 ten-second slides. The longest single item sets the finish-current-item wait, so cap long videos at the loop length you chose and route anything longer through the force-refresh path.
The decision
Finish the loop is the default for looping playlists on more than one screen: nothing is ever cut, every swap lands on an item edge, and the cost is bounded by one loop. Finish the current item is enough for a single screen with short items. Switch at once is for content that is wrong or withdrawn and cannot stand for one more second. Interrupt when removed turns a takedown into an immediate event without touching anything else. The force refresh is for the mistake case.
Recommendation: Set players to finish the current loop and apply the edited playlist at the next loop boundary, add interrupt-when-removed for items the new revision drops, and keep a staff-triggered force refresh for everything that must stop now. Size the loop to the promise: keep L at or under T - P, which with a 300-second budget and a 120-second poll means a loop of 180 seconds, 18 ten-second slides. On the cafe's 12-item, 120-second loop, every edit reaches every screen in at most 240 seconds, average 120, with no item cut.
Questions
Do screens that started at different times end up on the same item after a boundary swap?
No. Each screen reaches its own loop edge and starts the new revision there, so screens that were an hour apart in the loop stay an hour apart. The swap gives every screen the same revision and a clean item edge, and that is what boundary swapping promises. Getting many screens onto the same item at the same moment is a separate job, done by starting the loop together as a sync group, and it holds only while the screens keep step.
What happens to the item on screen when an edit changes its duration?
With a finish rule, the old duration runs out first: a slide held 30 seconds in the old revision keeps its 30 seconds even if the new revision says 10. The new duration applies from the next item or the next loop. So a shortening edit takes full effect one boundary later, and the wait rules on this page already cover that boundary. Build the same rule into your player and a duration change can never surprise a viewer.
Does the wait grow when the estate has a hundred screens instead of one?
The two waits, one poll interval and the rest of the loop, are the same for one screen or a hundred. What grows is the window in which some screens already have the new revision and others are still on the old one, which on a 120-second poll lasts up to two minutes. A swap pinned to a loop boundary keeps that window dull: every screen shows a whole item throughout, so a visitor walking past two screens sees no break.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.