Got a remote venue with 17 displays.
Upgraded CMS to the latest v1.7.6.
Rolled out remote upgrade for all the clients to player v1.7R59 according to the docs.
Seems that the upgrade went through, but the clients (all of them) keep restarting themseves. In the audit logs I see this:
function OnUpgradeReceiver - onReceive, message Application Upgraded, restarting. requestUri /xmds.php?v=4
All players are Minix X7.
On the displays all they see that it’s flashing back and forth between Xibo’s black default screen and Android’s desktop.
No content is displayed. Remote screenshot shows only the black default screen. Any help please?
I have remote access with ssh to the displays, using am force-stop uk.org.xibo.client I can stop the client, and using am start uk.org.xibo.client/uk.org.xibo.player.Player I can start the client just as if I would click on the icon - but it’s still the same.
I tried remotely rebooting the android box completely - still - the Xibo client app is in a restart loop.
What can I do to fix this?
Is there any local cache file I could delete on the player itself, or something in the CMS database to fix?
Assuming that upgrade failed:
So it tries to upgrade, fails and restarts the app.
Could you please check if SuperSU / superuser app is set to remember to grant permissions for Xibo?
Grant it indefinitely and un-tick the Re-authentication.
failing that (or if you can’t do that at the moment) - please unassign the apk file from the device (in CMS) and delete the apk from the library, should also stop this loop of endless restarts.
The upgrade didn’t fail, because at version information in the CMS i see R59 properly at each display.
I only have remote SSH access to the Android boxes (I’m at 200km away from them), I don’t see how I could interact with superSU.
As far as I remember, I ticked it to remember permissions forever for all the boxes.
Last time when I upgraded, I had no problems whatsoever, so I don’t think it has anything to do with SuperSU by itself.
I unassigned the APK, and deleted it from the server, but the loop still continues. I restarted manually the app (with comands above), but still looping.
Note, the upgrade seems to be gone through well, but somehow the app thinks it has to restart itself over and over again.
There’s a bug in the Android player app.
Deleting /data/data/uk.org.xibo.client/databases/XiboForAndroid.db and XiboForAndroid.db-journal seems to fix the restart loop.
I guess that normally, this should happen automatically during upgrade…
I am glad that it’s fine now, although it is a really odd behaviour.
Could you please tell me if you have only ‘normal’ apk installed on your devices?
Or do you have White labels installed on it as well?
White Label Xibo for Android is a different application as far as Android is concerned, so if you have two types of applications installed and both are set to automatic restart they will ‘fight’ to be on top (ie. one closes other reopens etc).
OK, what I did remotely with SSH on each box was this:
su
am force-stop uk.org.xibo.client
rm /data/data/uk.org.xibo.client/databases/XiboForAndroid.db
rm /data/data/uk.org.xibo.client/databases/XiboForAndroid.db-journal
ls /data/data/uk.org.xibo.client/databases/
am start uk.org.xibo.client/uk.org.xibo.player.Player
I have SSHelper.apk installed on each Android player box granted with root permissions. This was a lifesaver.
Did you already get rid of those .db files on all of your devices?
It could be good if we could have a look at them, if you didn’t delete all of them yet.
only once, at the time when I lastly started the app with my am start command. Not a single mention in the “Recent log” until this, the last line before this dates back to the moment when I rolled out the update.
Oh, and now I see in the “Recent log”, that on 4 out of them, I had repeated entries of OnUpgradeReceiver - onReceive Application Upgraded, restarting. during the first hours. The entry repeats itself abut every 10 seconds (seems that a self-restart cycle took about 10 seconds). The rest of the players have only one entry, which appears right after I fixed the issue by deleting the db file.
