Editing Region Library via API

So I have the following signage below and it is divided into 3 regions as labeled.

Region 3 is going to be used for several purposes. During regular operation it should show an order of scheduled images. However during special cases it will need to be made to display a single image until told via the API to go back to displaying the order of scheduled images.

I’m new to using Xibo, so I’m unfamiliar with managing regions and displays as such. I would very much appreciate any suggestions on how to accomplish this.

Can you please explain a little more in detail what you are wanting. I understand that you want to make an image stay on the screen for a while, but can you tell us how you envision it working? Would there be some sort of trigger, such as an event, a time of day, or something to reference as a starting point on how to address what you want to accomplish.

Would overiding the first layout with a second layout scheduled with priority be an option?

Ultimately region three will display ads or other images scheduled by an end user. However during special occasions where lets say that a game is closed, or just starting, region three should be made to display the appropriate images. These are not scheduled and can happen at any time.

A game starting or being closed would be a trigger. But this information is maintained by a different application that I’m writing that would also exist on the machine that would run the xibo windows client. Ideally, my separate application would know if a game is opening, send that information to a backend server, then the backend server would tell the xibo CMS to change region 3.

Overriding the first layout with a second could be an option. I’m assuming it would then be possible to go back to the second layout?

Thank you for information.

The best I can tell you is that you will want to utilize the new XMR feature of 1.8, in addition to the new API.

I would assume that when a table opens/closes the information you would want to display would be for a set time.

I have not tried this, so this might need a little improvement in the implementation here, but my idea would be this:

  1. Schedule the regular layout on the screen.
  2. Make your application server schedule a second layout with priority, till X time when the layout should revert to the original.
  3. Utilize the XMR in 1.8 to tell the display in near real time to update. It will then show the second layout, overriding the first. At such time the second layouts schedule expires the display will then revert to the first layout, although it will start from the beginning of the first layout.

You may also need a beta addition of the client to use XMR, I am not 100% sure on that.

Colin is right, you’d need 1.8 CMS and player - currently there is 1.8.0-rc1 released, which is not recommended for production environment yet.

Either that, or make your application trigger changeLayout API call, which is also described in my 1.8 api introduction.

So you’d provide the layoutID, displayGroupID - each display has it’s own display group id, alternatively that can be actual display group id if that should affect whole display group that you created.
You would also specify the duration for which this layout should be displayed
After that duration ends, player will go back to regular layout.

If 1.8 isn’t recommended for production, that will be an issue. The software I’m working on is scheduled for deployment in January. When Xibo 1.8 is released, I can see updating to use that but that would have to be later.

Given that, can a similar approach be accomplished using Xibo 1.7?

No set date yet, but it should be early next year with January in mind.

1.7 series does not use XMR and API is also nowhere near as complete unfortunately.

I think it would be good if you’d try 1.8.0-rc1
Either as a separate CMS on your own web server or the demo hosted with Spring Signage (which comes with XMR pre-configured already).

Thanks for the help guys, I really appreciate it. I consulted with my team and we found the best course of action would be to stick to Xibo 1.7 and wait until 1.8 releases to implement our feature that would require usage of the new API and XMR.