Xibo CMS 1.8 - XMR : Exception in Run: Handle invalid

Yes, forwarding is OK (Firewall). This also works with other services (mail, FTP)

In the client information you can see that the client is connected and last activity is also displayed. When a screen shot is requested, an entry (unknown block type) in the client information window also appears immediately.

You could try re-keying the Player. In the CMS, edit the display, and then on the Advanced tab, tick “Reconfigure XMR” and then Save.

The first few messages sent after that will be invalid, but then it should pick up.

I’m having the same issue. It appears isolated to the following scenario: Player and CMS running on same machine; request screenshot from another machine (receive exception in run: handle invalid error). Requesting screenshot for player not on same machine as CMS - works. Requesting screenshot from machine with CMS - works (although not that useful for player on same machine). All other XMR functions appear to be functioning.

Thanks.

I’m not 100% clear on this from your response.

With Player and CMS on the same machine, if you request a screenshot from a second computer (via the CMS web interface), you get this error.

With Player and CMS on different machines, everything works as expected.

With Player and CMS on the same machine, requesting a screenshot from a browser running on the same computer (via CMS web interface) also works?

Correct. In short, everything works with the exception of the first scenario. Thanks.

Just a FYI. If you are using ZMQ older than 1.1.3 then using “localhost” in the config.json file doesn’t work and you need to replace it with “127.0.0.1”.
This may not be an issue in this thread but was an issue for me and I wanted to make sure anyone that happens across this knows about it.

1 Like

I don’t understand why that should be the case.

There’s no communication between the browser and XMR or the Player. Your request for a screenshot goes to the CMS, which places a request via XMR, which then arrives at the Player.

I can’t replicate the issue here.

I presume none of you are running this inside Docker as we intend?

Scenario:

PC1 (My Home) Webbrowser
PC2 (My Home) Xibo Client
Data center: Windows 2008 Server : Behind firewall : 212.xxx.xx.xxx portforwarding 192.168.2.233:9505

Screenshot for this scenario works fine after Reconfigure XMR.

Sending commands I still have problems, but am still testing

I have 2 test machines - 1 with docker and 1 without. Both produce the exception in run error under the first scenario (player and CMS on same machine, request screenshot from second computer via CMS web interface). Both are windows 10 pro, in case that makes a difference.

This is not a big issue for me - and I would imagine having a player on the same machine as the CMS is probably not as common a setup. I mentioned it primarily for the benefit of the OP, as it originally appeared to match hhan’s setup. In addition, just in case there is a bigger underlying issue involved.

Thanks again for all your work on this project!

1 Like

Thanks for your detailed notes.

I’ll log a bug for it then and we’ll have another bash at a reproduction.

We’ve not been able to reproduce, but I have added some extra logging to see if we can pinpoint the issue. If anyone wants to test ahead of the next release (next week) please PM me for the EXE

I can confirm that this issue still exists on 1.8.2 (docker install on windows 10 pro). Again, when player is on same machine as CMS and screenshot request is initiated from another machine on network. Note that the screenshot interface itself says “success” but, when refreshing the display page, the screenshot? column shows a “check” instead of an “x” and the thumbnail is not current.

Happy to help pinpoint if you walk me through how to provide whatever logs are needed.

Thanks.

It’s clearly connected to XMR properly because it’s showing activity. What’s the XmrSubscriber error message that is logged in full?

The message is “Exception in Run: The handle is invalid”

Can you please enable audit level logging on the Player. That should give a second log entry there which will give us a stack trace.

Please can you also confirm that you get a new log entry every time you request a screenshot?

Yes, new log entry every time screenshot is requested.

May need clarification on enabling audit level logging on player. I tried from advanced tab on edit display (is that the right place? - see below) - but did not receive a second log entry when requesting screenshot.

Auditing there is CMS side auditing for the display.

To put the Player itself in to audit mode, you need to create a Display Settings Profile for it, with Log Level (on the Troubleshooting tab) set to Audit.

You then need to assign that profile to that display, and wait for the settings to be updated (one or two collection intervals).

Log entry after error = “NetMQ.NetMQSocketEventArgs”. Does that mean anything useful?

I’m afraid that didn’t quite do what I was hoping it would - which was print a stack trace (it just printed the exception name). I’ve logged a comment on the bug report and will provide a version that does that when I can.