Okay i cleared the CMS side cache.
I cant do a better screenshot but it should be all clear to read.
I cant do a better screenshot but it should be all clear to read.
Is the date and time correct on the CMS and the Player? Can you try without SSL to rule that out?
The status shows lots of the files as partially downloaded. Perhaps you need to give it longer to complete?
Yes the date and time is correct on the player. And without SSL i can try tomorrow.
Here is a picture of the weboverview.
I think without SSL is a good test.
You can see in the CMS there the amout of data that has been downloaded for each file since the cache reset, and in all the ones I can see, they are 0.
It may be there’s something in the reverse proxy config that’s wrong, or it may be SSL related. Without seeing the logs on both it’s hard to say I’m afraid.
And if i show you the logs or configurations files in a pm? If yes, which files exactly? If no i try it tomorrow without ssl and then i will report the results here.
I am wondering why the layout is to 79,4% downloaded since 20 minutes.
Is the download percentage going up?
If so, then it looks like the connection is slow somewhere making the download take time.
Try without SSL first. If that doesn’t work, then we can start looking at logs potentially.
I hope that I am not inserting a red herring or derailing the thread but I am running into a similar issue. My client is synching to the CMS just fine by DNS name however looking in my requiredFiles.xml it is referencing “http://localhost:8081/xibo/xmds.php?file=”. Did we miss setting a directive somewhere?
Did you set the CMS name in config.env?
Also, does your reverse proxy include the ProxyPreserveHost directive?
ProxyPreserveHost was the issue for me in particular. Thanks!
1 Like
It’ll be missing ProxyPreserveHost On from your reverse proxy then I would think. There’s an example of what is required in the manual for an Apache reverse proxy. If you’re using something else, you need to ensure the host header is passed through from the request to the backend.
@klausf11 you might want to check you have that in your reverse proxy configuration too.
Required Files is cached, so to test that adding that solves this for you, you’d need to make a schedule change, or a change to a scheduled layout, or edit each display, and save, making no changes, to clear the cache.
Without HTTP it works and it can download and display the layouts
OK. Did you verify the ProxyPerserveHost setting is on in your reverse proxy configuration as suggested?
i am doing the https secure now new. Because an employee did this before. I use your guide Xibo 1.8.0 with Docker on Ubuntu 16.04
I did everything to _service apache2 restart But how can i add my certificate to that configuration?
The guide you linked to to generate a new certificate with Lets Encrypt. That provides its own proper SSL certificate.
If you want to use your own, then there’s a community contributed guide here:
I am noticing that the path variable in requiredFiles.xml is referencing http instead of https. This may be a related issue when behind a proxy.
You may need to tell Apache to add X-Forwarded-Proto header as HTTPS. Xibo will look for that to understand if access is via SSL or not.
I believe:
RequestHeader set X-Forwarded-Proto "https"
Inside your SSL reverse proxy will do that.
That makes sense however when accessing the docker host (localhost:8081) via https I get “SSL_ERROR_RX_RECORD_TOO_LONG”. I believe that may be the root issue.
The local Docker container can’t do https, so you won’t be able to connect to it directly over https. Only over http.
The change I suggested goes in your reverse proxy configuration, not in the container.
I see. RequestHeader set X-Forwarded-Proto “https” fixed it for me. Thanks once again.