Windows client hanging on splash screen 1.8.0

Get Help
1

I’ve got a fresh docker install of Xibo on a Debian Jessie server, with Apache providing an SSL proxy. From the server side of this, all seems to be well. I’m then trying to run the Windows 1.8.0 client on a freshly installed Windows 10 (Long Term Servicing Branch) machine. Install is good, configuration is good - connects to the server and I can Authorise the Display from the server end.

However, when I try to launch the client, I just get the splashscreen and it hangs for hours. Any ideas what I can check?

2

Could you press ‘i’ on your keyboard while Xibo player has focus?

That will show a status window of your player, please take a screenshot of it and post it here.

3

I’m afraid “i” doesn’t do anything - the splash screen and only the splash screen is still the only thing showing.

4

Unless you’ve changed the default key (i) in display settings -> edit display profile -> troubleshooting tab

Then ‘i’ should display client information screen (of course Xibo player needs to have focus for that to happen)

5

I’m afraid the client is just completely hung - no key does anything, the splash screen just sits there.

6

Just out of curiosity, is IE11 installed? I used Win 10 LTSB too and the first time I went to set it up I didn’t have IE 11 selected. Also, you’re going to need to check that the reg key to use IE 11 is set: > Enabling HTML5 in the Windows .net Player

7

Yes, IE11 is installed, and the client installation has made the reg key change - must be something else!

Thanks :slight_smile:

8

Well, if you can’t access the status screen, then perhaps look in the CMS logs.

You might need to enable CMS debugging and/or player auditing as well.

If that’s not good enough, you can try this - How to get a Windows Player log for advanced debugging

Please proceed carefully though.
as it will create logs in the specified folder for example
C:\Users\USERNAME\Documents\Xibo Library\log.txt
You will most likely want separate display profile with the settings as mentioned in that topic.

Unless it’s more of a Windows issue, in which case it could be good to see ram usage etc while the player is ‘frozen’

9

Thanks. A further update:

It seems the issue is to do with accessing over the SSL proxy. I have changed my Windows client settings’ CMS Address from https://servername/ to http://servername:8080 (where 8080 is, of course, the port set up in cms_custom-ports.yml.template) and the client opens fine. Since the CMS and the displays will all be on a private vLAN this is acceptable to me, but if there’s any further testing or information I can provide while this is still in development and before I put it into production, I’m happy to do so.

10

Are you able to bring the Player status screen up now?

We have literally thousands of Players behind SSL reverse proxies (mainly haproxy in fairness rather than Apache), but there should be no reason that it would impact the Player, nor cause it to hard lock up the machine.

11

Yes:

Capture.PNG729×625 64.6 KB

12

And reverting back to your SSL proxy reliably prevents that screen from opening?

13

Yep - back to being stuck at the splash screen.

14

Very odd.

Are you able to share whatever configuration you made for the proxy?

15 
<VirtualHost *:443>

SSLEngine On
ProxyPreserveHost On

# Set the path to SSL certificate
# Usage: SSLCertificateFile /path/to/cert.pem
            SSLCertificateFile      /etc/ssl/certs/public.crt
            SSLCertificateChainFile /etc/ssl/certs/at_ov_cabundle.pem
            SSLCertificateKeyFile /etc/ssl/private/private.pem

# Servers to proxy the connection, or;
# List of application servers:
# Usage:
# ProxyPass / http://[IP Addr.]:[port]/
# ProxyPassReverse / http://[IP Addr.]:[port]/
# Example:
ProxyPass / http://0.0.0.0:8008/
ProxyPassReverse / http://0.0.0.0:8008/

</VirtualHost>
16

That looks sensible to me.

Without having access to it with Postman or similar, it’s going to be tough to know why that wouldn’t work.