Connection Refused is definitely coming from the CMS side - at the web server level. It is very odd to say the least. Only traffic on 9505 should be encrypted, 1081 should be HTTP unless you are using SSL?
You should not be running the Linux Player as root - a user account is sufficient and recommended.
Can you try updating your CMS settings and configuring the File download mode to Off ? this will remove the webserver from the equation and download files over SOAP. Much less efficient but might point to the issue.
Have you specified a CDN URL in your configuration? the only time that a file download would issue a redirect is if you have a CDN URL present.
Failing that can you please enable auditing on your Display record (Edit -> Advanced -> Auditing until - pick a future date -> save). And then to the Log and put RequriedFiles in the Page filter. If you then start the Player you should get some XML shown in the log detailing the files and the download URL’s that will be followed by the Player. Could you redact and paste those here?
I am having an issue with the new xibo-player. The xibo-player-test works and displays the correct layout. However, when I try to run xibo-player it displays this message:
“terminate called after throwing an instance of ‘zmq::error_t’
what(): Invalid argument”
Furthermore, when it asks for the local library, I press ‘Browse’ and the terminal immediately displays a message stating “Error creating IO channel for /proc/self/mountinfo: Permission denied (g-file-error-quark, 2)”.
I can give you our actual sites address via pm if it helps. But I believe this has something to do with https, since the address in those log entries are regular http. Our webserver redirects http to https. We’re using Apache.
The player seems to attempt to download the files from HTTP addresses, so it’s no wonder they are HTML. Is there anyone else with similar issue? Windows players use the correct HTTPS addresses.
EDIT:
Just checked windows players RequiredFiles.xml file, and actually they too seem to have HTTP as their default location, but the redirection works unlike when using Linux player. This is really weird.
The address is set with HTTPS. The redirection is handled by Apache, and I’m guessing that’s
where the problem lies. I tried setting STS through CMS and forcing HTTPS. STS had no effect, forcing HTTPS with CMS made the service unavailable (probably because Apache was already redirecting).
I’ll have to take a look at our servers HTTPS configuration. Thank you.
Firstly, I think you might be trying to run the Player as root. You shouldn’t do that. It needs to run as the user you’re logged in to the desktop as.
Second your CMS is incorrectly installed. You should not have web in the URL you use to access the CMS. Only the contents of that directory should be directly web servable. Please go back to the installaton guide, and pay particular attention to the section on preparing your environment. You’ll need to use an alias or a symlink in your particular circumstance.
Thirdly you have Apache’s mod_security installed, and whatever request the Player is making is tripping something in that. We don’t ship mod_security, so it’s something you or your server admin will need to investigate and either disable, or correct the configuration for.
A much better option would be to use our suggested installation method with Docker, where we ship everything pre-configured for you so you don’t have these kinds of issues.
So the player runs fine on my machine, but the content never updates or refreshes. The windows client updates and refreshes fine but so far the linux client just load the information at start and never changes.
I inspected the messages the player is sending with Wireshark and found out that it actually does try to get the files through port 80. The URL is HTTP so the player code somewhere changes the address. Then I found this in the CHANGELOG.md file:
27.08.2018 - (unstable)
...
...
- Only HTTP download type is supported for now in RequiredFiles
So it seems that if I wish to get the player working I’ll have to enable HTTP on the server. The player handles everything except the file downloads with HTTPS.
EDIT:
I did some more testing. I now managed to force HTTPS on the server but URLs turned into HTTPS return empty files.
EDIT:
The player suddenly works. Not sure how. I did multiple reinstallations, tried different URLS, did XMR reconfiguration. The default HTTPS URL started working.
I’ll try the reproduce the problem in the future, and report here if I find a precise solution.
We test on both http and https (mainly https though) and we’re sure that it does work over https. It feels like something strange is happening with your setup - i know that isn’t helpful, sorry!
This refers to SOAP file downloads vs HTTP downloads, rather than SSL stuff. Good detective work all the same!
If you do get to the bottom of it please let us know