Hello.
I have a suggestion that can streamline the configuration of new players.
Make available the option of adding players in the CMS before it add the network.
The CMS should offer the possibility of generating a hardware key automatically or manually.
With this player created in the CMS and hardware key ownership, add the same key to the player android for it to be recognized and start to be updated.
This will enable the preconfigure players leaving just plug it into the network at the time of installation.
This way the user could set up the entire network in advance creating the players beforehand.
So it would be enough to go to each establishment connect to the internet and add the key and wait for the download.
Regarding the key to complexity, when using a mini USB keyboard would not be difficult to enter the CMS can offer the ability to print a list of players and their keys.
Another thing “something I already do” is to change the key of a single code for each player, for example, 001, 002, 003. so whenever I need to replace a player I just change the hardware key by code that already It exists in the CMS and this new player will take the place of the former.
I have to change the hardware key as explained above because I had problems earlier where several players were detected with one, maybe because I use a rom restoration created with the basic settings and they clonavam the data used to create the key, or the players are Chinese and have a parameter used in the same key creation, or other reason, just know that this solved my problem. I do not use the hardware key automatically created.
It is complex to make it harder to guess, so that if someone is maliciously trying to brute force your CMS Player API (XMDS) they have a much bigger range of values to guess from. You could argue that if your CMS key is ultra-complex then you don’t have this problem.
That being said I don’t have any arguments against some sort of pre-provisioning system for advanced users.
I’m not sure adding a mechanism by which we encourage users to user hardware IDs like 001 is a good idea really. And hand-entering a complex ID is always going to be slower than the current register/authorise process.
If you want to setup scheduling ahead of adding your Player to the CMS, then you can do so by creating a Display Group and scheduling your content to that. The big advantage there is that if you subsequently replace the Player, then you only need to add the new Player and put it in the same groups as the original to restore the exact same scheduling as the Player had before it was changed.
The OP’s problem is definitely because they’re cloning the memory from one Player to another. Choosing codes like 001 is a really bad idea though as it reduces significantly the security offered by the XMDS webservice. You should use a long complex ID similar to the one generated automatically (unless there’s some other layer of protection there - eg the Players run on a private LAN, but even then I’d still prefer using a complex ID).