XMR not working using websockets

Get Help Xibo Player for Windows
1

I recently upgraded to CMS 4.4 and the latest Windows Player release. XMR is throwing the following errors:

|

Unable to restart XMR: Could not load file or assembly ‘websocket-sharp, Version=1.0.2.32519, Culture=neutral, PublicKeyToken=5660b08a1845a91e’ or one of its dependencies. The system cannot find the file specified.

Stack Trace: at XiboClient.Action.XmrSubscriber.Stop() at XiboClient.Schedule.Stop() in C:\Users\User\Documents\Source\xibo-dotnetclient\Logic\Schedule.cs:line 749 at XiboClient.MainWindow.MainForm_FormClosing(Object sender, CancelEventArgs e) in C:\Users\User\Documents\Source\xibo-dotnetclient\MainWindow.xaml.cs:line 455 at System.Windows.Window.OnClosing(CancelEventArgs e) at System.Windows.Window.WmClose() at System.Windows.Window.WindowFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at System.Windows.Interop.HwndSource.PublicHooksFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled) at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler) at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)

2

Upgraded from 4.3.1 to 4.4.0, too. (Docker installation)

Same XMR error:
Unable to restart XMR: Could not load file or assembly ‘websocket-sharp, Version=1.0.2.32519, Culture=neutral, PublicKeyToken=5660b08a1845a91e’ or one of its dependencies. The system cannot find the file specified.

3

Is websocket-sharp.dllpresent in your player install direcory?

4

It is not; in fact it’s not present anywhere. I tried a reinstall and no sign of it.

5

Couldnt solve it with the mentioned websocket-sharp.dllversion + a newer version and a matching Redirect. The assembly load error is gone, however XMR still does not work. I only get a timeout. Might be a version specific issue related to this

6

Same issue here. I’ve rolled back to v4 R405. @Ieuan_Leigh Perhaps it would be wise to withdraw this release?

7

Strange, it looks like that file is missing from the installer (but is there locally in development). I will see if I can rebuild the installer and post an updated MSI to the release.

8

The MSI has been updated to fix, apologies for this regression in functionality.

We have also logged a CMS bug to delay deployment of web sockets until v4 R407 so that anyone with a defective v4 R406 installation will have it solved once 4.4.1 is released (the CMS tells the player app when to switch to web sockets).

You can either reinstall the windows player using the same link, or wait for the patch to the below issue (expected later today).

Apologies again for the inconvenience.

9

Has anyone successfully gotten XMR to work with a 4.4.0 CMS Docker Install and R406 player combination?

I can’t seen to get it to with using with websockets or the old port 9505 method. Every player I’ve upgraded to R406 has the following error:

xmrStatus: Long term Inactive (tcp://10.100.10.74:9505), last activity: 2/17/2026 4:16:51 AM

If I download the player to R405, XMR connects and works normally. As soon as I upgrade the player to R406, it stops working again.

In my CMS settings, I currently have the XMR Public Address set to tcp://10.100.10.74:9505 and the web socksocket address blank. I’ve tried both the IP address and hostname in the public address field, and no matter what I do, R406 players do not successfully connect to XMR via any method.

10

Same situation with my 4.4.0 Docker installation with the updated R406 player.
XMR is not working.

11

Are either of you running behind a reverse proxy or similar? Your player app should try to connect to ws://cms_url/xmr, but if you have a proxy in front that might fail.

It would be useful to see your XMR container logs docker-compose logs -f cms-xmr to see whether connections are attempted.

12

Hello Dan,
thank you for your response.
Yes, Xibo is running behind a proxy. The XMR container log is empty.
Can you please explain what the configuration in the proxy config (apache) should look like?Unfortunately, I lack a bit of expertise here.

13

I’ve only ever used nginx as a reverse proxy, so I am not really sure how you would do that with Apache. In theory though you need to enable wstunnel:

sudo a2enmod proxy_wstunnel

And then make sure you’re handling the ws connection and tunnelling it to the right place (this is an example to give you direction):

<VirtualHost *:80>
    ServerName yourdomain.com

    # 1. Handle WebSocket traffic specifically (assuming you've bound the 
    # XMR container port to 8080 on the host)
    ProxyPass /xmr ws://localhost:8080

    # 2. Handle standard HTTP traffic
    ...
</VirtualHost>

The cms-web Apache container does this, but I think your proxy will be closing the connection because it doesn’t understand what to do with it.

14

I also have an Apache reverse proxy I’m using for SSL for the CMS and was able to get this working with standard non-encrypted traffic by doing this:

        ProxyPass /xmr ws://127.0.0.1:8080/xmr upgrade=websocket
        ProxyPassReverse /xmr ws://127.0.0.1:8080/xmr

        ProxyPass / http://127.0.0.1:8080/
        ProxyPassReverse / http://127.0.0.1:8080/

I have not successfully got it working with secure websockets. I tried adding the same thing I have above to my SSL virtual host and changing the Xibo Websocket address to wss://hostname.xyz.com/xmr and it did not seem to work. I’ll keep working on that and if I can get it to work, will post my config here for everyone else.

I am noticing one little glitch that I suspect might be a bug in the way the Windows player is reporting the status. It shows xmrStatus: Connected (tcp://hostname.xyz.com:9505), last activity: 2/19/2026 2:24:03 PM even though it is actually connected via Websockets. I suspect this might be a bug in the status reporting on the player.

I can confirm via my apache log it is connected via websockets:

10.100.29.176 - - [19/Feb/2026:19:26:29 +0000] “GET /xmr HTTP/1.1” 101 328 “-” “websocket-sharp/1.0”

I believe the “101” status code indicates a successful upgrade to websockets

15

@derekschwab Thank you very much, your configuration suggestion helped me a lot. It works for me now, too. I would be very interested to know if you manage to switch the connection to a secure web socket connection. Please feel free to share your results here.

16

… and to add: I also get the supposedly wrong XMR status message, which refers to the wrong connection type.

17

Yes, you’re both right, this is a bug.