Within our self-hosted Xibo CMS version 4.3.1, I noticed that our DSCS9X players running Xibo for Android v4 R408 regularly missed their heartbeats, and when displaying a webpage the following would appear on the screen: “ERR_INTERNET_DISCONNECTED”
Troubleshooting
Looking at the location of our players, most of them were located behind the screen and connected to our CMS over Wi-Fi. Initially it seemed to help ensuring the antenna was in direct view of the access point, but after observing for a while, the webpages still failed to load at random.
Then I checked if checking and unchecking the pre-load checkbox within the webpage widget would resolve the problem, but his however showed no noticable effect.
After a few hours of troubleshooting, I remembered about the display settings for the Android players, specifically looking at anything network related.
The actual problem & solution
It turned out that the option “Restart WiFi on connection failure” (under Display Settings → Android → Network) caused the players to regularly reconnect to the network, even when they had a stable network connection.
Disabling the “Restart Wi-Fi on connection failure” option resolved the issue with our Android players missing heartbeats, and pages now load perfectly.
Thank you for sharing this and for passing on that you found the issue was resolved when not using the Restart WiFi on connection failure setting in the Android profile in your CMS.
I will test this and see if I can replicate your issue, then I report this to the developers if necessary.
The player loading a layout containing a webpage widget that’s within a campaign. Details: The entire layout, along with the widget is set to 60 seconds. Within the campaign this layout will appear once every 4 minutes.
The player repeating the same default layout with the webpage widget. Details: The widget is set to 60 seconds. Layout duration variable depending on the playlist.
For the first one the error sometimes appears immediatly upon the layout being displayed on the screen itself. For the second one the error sometimes appears when the widget reaches the end of duration and loops over again.
In both cases, as long as the page loads sucesfully, it will continue to display for the entire duration. When they loop over, only then is there a chance it displays the error and continue to do so for the entire duration.
This problem can be reproduced with different webpages and embeds. I did not have this problem with a specific page.
Short version:
How often: At random. Could be every time the widget gets loads, or once in a while.
Recovery: Only when the widget reloads / When the layout is displayed again.
Duration: 60 seconds.
Thank you MrStefan, that’s all helpful information.
I have my DSCS9X on WiFi, running R408 and a webpage layout that runs for 60 seconds, then reloads the layout. I will keep this going to allow enough time for the issue to occur.
Forgive me MrStefan, one more question. What firmware version is running on your DSCS9X?
You can check that by opening the Settings app, then choose Device Preferences option, then About. The Build entry at the bottom of that page is the firmware information I need.
I have been testing this since we last spoke and so far I haven’t been able to replicate the issue.
If anyone else is seeing this issue, but they found that not using Restart WiFi on connection failure helped them too, please can you post on here to confirm that? I would be interested to know if this is an issue anyone else is seeing.
I will run this for a bit longer in case it does happen but I wanted to share an update on the test so far.
Thanks for testing this, I really appreciate it. It’s sounding more like the issue is specific to my environment. If anyone else does run into the same problem at any point in the future, I’m hoping that my findings might help them.
I’m going to keep running this for a bit longer, then I’ll see if there’s a way to force the issue to occur (increase the distance of the device from my router, maybe even disconnect my router briefly and then reconnect, when I can afford for my network to go down for a short while). I’ll update on those when I have the results of those tests and a bit more time.
Are you aware of any ongoing issues with your network that could explain this? For example, do you see any brief disconnections or anything like that? Could you also check the logs from this display in your CMS, on the Logs page, in case any network or XMDS related logs are being reported?
I agree. Thanks you for reporting this MrStefan. If this does indeed turn out to be a more common issue then it’s good to have this reported in the community so other’s can also share their experiences.
This is a follow up to confirm that after trying various tests, I still can’t seem to replicate this issue. I have had to stop the test for now but I feel this has been a sufficient attempt to replicate the issue.
I’m glad that changing that setting has helped with your disconnect issue MrStefan. We’ll see if anyone else reports this issue and solution.
Many of my displays seem to have problems connecting to my CMS. When collecting all display information for multiple displays, it revealed the following:
Display 1: Number of Concurrent Failed XMDS Connections: 63
Display 2: Number of Concurrent Failed XMDS Connections: 16
Display 3: Number of Concurrent Failed XMDS Connections: 48
This of course triggers the “Restart WiFi on connection failure” since it exceeds the 10 failed connections in a row. Which also causes “ERR_INTERNET_DISCONNECTED” to appear when the player loads a webpage.
Since this option is now turned off in my environment, I haven’t seen “ERR_INTERNET_DISCONNECTED” on any of my devices. Web pages still load perfectly fine, but the communication to the CMS seems to be unstable here.
Thank you for your update on this, I really appreciate the extra information. I suspect that you are right, as you mentioned, the setting works when 10 failed connections occurs.
I will report this to the QA team so they are aware of this behaviour you are seeing.
In the meantime, I’ll look into what’s causing these players to have trouble connecting to the CMS. They’re spread out across different locations using a corporate network, which might cause the failed connections.