Hello,
Upgraded to CMS 1.8.2, testing Android clients R101. From the CMS I use request screenshot, but the checkmark doesn’t disappear (used to work perfectly on 1.7.9 with previous Android client). There’s a message in the CMS “If the Player is configured for push messaging, screenshots are requested immediately…” but I don’t think I want that, because of the complicated and over-protected network environment - the classic method would be perfect.
Request screenshot in 1.8 series needs working XMR I’m afraid, without it this feature will not work, same for send commands and any other player actions.
What’s the correct way to set up xmr?
The CMS is behind a reverse proxy, clients are on public internet.
zeroMQ needs to be installed and enabled (in php.ini)
Then XMR configured - http://xibo.org.uk/manual/en/install_xmr.html
In docker installations all you’d need to do is to set the public xmr address to be your domain name or ip like:
tcp://your_ip:9505 or tcp://name:9505
OK figured it out. The terminology is confusing - the documentation refers to the “XMR” term while in the CMS the message description states “If the Player is configured for push messaging, screenshots are requested immediately…”. It’s not obvious that XMR = requirement to be configured for push messaging.
Also in the CMS dipslays settings configuration by default the XMR field is empty - the message above should take that into consideration (like “if XMR field empty then warn user that request screenshot will not work”) instead of printing that confusing text.
OK - now the screenshot works, however, video content is not seen on the screenshot. In 1.7.9 and earlier, video screenshot was working on Android clients if “Use a SurfaceView for Video Rendering?” was ticked. Not anymore on R101, regardless of this setting.
There’s no change to the way screenshots are taken, or the way videos are played.
I suspect you didn’t allow long enough after changing the SurfaceView setting for that to be applied.
Sorry I did, and I double-checked that using the “Status” window in the player client. Once it had “Use a SurfaceView for Video Rendering?: true”, next time it had “Use a SurfaceView for Video Rendering?: false” - and I tried screenshotting after this check.
Using Minix Neo X7 with the latest firmware available. Still using them in production with 1.7.9 which doesn’t have this issue.
I would make sure you have a restart when changing that flag. It shouldn’t be necessary, but it definitely won’t affect any video that is already playing (your live streams for example) if you change it without a restart.
I restarted the cient, believe me (otherwise it doesn’t change value in the status window). I do a full restart twice after changing the setting in CMS by force-stopping the app in Android, and starting it manually. Tried even rebooting the Android box.
(the difference in video playback is slightly noticeable by a little jerkyer playback when it’s on SurfaceView, and smoother when it’s not).
I don’t know what that can be then. There literally is no difference between the screenshot and video playback. They use the exact same code.
I’ve just done a test with an X5mini (latest Minix firmware - Android 4.4.2 - which is the same as the X7mini firmware), XfA 1.7 R64 and SurfaceView on, on a 1.7.9 CMS and I get black for a screenshot - which is to be expected as the video is hardware accelerated.
Would it be too much to ask to keep the screenshot functional in the old way too (as a selectable option maybe)?
There are many clients where custom port access is blocked from their internal network. I can’t ask them to open any extra port, and you know, signage is a low priority in their business, I can’t explain to the management and they won’t understand why this is needed. They only see it as “it was working until now, why is it not working the same from now on, this is too litlle reason to touch security of the entire network”.
I see XMR has a lot of benefit but there are circumstances when it cannot be used and we have to restrict to plain http only, safe and sound going all over through standard ports, proxies etc. And loosing screenshot is a show-stopper for us in these cases.
If there would be a setting to get the screenshots the old-fashioned way - that would be very very cool, thanks.
There’s no reason you need to put XMR on the port we suggest if that isn’t available on your customer network. You could very easily have it listen on say port 80 or 443 or even 53 (DNS) (indeed it can listen on many ports simultaneously) - clearly those ports would need to be free on whatever IP address you use for XMR to listen on). You can configure the address the Players connect to per display settings profile so they can differ per site.
We don’t have any plans to add in support for Player actions via means other than XMR I’m afraid.
That’s not possible. A security gateway like a Cisco ASA, or Uubiquiti EgdeRouter will kill these packets as they can’t pass through Deep Packet Inspection. (they look into the data flow on the ports you mentioned, and as long as they see there’s not specific http or dns-like formatted packets with proper headers, they will be blocked and reported). Also an http proxy server will not pass them through even though it sits on port 80.
We’ll have to consider this as functional regression then, and consider other signage solutions in the future for these sites…
As you wish. I’m afraid your environment not meeting the requirements of the system doesn’t mean that the functionality has gone away. XMR is going to become more and more important as things progress so an alternative product might be sensible if your customers are unwilling to open an outbound port to a fixed IP address.
The decision to move the screenshot functionality to XMR wasn’t something we did without thought - with the functionality as it is in 1.7 series we received many complains that the functionality wasn’t working, most of which turned out to be that the player hadn’t run its collection interval.
Therefore it was a natural decision for us to move the functionality to use push messaging.
We moved it, rather than copying it, because generally speaking having a single feature work in 2 different ways is confusing, particularly in this case because we couldn’t guarantee that a player wouldn’t run its collection interval while a screenshot push message was happening. We tested the feature thoroughly with both options enabled and this did indeed happen on players with a low collection.
As a workaround could reintroduce the old mechanism for Players that are not configured for XMR. We’ve created an issue for that to be addressed in 1.8.2.
Thank you very much. I suggest to put a checkbox in the settings, with the default value to push the screenshots via the new method. If one selects the old method, race condition shouldn’t occur between the two methods (as they would exclude each other).
May I also suggest to update the warning text in the CMS when the user requests the screenshot to also reflect this.
We can tell ahead of time whether we have XMR available - we could use that information instead of a setting to choose the right method of sending the request.
We can certainly improve the form to give feedback on which method will be used.