I am running the Android player (v 1.8 v102) playing a simple 1080p video layout and the player will crash after a few hours.
I can’t for the life of me figure out how to make it stable.
I see error messages like:
Unable to start XMR queue: class d.cp/java.io.IOException: pipe2 failed: EMFILE (Too many open files)
and
Unable to start XMR queue: class java.lang.NullPointerException/Attempt to invoke virtual method ‘int java.lang.String.lastIndexOf(int)’ on a null object reference
It seems to crash with the Too many open files messages. Could it be a problem with the schedule? Is there a way to disable XMR?
I am using an EgoIggo E9s 4k
CPU: S912 Octa core Cortex-A53
2GB DDRIII
16GB emmc ROM
Android 6.0
The CMS was installed with docker (version 1.8).
The layout is a single video that is running perpetually (Mp4). I have it scheduled using Dayparting (always on) with no repeats set. The same layout is also set as the default layout, but that shouldn’t affect things if it is running the schedule, right?
No, I don’t think that you’ve done anything wrong - although if it is set as default layout then there is no need to also schedule it.
That being said, we recommend the default layout to be something rather simple and light on content (not necessarily videos) then to schedule heavier layouts.
You might need to enable auditing for that display (Displays page -> edit display -> advanced tab), for it send more logs to the CMS, I’m quite sure there will be some other issue than only XMR related logs.
Speaking of XMR, if it’s docker installation, then you should only need to edit the XMR Public Address in CMS Settings -> Display
it should be set to tcp://your.ip.address:9505 or tcp://your.domain.name:9505
After you do that you might need to send rekey action to the player (Edit display -> Advanced tab -> Reconfigure XMR)
and perhaps restart Xibo for Android on the device.
I am also doubtful that this relates to XMR - at least not directly. It looks like something (perhaps Xibo, perhaps not) is consuming all allowed file handles on your device.
A screenshot of the status window and some extra logging might point us in the right direction.
The client will unexpectedly quit every once in a while (and we need it to run perpetually). I will try and get a screenshot of the Android Status window. I have the audit level loggin turned on at the CMS. Where else should I be looking?
Lets take XMR out of the equation entirely but clearing the “public xmr address” from your CMS settings. This means the player won’t try to connect to XMR at all.
In the CMS you need:
A display profile for auditing, assigned to this display (or edit the default display profile if you only have 1 display)
Set “auditing” on the Display itself
Global auditing should be Off or Error so we don’t get noise
Truncate your logs to get a clean set
Then you will need to let those logs collect up until they cover the an occurrence of the issue, and then give us access somehow
If I set auditing on the display, will it show any data in CMS logs while it is collecting the data from the display? I don’t see anything in the CMS logs yet and I turned on the auditing in both the profile and the display. Global is set to error.
Thanks again for all of your help with this; I am trying to get to the bottom of this.
I can’t seem to get logging working properly on the CMS. I have logs and auditing turned on for the display, and logging is set to error on the CMS. I can’t figure out how to actually get the logs recorded, as the appear blank on the logs page of the CMS. Is there a tutorial or post which shows how to set this up properly?
If you’ve enabled auditing on the display and assigned a display profile with auditing to said display, then, assuming that this display is logged in to the CMS it definitely should send logs to it.
Perhaps it’s just a case of filters on the Logs page?
Perhaps you could adjust the interval and duration back?
Hi Peter,
I had it set to audit. However, I still see no log files. The display Xibo app crashed twice this morning already. I am going to try and shut down some other Android apps that are running and see if that helps. Is there any setting that will cache the video file on the player so that it does not keep trying to download resources?
If it’s video that player downloaded from the CMS, then it should be in the player local library and player should not attempt to download it again - if it does that, then that could imply an issue with the storage on the device.
I also checked the Android App settings on the player for Xibo and noticed that the permissions were not allowing it to access local storage. I switched this on and will see if this helps with the issue.
