What a realtime player is, and why it changes the job

Two quotes came back for the same four screens. One of them has a line for four small boxes, one per TV, each with its own licence. The other says the televisions are fine as they are, and to open one web page on each of them. Neither quote explains why the first one needs hardware at all, so the boxes read as either the serious option or the upsell. Both quotes use the word player, and in those two quotes the word means two different things. They are not two prices for one product. They are two architectures, and the one you buy decides whether changing a price is an edit or a deployment.

A realtime player is a screen that holds an open connection and works out what to draw from your show and your schedule as it plays, instead of downloading a playlist and playing it from its own local storage. That one difference is where nearly every day-to-day annoyance in signage comes from, in both directions.

What is a digital signage player?

Search the phrase and the answers come back as hardware: a palm-sized computer in the HDMI port, one per screen, with its own licence and its own firmware. That is a correct description of a product, but it is an answer to the wrong question, because player is a job before it is an object.

The job has two halves. Decide what should be on this glass at this minute, and draw it. Anything that can do both halves is a player. A dedicated box does them. So does the browser already built into an Android TV, a Google TV, an LG webOS set, a Fire TV, a Chromebox or a laptop in kiosk mode. In ChannelOS the browser is the player: you open one address on the TV, a six-character code appears, and that is the whole installation. The detail of that, and the cases where a box is still the right purchase, is in do you actually need a digital signage player.

What is a digital signage CMS, and how does it decide what a screen shows?

This is the fork, and it is worth naming both sides properly rather than calling one of them modern.

Model one: push-and-cache. You build a playlist, you press publish, and the system distributes files down to every device. Each device stores them and plays from its own disk. The software’s job is distribution, the device’s job is playback, and the interesting number on the dashboard is a sync state: which devices have the current version, and which are still on last Thursday’s.

Model two: derive-and-listen. The screen holds an open connection and asks a single question continuously, which is what is on air for me right now. The answer is computed from the show, the schedule and the clock at the moment it is asked. Nothing is copied onto the device, so there is no version on the device to be stale. The software’s job is to hold one true answer, and the screen’s job is to keep asking.

ChannelOS is the second one. The realtime side runs on Cloudflare Workers and Durable Objects, which is the part you never touch and never configure. Everything else in this lesson follows from that choice.

How does digital signage update when I change something?

On push-and-cache, an edit becomes a delivery. You finish it, the platform queues it, and each device collects it on its next check. That interval is a setting, the device has to be awake, and a device that misses the window keeps playing the old thing perfectly happily. This is why those products have a status column at all.

On derive-and-listen, the screen is already listening, so there is nothing to deliver. Edit the show and every screen tuned to it repaints. The board’s one-tap controls, play, pause, blank, mute and next, reach the glass straight away rather than at the next poll, and an edit lands as fast as the screen can draw it. The three nouns underneath this, show, channel and screen, are laid out in how ChannelOS works.

One honest clarification, because the product does have a Publish button. Publish is how a show first reaches a screen, or goes onto a channel so it airs on a timeline. It is not something you press again after each edit.

Do I have to push content to each screen?

No, and the useful way to see what that means is to list the things that stop existing.

There is no publish queue to watch. There is no line on a dashboard counting how many devices are still on the old version. There is no walking to the one screen in the back room that did not get the memo, and no re-sending to all of them because you cannot tell which one it was. One screen and a hundred screens are the same single edit, which is the whole idea behind the name, covered in why it is called ChannelOS.tv.

Worth being exact about the free plan here. The derive-and-listen behaviour is not a paid feature: on the free plan you get one screen for ever, you push a show straight to it, and editing that show repaints the glass. Free screens do carry a disclosure, which is a ChannelOS banner along the bottom that opens into a full ChannelOS slide for about 30 seconds roughly every two minutes, then folds back. Any paid plan removes both. Channels and dayparting, which is where a schedule by hour and weekday lives, start on Solo.

How do I tell which model my signage is on?

You can test this on whatever you already use, in about a minute.

1. Open the show that is currently on air and change one price or one word. Keep it small and unmistakable, so there is no arguing later about whether the screen moved.
2. Leave the TV alone. Press nothing, do not reload the page, and do not wake it up, because each of those is the thing you are testing for.
3. Count the seconds until the glass shows the new text. Seconds is a derive-and-listen answer. Minutes, or never without a nudge, is a poll interval someone configured.
4. Look through the product for a per-device sync, version or last-seen column. Anything that has one is pushing content, because a system that computes the answer live has nothing to report there.

If the screen changed by itself and nothing in the product reports a device version, you are on derive-and-listen. If it needed a push, a sync or a reload, you are on push-and-cache, on an interval someone chose.

When is a media player box the better buy?

Push-and-cache exists for a real reason, and the reason is the network.

A ChannelOS screen that is already playing keeps playing when the wifi drops, and it keeps the show’s pictures and clips in the browser’s own storage so they are not re-downloaded every loop. What it cannot do is come back from a cold start on its own, because the page and the show are fetched fresh when the screen restarts. So a power cut at 3am on a site whose broadband is also down means a screen waiting for the connection rather than a screen playing yesterday’s board. A media player with local storage comes back with no network at all, and that is a genuine reason to buy hardware.

Three cases where you should buy hardware instead. A site with no wifi you would trust, or none at all. A metered or mobile connection, where a device that downloads once a week is cheaper to run than one that fetches on every restart. And a screen somewhere nobody visits, where a long outage has to be survived unattended. What happens in the minutes after a drop is when the wifi drops.

Everything else, which is most shops, cafés, gyms, clinics, offices and reception areas with ordinary broadband, is where derive-and-listen is the easier model to live with, because what you are buying is the absence of a distribution step rather than a faster one.

Next, the practical version of all of this: how to show the same thing on many TVs at once, which is one show, one channel, and as many screens as you point at it.