I have been speaking with Peter Mis through other topics and privately about the changeLayout and text widget APIs.
I currently have a situation in my project where my PHP script uses cURL to send the above API’s to Xibo.
The screen changes layout instantly (Working)
The text widget updates with new text instantly, on the CMS
The screen only shows the last edited text as the layout is not being built after I call changeLayout.
I know my script works as it changes the layout and the text.
It would appear that the process if getting stuck at Xibo’s end with the layout not being ‘built’ as my screenshot below.
I can replicate this every time I call my script.
Peter has reccomended I share my docker-compose logs as it could be an issue with XTR not clearing up the layout change or where something has become stuck.
I have attempted to call the changeLayout, change text and changeLayout in that order to see if I can almost force it, but not no avail.
Hey Dan, I wasn’t providing that before, I have just tested with it in place and it now it doesn’t change to the previously entered text from the widget, I have to browse to the layout in the CMS for the player to realise that the text has changed.
UPDATE: - I have changed the API Call slightly to downloadRequired = 1 and changeMode = queue (instead of replace, which is counter intuitive I know… ) and now if I sent the widget change and then a layout change and nothing changes until I call the layout change again and it changes to the correct text!!
I didn’t see anything else interesting in your logs i’m afraid.
The intended behaviour is that you would change the widget text and then call changeLayout with downloadRequired=true if you wanted your recent change to be obeyed. All this does is force the Player to “collect” from the CMS before running the layout change action.
If your player already has a lot to download, you could expect that action to take some time to complete - and your Layout wouldn’t be shown until it was complete.
replace and queue modes only come into effect if your running layout is already a layout change action - i.e. replace the current action with this one or queue it for when the current action finishes.
What is the total duration of the Layout in question? It could be that you have a Layout there with a really long duration, and you have a bunch of actions queued up behind it.
We don’t notify displays each time a Widget is saved - they’d be firing off like mad when someone was in the designer. We only notify on Layout Build - which happens periodically while you are in the Layout Designer, or via the Task - Regular Maintenance.
I think what you’re seeing is a timing issue - possibly a bug - which means that the display is not notified that there is new content to download by the time it does the collection. Therefore it gets its current list of files and assumes there is nothing to do. It then does show the layout again (replace or queue), but its the same as before.
I’ve submitted a bug for this here so that I can investigate further. As a workaround I think you can force the Player to download a new copy of the Layout by using the API to edit the Display. You could test this by:
Calling the API to edit your Widget - as before
Manually while on the Display page, edit the target display and click Save (will clear the Player status/cache)
Calling the API to changeLayout, with downloadRequired=true&changeMode=replace - as before
If this works, you can either wait for a fix, or build the edit display into your API call (which I admit will be a pain). Another potential workaround would be use the Schedule functionality instead of changeLayout - i.e. you add a new schedule to that Display, which will immediately be notified if it is in the Schedule window.
These steps work!! Its so good to finally pin down the cause. Thank you.
Just to answer your questions from before - The layout which is on scedule is about 60 seconds and the changeLayout is only 10 seconds, with two regions, one photo and one text widget (which is being changed) so I wouldnt see any major issues without downloading content there.
I will think I will test the edit display API call to clear the cache from the screen in my PHP script and report back to you shortly. Hopefully a fix will be found in the future as the project I am working on would rely on this function.
Great news - you’re welcome - thanks for your patience.
I’m sure it will - what we need to avoid is calling “notify” unnecessarily as this adds significant load to the whole system - we also don’t want 1 API call to trigger two Display collections at the same time.