XTR Layout Changes

[Alex_Noyes]

Hi,
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.

1. The screen changes layout instantly (Working)
2. The text widget updates with new text instantly, on the CMS
3. 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.

Please find the docker-compose logs below…

I am not very docker-competent so please excuse my lack of docker knowledge from hereon forward.
Any thoughts would be greatly appreciated…

[alex]

If you go to the Tasks page in the CMS, what is shown there for Regular Maintenance task?

[Alex_Noyes]

Please find attached…

[alex]

That all looks sensible then. I don’t think whatever the issue is relates to Docker or XTR, as that’s all running as expected.

Is there anything in the CMS logs? Does running the report fault wizard while making your API calls, and then for a few minutes afterwards show any errors?

[Alex_Noyes]

Hi Alex,
I could not find anything in the API channel but please see the logs with no filter, can you shed some light on this and what some of these might mean, as they could possibly be affecting it?

Also this is the output from the audit trail which looks good and shows no errors.

Thanks
Alex.

[alex]

Please run the Report Fault Wizard as requested. There should be hundreds of lines of log output with that set.

[Alex_Noyes]

I have PM’d you the Log ZIP which has been created due to screen names etc…

[dan]

Are you providing downloadRequired=1 to your changeLayout API call?

https://xibo.org.uk/manual-tempel/api/#/displayGroup/displayGroupActionChangeLayout

Without this parameter the change to the layout will only be detected the next time the Layout is built in the background, followed by another XTR/collection.

[Alex_Noyes]

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.

Strange!

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!!

Almost there!!

[Alex_Noyes]

Was there anything else in the logs which would point to the issues I am having?
I noticed that the following widget options were pulled in the logs:

Saving widgetId 176 with options. {
"saveWidgetOptions": true,
"saveWidgetAudio": true,
"notify": true,
"notifyDisplays": false,
"audit": true
}

Is the false above that I have highlighted in bold significant?

Thanks,
Alex.

[Alex_Noyes]

So… further digging reveals that even after waiting for the layout to finish ‘building’ the widget doesn’t change. Could there be anything on the player which would be causing this?

I have checked the logs from within the Client information and Status panel but cant see anything out of the ordinary?

The only thing which looks a little suspect is - Dispose|Cannot dispose of web browser. E = Cannot access a disposed object. Object name: ‘WebBrowser’.

Alex.

[dan]

Sorry for the delay.

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.

@Alex_Noyes

Saving widgetId 176 with options. {
    "saveWidgetOptions": true,
    "saveWidgetAudio": true,
    "notify": true,
    "notifyDisplays": false,
    "audit": true
}

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:

1. Calling the API to edit your Widget - as before
2. Manually while on the Display page, edit the target display and click Save (will clear the Player status/cache)
3. 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.

[Alex_Noyes]

@dan

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

Hey Dan,
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.

Thanks again!
Alex.

[dan]

@Alex_Noyes

These steps work!!

Great news - you’re welcome - thanks for your patience.

@Alex_Noyes

Hopefully a fix will be found

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.

We will work on it for 1.8.3 and get it included.

[Alex_Noyes]

Hi Dan,
Just to confirm, this fix released in 1.8.3 has rectified this issue. Thank you for your help.

Alex.