Updating Players and Keeping Versions in Step

Two pieces of software matter here: the CMS you log into, and the player app running on each screen. They are updated separately, and they need to stay roughly in step. The short version is that we look after one of them and most of the other, so there is less for you to do than this article’s length suggests.

Who updates what

The CMS is ours. easyCMS is hosted, so you never update, patch or back it up. We do that, and we tell you when a release changes something you would notice.

Android and LG webOS players are ours too. These update centrally: a player build is loaded into easyCMS once and assigned to the settings profile your screens use, and each player then downloads and installs it during its own update window. Because that assignment happens on the profile your account shares, it is a change we make rather than one you will find in your own menus. Tell us when you want a network moved and we will schedule it.

Windows players are yours. There is no central push for Windows. The installer runs on the machine, so plan for remote access or a site visit.

Good to know That split decides whether a hundred screens is a phone call to us or a hundred site visits. Worth knowing before you plan a rollout.

The version rule

Run players on the same major version as easyCMS wherever you can. That combination gets the full feature set and is the one we test.

The previous major version still works. It keeps receiving security fixes rather than new features, so it is a reasonable holding position for screens that are awkward to reach, not an emergency. Going back further than that is where things genuinely break.

What drifting looks like in practice:

Newer widget types render as blank areas on older players.
Something you configure in easyCMS quietly does nothing on the device.
In the worst case the player rejects a layout and falls back to whatever it can still play.

If a layout works on one screen and not another, compare their player versions before you change anything else. Open Displays and show the player version column, then sort by it, drift is usually obvious at a glance.

Before a major version jump

On Android and LG webOS, moving a screen to a new major version can require a licence entitlement rather than just a download. Ask us before planning one, so nobody discovers it mid-rollout. Windows players have no licence to worry about.

Rolling out without breaking a network

Pilot on one screen. Something you can physically reach, and ideally not the one customers look at.
Give it a day. Version problems show up in the first day of real scheduling, not the first ten minutes.
Go in batches. Ask us to move a subset first rather than the whole estate at once.
Check afterwards. Every player should report the new version and be checking in normally. If one does not, tell us before moving anything else.
Avoid the week before a campaign. No update is more urgent than a screen that already works.

When an update goes wrong

A screen will not start, or went dark after an update. Send us the display name and what it shows and we will roll that screen or that group back. Do not try to reinstall over the top of a broken smart-display player, it usually makes recovery slower.

The player is online but nothing plays. Usually a layout that a changed widget has made unplayable rather than the update itself. Read the player status window and check whether the layout is still valid.

A Windows player will not launch after updating. Reinstall the version that worked, confirm the screen is playing again, and then tell us what happened before retrying.