First off - I LOVE Xibo! We use it internally for our nonprofit to display messages to folks living in our facilities as well as displaying messages to customers at our local thrift store. Just thought I’d mention!
Onto the technical request. I am using non-recommended hardware to run several clients. I’ll post the specs below, but the issue is that all android clients becoming unresponsive after a period of time (2-3 hours) after running continuously. Additionally, the entire OS is frozen, requiring an onsite reboot. This is only occurring with the android OS (using Remix OS, have tried other PC-like android OSes with similar results), as I have an identical box running a windows client just fine.
Here are the specs:
Clients
Hardware
Zotac ZBOX CI320
Intel Celeron N2930 1.83GHz
4GB Memory
60GB SSD
Version/Software
Clients - 1.8
Server - 1.8.1
Remix OS 3.0.207
I do realize that since I’m not running on a recommended box that this could simply be some kind of incompatibility, but I am willing to play around with this to try and get the clients running stably, if anyone has any ideas. I can also retrieve additional info (e.g. logs), as requested.
I would suggest upgrading a unit that has the problem to R102, as that fixed a number of strange things for us. Has you also connected a unit that has the problem to a quality UPS to make sure dirty power is not the issue?
Thanks! I will give upgrading to R102 a try, as well as connecting a UPS to see if either of those resolve the issue. I also have a few other things I’m going to try out as well - I’ll post back what I found out.
There’s your problem. I haven’t gotten a stable version of RemixOS to work, you really need ‘their’ custom hardware (the for-profit behind RemixOS) for a stable, working version of RemixOS.
I would suggest starting from an AOSP binary for your particular hardware if you continue having issues.
So I scratched Remix OS and went with the generic Android x86. I reimaged the boxes with that and added the R102 ver of the xibo for android client. I have 3 of those setup like that now - I’m going to monitor them and should know within a day or so whether this config is stable. I’ll update in a day just to confirm either way.
Thanks Peter! Sorry I haven’t responded back to your emails (they’ve been getting caught in our quarantine - we have some pretty overambitious email filters here).
On Friday, I:
Imaged all 4 zboxes to Android x86 6.0 R3, replacing RemixOS
Configured the newest xibo for android client (R102) on each of them
This morning, Xibo is reporting that each of them last checked in on Friday evening. Currently, they are unreachable at layer 3. I’m going to go onsite later today to see if they are actually frozen or if they are still rotating through the templates. I’ll check back in once I find out. Again thank you all for your suggestions and thoughts on this!
Yesterday morning, on a whim, I decided to forgo a wired connection and configured each of the 3 to connect wirelessly. This is how the one Intel ComputeStick is setup with RemixOS and it seems to work well (except for losing connection periodically, but I have an app that restarts it every 2 minutes or so).
This morning, 1 of the 3 is still up and responsive. The other 2 are completely frozen and the system is unresponsive. I checked the error logs in Xibo to see if anything showed up, and here’s what I found:
I don’t know if swapping them over to WIFI has anything to do with at least one of them working. The other 2 worked and lasted longer than the tests I ran while they were connected via a wired connection. Perhaps it’s some funky driver issue? But I am stumped as to why one of the boxes is still working and the others are not (they are all identical). The working one has a better WIFI signal than the other 2, which are further from the WAP, but I can’t imagine that’s the issue.
Any thoughts or suggestions?
My ace in the hole is to purchase windows licensing for each of them and use the windows client, but I’d prefer not to for various reasons.
Seeing those memory notifications (knowing that they are not necessarily abnormal), I decided to go through the boxes and remove unneeded apps. I also peeked at the memory utilization stats and saw that Google Play Services was consuming about 95% of available memory (I think there’s 4GB) and is running continuously. I did not register the device with google play services, so I tried to remove it or force it to stop running, but those options are disabled, so I’m looking at ways to do that now.
You can issue the XMR rekey command (on Displays page → edit display → advanced tab), other than there seem to be only those memory notifications - which could be a problem, if there is a lot of them.
hm, that’s rather odd, I don’t think you’ll be able to remove it ‘normally’, as google services are very deeply integrated with Android.
I came in this morning to find all 4 of them locked up again. I checked the logs and there’s nothing in them.
I think I might be at the point of realization where this just isn’t going to work on that hardware. I’m happy to take other suggestions, of course, and I’ll try anything at this point, but I think I need to simply move to a Windows OS for these boxes.
I think they were all based off of android x86 6.x. I attempted some various mods of android x86 - Remix OS, Phoenix OS, and also tried android x86 itself. All operated normally for extended periods without Xibo for Android, but would freeze after a few hours of continuous use of that app. I do have a Remix OS in production based on the android x86 6.x. It’s running off a different box (an Intel ComputeStick). The only issue I had with that was the wifi connection would regularly drop within 5 minutes. I resolved that initially with an app that would reestablish any loss in connection every 2 minutes, but permanently solved it by updating to the moist recent Remix OS version and Xibo for Android client.
For the one’s I had issues with (the ZBOXes), I’ve given up deploying android builds and went with some Windows 8.1 w/Bing licenses I had that were unused. Not ideal, but they are all working just fine now. I’ll re-purpose my android client licenses with new boxes, once we add onto the current system (which is the plan within the next year).
We had simular issues with android in the past so we just scheduled an auto system restart at 4am and it prevented this issue from happening… we never actually found the cause of the issue, or looked that hard into it if I’m honnest…
I am however having a problem where on android the player is frame freezing.It doesn’t happen until the end of the second cycle of the playlist or so. Once it has frozen the application and os respond, only content sticks.
We disabled Surface Rendering because of gave us better results loading beteen videos… (no noticeable lag) and that’s when the issue occurs. When we enable it it seems to be working fine but the lag is too noticeable… we are running on an s905 board with android 6.0… any solutions would be greatly appreciated.
We have faced the same issue and until now we’re looking for some solution, has anyone have a temp fix for this? I have tried to scheduled multiple restarts but seems that it still does the same.
If the CMS is in 1.8 series same as the player and XMR is correctly configured then there should be no issues like that - it might be sometimes necessary to issue rekey action after some configuration changes, but that’s all.
Regarding the above, since you’re using 1.7 series CMS, you don’t have the XMR and since you’re also using 1.8 series player that would love to connect to XMR, you get those errors.
That should not cause layout playback issues, but you can’t fix it in this combination - you’d either need to upgrade the CMS to 1.8.2 and configure XMR or downgrade the player to 1.7R64 and it won’t want try to connect to XMR.
