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