I’m not 100% sure of the root cause on this one, but we’ve been doing some work on the load balancer that serves Xibo, amongst other software, and this work has involved a transition to Lets Encrypt SSL certificates. The LB automatically provisions the certificates, but sometimes there is an error or lag that causes the content to be temporarily served with a private cert. We’ve also had to restart the LB multiple times as we modify its configuration.
For whatever reason, we’ve noticed that there is an ongoing issue where the Xibo Windows clients to go black and require a restart to recover from the problem. On a couple occasions, we’ve had to clear the data directory to achieve a full recovery.
Sorry, not sure this is helpful in pinpointing the issue, but I assure you the stability issue is real.
What does the status screen show when the Player gets in to that state please? What version of the Player are you running? Does a collect now over XMR recover it?
I don’t think it has anything to do with loadbalancing. It’s much more likely to be related to serving invalid certificates to the Players I would imagine.
Just so you don’t think I’m ignoring you… I haven’t been able to recreate the issue this week in spite of having very similar network conditions. I’ll update this if I am able to dig up more info for you.
I tried to fin you relevant logs via the CMS, but I’m battling the data being buried under process errors per my other thread: Error: ProcessID empty for command
Actually, found one useful related error in the CMS:
Exception in Run: Client found response content type of 'text/html; charset=UTF-8', but expected 'text/xml'.The request failed with an empty response.
It’s repeated over and over during that period when the problem was occurring. The LB returns a 404 when the container is offline so my guess is that the client is calling for an XML file while the containers are inaccessible, and then encountering the 404 page instead.
Only the Windows clients report this error. I’ll let you tell me which way is desirable.
That looks like a perfectly expected error. The 404 page will be text/html.
What we need to see is the status page of the Player when it gets in this state please, and ideally with logging going to a file so we can see if there’s any issues logged there.
I’ll keep an eye on it. Of course it hasn’t presented itself again now that
I’ve said it.