Hi, I am having an issue with WebOS clients (v4.16 player) not being able to download content from self-hosted Docker (Windows) Xibo CMS (v4.4.4).
The error I get in the status page is “message:connection error” and it will not load the scheduled layout. It will only play a previous default layout or the splash screen. It will connect to the CMS and allow me to authorize.
I do have an available license for the player. The player will work fine with Xibo cloud-hosted CMS.
(The WebOS players would also work with my old upgraded Docker CMS server (v4.4.3) but would not update the weather module after the initial layout publish. I set up a new, clean CMS server to trouble-shoot that issue.)
The PC clients, running the current player, work fine with my Docker CMS. The connection problem is only with the WebOS players.
I have disabled the windows firewall on the CMS machine entirely for testing.
The only changes I have made to the docker config is to use custom ports (8080 > 80 and 6550 > 9505).
I have gotten a XMR heartbeat. I can connect to the CMS from the built-in web browser on the WebOS client and even login to the CMS.
I have tried with both WebOS 4 (WP-400) and a WebOS 6 client (UL3J)—I get the same behavior. (So it is not a problem specific to one particular display or firmware version.)
Is anyone successfully using current WebOs clients with the current Docker server hosted on Windows?
Any suggestions to trouble-shoot that vague “connection error” message?
Hi, could you please contact our help desk regarding your webOS player as support is included. Our support agents only monitor here (Xibo Community) when time allows, opening a ticket will get this looked at quicker
Hi, I have done that. They tested my WebOS clients with the Cloud server and we both agreed that the webOS client works with their Cloud server.
They gave me some suggestions, which we tried. But they say that they cannot troubleshoot my self-hosted server. That is understandable.
That is why I have posted this to the community because it seems to be an issue between the WebOS clients and my self-hosted server.
I need some help, figuring out the difference between the Cloud server and the docker version of the server that I am using. My PC clients work fine with it so it seems to be only a problem with the webOS clients.
There must be something in the configuration of my docker server that is different from the Cloud server. The only changes I have made to the docker server were the port forwarding. Everything else is straight out of the box.
So I’m hoping that someone here who is running webOS clients with a docker server can give me some insight.
I’d suggest reverting to standard ports as an initial test.
We develop the webOS app (all player apps actually) against a factory-fresh Docker configuration to try and avoid these sorts of issues. To be specific, not on windows, although I don’t see why that would matter.
I believe I have reproduced exactly the same issue described in this thread, but on a different platform, which may help narrow down the cause.
Environment
Xibo CMS 4.4.4
Self-hosted on Ubuntu Server
Docker Compose (official images)
LG webOS Signage player v4.16
CMS running on standard ports:
HTTP: 80
XMR: 9505
No reverse proxy
No custom Docker networking
Unlike the original post, this is not running on Windows, so the operating system does not appear to be the common factor.
Behaviour
The webOS player:
Connects to the CMS successfully.
Appears in the Displays list.
Can be authorised normally.
Downloads and displays the Default Layout after reboot.
Sends registerDisplay and notifyStatus requests successfully.
After a short time, the CMS reports the display as disconnected.
The “Last Accessed” timestamp is only updated when the TV boots.
The player never seems to poll the CMS again for content updates.
If I publish a new scheduled layout:
Windows Player updates almost immediately.
Android Player updates almost immediately.
The LG webOS player never updates unless it is rebooted, and even then it only shows the last downloaded default layout.
Tests performed
To rule out configuration issues I have tested the following:
XMDS communication is working.
registerDisplay requests succeed.
notifyStatus requests succeed.
Display can be authorised.
Display Profile correctly assigned (WebOS).
Restarted both CMS services and the display.
XMR container is running.
CMS can connect to the XMR service internally (curl http://cms-xmr:9505 reaches the service).
Windows Player works perfectly.
Android Player works perfectly.
Scheduling works correctly.
Publishing layouts works correctly.
Manual layout assignment works on Windows and Android.
I also tested scheduling two different layouts a few seconds apart:
Windows switched correctly.
Android switched correctly.
LG webOS remained on the previous layout.
XMR observations
The XMR container logs only show:
XMR Starting (Memory Limit: 256M)...
repeated after each restart, with no further activity.
The CMS has:
XMR_HOST=cms-xmr
configured correctly.
Conclusion
Everything points to the CMS itself working correctly because both the Windows and Android players receive real-time layout updates without any issues.
The problem only affects the webOS player.
Since the original poster is seeing the same behaviour with Docker CMS 4.4.4 (although on Windows), and I can reproduce it on Ubuntu with a clean Docker installation using standard ports, this looks more like a compatibility issue between the current webOS player and Docker CMS 4.4.4 than a local configuration problem.
Has anyone else reproduced this on Linux? Any additional debugging that could be enabled on the webOS player or CMS would be greatly appreciated.
The issue turned out not to be related to Docker, Ubuntu, XMR or the webOS player itself.
The problem was that Force HTTPS was enabled in the webOS Display Profile, while my self-hosted CMS is running over plain HTTP (no SSL).
After changing:
Display Profile (webOS) → Force HTTPS = false
and rebooting the LG display, the player immediately reconnected correctly.
The symptoms before the fix were:
The display could register and be authorized.
It downloaded the default layout after reboot.
After a short time it appeared as disconnected.
“Last Accessed” was only updated when the display booted.
New scheduled or published layouts were never received unless the TV was restarted.
After disabling Force HTTPS:
The display stays connected.
Real-time communication with the CMS works correctly.
Layout updates are received normally without rebooting the display.
So if anyone has a self-hosted CMS running HTTP (without SSL) and experiences similar behaviour with webOS players, it is worth checking the Force HTTPS setting in the webOS Display Profile.
XMDS communication is working.