How XMDS works: the protocol behind every Xibo® display

XMDS is the protocol every Xibo® player uses to talk to the CMS. It handles the whole life of a display: registering itself, being authorized, collecting its schedule and media, and reporting back what it did. If you understand that loop, you can diagnose most signage faults without ever opening a log file, because nearly every fault is a step in this loop that didn't complete.

It matters to us specifically because XMDS is what makes XiPlay possible. Xibo Signage Ltd. does not publish a BrightSign® player, but the protocol is what a player must speak, not the vendor. XiPlay implements XMDS (v3 and v4), which is why a BrightSign® player running it appears in your Xibo® CMS as a completely ordinary display.

The lifecycle, step by step

A player's entire relationship with the CMS is a repeating cycle. Laid out plainly:

1. 1 Register. On first contact the player tells the CMS who it is: its hardware identity and its configured CMS key. At this point the display exists in Xibo® but isn't trusted yet.
2. 2 Authorize. A human authorizes the display in the Xibo® CMS. Until that happens, the player is known but receives no content. This is the single most common reason a freshly set-up player sits there showing nothing: it registered fine, and nobody authorized it.
3. 3 Collect the schedule. The player asks what it should be playing, and when. Scheduling logic (dayparting, priorities, display groups) is evaluated by the CMS, not the player.
4. 4 Fetch what's missing. The player compares the media the schedule requires against what it already has cached, and downloads only the difference. This is why the first collect on a new display is slow and every subsequent one is fast.
5. 5 Play locally. Rendering happens entirely on the device from cached files. The CMS is not in the playback path at all.
6. 6 Report back. The player submits status and playback records, which is what makes proof-of-play and last-seen monitoring possible.

The insight most people miss

Look at step five: playback is local. The CMS is consulted to decide what should play and to supply the files, but once the player has them, it does not need the CMS to keep playing.

The network is in the update path, not the playback path. That single architectural fact is what separates a screen that survives an outage from one that goes black.

A player that treats the network as part of the playback path (streaming each asset, or checking in before each play) has no answer when the connection drops. A player that treats it as part of the update path simply keeps looping the last thing it collected. XiPlay is deliberately the second kind: an outage pauses the collect cycle, never the screen.

Debugging with the lifecycle

Once you know the loop, faults sort themselves into it:

• ✓Player shows an activation screen and nothing else → it hasn't completed register/authorize. Check the CMS address, the key, and whether anyone authorized the display in Xibo®.
• ✓Display appears in Xibo® but the screen is blank → registered and authorized, but nothing is scheduled to it, or the collect hasn't run yet.
• ✓Content is stale after you changed the schedule → the collect isn't completing. The player is playing happily from cache; the problem is the network between it and the CMS.
• ✓Content plays at the wrong time → not an XMDS problem at all. Scheduling is evaluated by the CMS in the display's timezone, so check the timezone set on that display.

v3 and v4

Xibo® has more than one generation of the protocol in the field, and a player that only speaks one of them limits which CMS you can point it at. XiPlay implements both v3 and v4, so it works against your current Xibo® server and keeps working when you upgrade it. The player is not the thing that pins your CMS version.

Why this is good news for hardware choice

Because XMDS is a protocol rather than a product, the question "what can drive my Xibo® CMS?" has a wider answer than the official player list suggests. Any player that implements XMDS correctly is a first-class Xibo® display. That is the entire premise of running Xibo® on BrightSign® hardware: you keep the CMS, the layouts, the schedules and the display groups you already have, and change only the box behind the screen.