Dan,
First of all, thank you for your reply,
I wish you an happy new year to you and all Xibo’s team.
I read on this community that it would be possible to get an Android Player in beta version compatible with XMR. Would it be possible to get it please ?
Then,
I have currently a PHP script which send request to Xibo’s API in order to add an image/video to the library or to automatically schedule a content to a screen.
I need to change the image of a player more often than once per minute (I would like to be able to change the image once per second)
To do that, I read that it would be possible to send to a player “request” or “command” through XMR to ask the player to check a new content on the server.
Could you tell me how can I manage to send a “message” through XMR with a PHP script ?
Please send your request to support@springsignage.com, or whomever supplied your Xibo for Android licences. Thanks.
I think you need to reconsider your architecture - it is not advisable to use Xibo for this sort of high-frequency update - it almost sounds like you want a video stream rather than a picture.
You cannot use XMR directly - instead you use the CMS API to trigger actions on the player. There are a number of actions available, which are listed in the API document: http://xibo.org.uk/manual-tempel/api/#/displayGroup
They all require a displayGroupId, which can either be a real group, or a specific display using its own special displayGroupId.
If you are scheduling new content to players, they will already be using XMR to detect that content change and update themselves immediately. If each content change needs new content to be shown, you can’t make that happen any quicker, because the player needs to download that content.
The flow is:
Content Changes
CMS detects that content is active on displays
XMR collectNow message sent to displays
Displays connect to XMDS and receive new content
If existing content needs to be shown, then using a changeLayoutAction might be the way to go as the content is pre-downloaded and will change immediately.
That example is no longer valid I am afraid because lines 16/19 have been moved into the CMS (accessible via the API). It seemed to us more appropriate to do the encryption at source, in case the XMR service was moved outside the local network.
Of course you could write something that did your own encryption based on the public key and then manually sent a message to the XMR private address - but I suppose the question at that point is why would you bother?
It would make much more sense to add your custom XMR call into the CMS - or use the existing calls. Adding custom calls can be achieved by adding custom Middleware, which registers a new API route, which is then action-ed by your own controller. Further reading here.