We had the reboot command working perfectly on our first test of xibo, which was hosted on the cloud.
We then progressed to hosting internally using docker (can’t remember the version but i think it was 1.8.3) and reboot didn’t work.
We then asked the question on here some time ago and was told to make sure XMR port 9505 is open which it is and is having data through it. We have also switched firewalls in the time that we’ve been trying to get this working.
Forgot to mention we are now on newest version of everything.
Today we tried again using the cloud and still the android box wont reboot.
We’re all out of ideas, last time you said XMR is working if you can get an instant screenshot. Which we can’t.
Any help would be appreciated, we really need this to work.
What you’ve written is correct. XMR is used for the reboot process too, so if your screenshots don’t come back straight away then it’s unlikely that XMR is working properly.
The Cloud setup should have XMR working correctly. The Players will need to be able to connect to port 9505 outbound, so perhaps something in your location is blocking that going through the firewall?
You can telnet to XMR to test connectivity.
telnet myxiboserver.domain.com 9505
You’ll see something like that if connection is possible. If it just hangs and times out, then something is blocking your access to XMR.
If the connection is possible, then next reset your XMR configuration for each Player. Edit the Display, and on the last tab, tick the box to reset XMR configuration. Then save.
Now wait for the Player to re-register with the CMS. Once it does, try screenshot again.
If that works, then your reboot command should work (providing your Display Profile has the correct command to reboot your Android device defined in it of course)
You need to enter the correct command in the “Command” box there (which is in Display Settings → Android → Edit)
Most recent Android boxes will want one of the following:
svc power reboot
am start -a android.intent.action.ACTION_REQUEST_REBOOT
setprop sys.powerctl reboot
reboot
Once you’ve completed that, save, then go over to the Displays page, run “Collect Now” to ensure the Player gets the updated command definition, and then it should respond to a reboot.
That won’t affect XMR. XMR can’t be run through an HTTP reverse proxy server, as it isn’t using the HTTP protocol. You need to expose the port it’s listening on directly to the Players.
I don’t know how long it will remain connected without you sending traffic.
It sounds like you just need to enter your IP in the XMR Address setting on the CMS settings page then
eg tcp://10.10.10.10:9505
rather than the address of your reverse proxy. Again, the Player will need to collect and pickup that change before it will connect to the new address.
Well we know XMR itself is working as intended because you can telnet to it. Is there a firewall between you and the XMR service somewhere? Perhaps that’s cutting you off.
Again, you’ll need to reconfigure XMR on the Display record to be sure that the Player and CMS keys are in sync.
Basic rule of thumb. If you disconnect a Player from a CMS and reconnect it, or reinstall the Player, then you need to reconfigure XMR to be sure that’s working properly.
The Player generates a key when it is first configured, and it sends the public portion of that to the CMS, which remembers it. If you then cause that key to be changed on the Player side, the key the CMS has no longer matches, which means the Player can no longer decrypt those messages from the CMS.
Re configuring XMR causes the CMS to forget the old saved key so it can accept a new one from the Player.
