Group assignment doesn't trigger Xibo client

When I assign a new display to an existing group, the display doesn’t get triggered to start showing the content that’s scheduled for that group. It’s only when i change something in the scheduling on that group (where the display is member off), the display starts displaying the content it should. Is this a known bug?

Could you please tell us what CMS / client version are you using?

CMS 1.7.7. Same problem with XIBO for android client 1.7 R60 and XIBO for windows client 1.7.7.

It seems to work correctly in our environment.

I added two displays to the 1.7.7 CMS (Windows and Android), set some default layouts for them.

Created new display group, assigned one of the devices to it.
Created new event to display on that new display group
It was working on the display that was already in that group
Assigned second display to my new display group
It was working on the second display as well.

So it should work just fine, perhaps the content you had scheduled somehow interfered with the new schedule assigned to the group? ie some long running layouts, long schedule, both display schedule and display group schedule were scheduled on the same time, we’d need more details to try to recreate this issues.

In my case it’s not working.
When adding for example a second display to an existing group, the display doesn’t show anything except it’s default layout. I can force the ‘newly added’ display to start displaying the content assigned to his group by triggering it: for example changing it’s default layout to something else and changing it back. Or by changing the profile type to something else and changing it back. Or by changing something small in the scheduling for that group (for example add 5 mintues to the end-date of the schedule).
Is there a trigger value somewhere in the database so the clients know they need to download their content?

So each collection interval player will attempt to connect to the CMS and then download any new/updated content, schedule etc.

Since by adding that display to display group that already has something scheduled you are effectively changing the schedule for the display - so it should ‘know’ there is a new schedule (and possibly new content) to download.

I did a wireshark trace on a windows PC where the problem occurs.
When i change the group of the display, the content of the scheduleresponse tag in the SOAP response of the CMS doesn’t change. This confirms my problem.
When i trigger the change by changing a value of the display settings, the scheduleresponse tag contains the right information and within 10 seconds, the xibo client starts to display the right content.
So the problem must be a bug in the CMS.
(i did a clean install of 1.7.6 and an update to 1.7.7 CMS)

I did a clean install from CMS 1.7.7 and a windows client, same problem with this setup.

We added a little caching in 1.7.7 which is certainly the cause of the problem. Thanks for reporting this, I’ve created a bug:

The cache is time based and will expire naturally

1 Like

Just installed the latest CMS 1.7.8 and windows xibo client 1.7.8 but problem isn’t resolved.
When moving a display to another group, the display keeps playing the schedules from the “old” assignment. When chaning something in the new schedule, de display starts displaying the content from the new group.

I’ve had a quick look and I can still replicate the original problem, but the bug fix for this is in the 1.7.8 release codebase.

I’ll refer it back for another look and see what occurs.

We’ve pushed a hotfix into the 1.7.8 release to fix these issues. Please re-download the archive and apply over the top of your upgraded CMS.

Indeed, the fix is integrated in the latest archive.
thanks, this works.

1 Like

This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.