Player lost license and settings

Have a player running R59 for 8 months. CMS is version 1.7.8. Player stopped playing everything and only showed the default layout.

In the CMS the player was no longer part of the group it had been assigned to and no one removed it from the group, as I am the only one with access. I added it back to the display group, and restarted the Android unit. Still the same problem.

On the player, even though Spring Signage showed it was licensed, it claimed it was not. Removed the license from Spring Signage. Changed the license setting in the CMS to No, save it, changed it back to yes, and saved it again. Restarted the Android unit, still the same problem.

Pulled up the hardware license on the Android unit, changed nothing and re-saved. Unit then started to download all of its content.

Any idea why of how this could happen?

1 Like

Not that I can think of off the top of my head. There’s nothing in the CMS that would remove a Player from a group automatically.

The Player claiming it wasn’t licenced even though there was a record for it could simply be that it hadn’t had connectivity to the outside world for a period of more than 30 days, or the time and date being wrong on the device.

R59 uses an older HTTP library which can get the Player in to a state where it can’t connect to anything, even if the wifi or lan connection is up, over a long period of time. R61 uses a different approach and in places where that has been problematic the results have been good, so that would be my suggestion. That doesn’t explain the changes in the CMS. Does the audit log show anything?

We will surely update to R61. The log in the CMS only shows some items from today, and they are unrelated.

The date and time we checked and it was correct. We even restarted the unit several times, with no change.

Just seems weird that the unit thought it was no longer licensed and in the CMS it was removed from a display group. The hardware key was not changed either. The only thing that in some strange way could be related is that there was a previous screen with the same name in the Spring Signage license pool, that expired some time ago, and had yet to be removed. And in the Spring Signage portal I saw that the newer unit had checked in right before the problem started. But I really can’t see how that could be related.

Thank you Alex for the info on differences of R59 to R61 in respect to connectivity reliability.

It might be useful to make clear for others who might be reading this that there isn’t any link or correlation between the Spring Signage Portal Licence and the CMS licence - they are completely unrelated. In fact we’ve taken steps in 1.8 and renamed the CMS licence to “Authorised” which better represents what is happening.

Unfortunately I too have no idea what could cause a display to be removed from its display group without that transaction occurring through the user interface - particularly in 1.7 (in 1.8 we have dynamic display groups which could explain it if the display name changed).

I do recall you mentioning that this happened once before, and that time too we said that we didn’t know how it could have occurred.

There are two places in the 1.7 code that DELETE FROM lkdisplaydg which is the link table that assigns displays to groups. One of these is in the display delete code - so we can rule that out as the display still existed. The other is unlink which gets called by Display::SetMemberOf and DisplayGroup::SetMembers, which are the routes that get executed when the members forms are saved on the Display and DisplayGroup pages respectively.