We are also experiencing this problem on 1.7.6. We first noticed it when adding new clients and changing the default layout with the Android client R59.(We only run Android Clients). We can see in the CMS that the client is downloading the content but never seems to finish. The default layout it is just one image of 228KB. If we exit the client and go back in, the Default layout is immediately shown, and then the CMS follows by showing that everything is fine.
That’s a bit odd, it seems to work just fine for us.
Pretty much the only thing that could delay (further than collection interval and download time) schedule (changing layouts in general) is a really long duration on currently displaying layout.
What about android status window? Is it showing as up-to date or are there queued downloads?
Not sure why you are saying that? In the picture behind the status window, it is showing the splash screen, with the standard Spring Signage and Xibo logos that displays over the splash screen if no content has been downloaded to the client yet.
Yeah, I am not sure, sorry Colin you’re right, I guess I got confused since most people use the default splash screen.
What I didn’t notice yesterday for some reason is 'Player is missing dependencies’
Could you please check date time settings on this device and run ‘verify all’ on module page please?
Peter it seems that everything on the modules is enable except “Customer Counter connected to a Remote Control”. I will check the date and time on the android device but I’m sure that it’s correct because we are using it to display time on our display from the client and not CMS. @cslaughter have you found any fixes for the issue?
I have not come up with a solution, but I do think this is a duplicate of this. As we have noticed that if we leave the client running for sometime, say 1+ hours, it does finally show the content.
No worries, I was just a bit confused.
The date/time settings are correct, before and after the problem. The missing dependencies problem is instantly gone once you close and reopen the client. So maybe after the client downloads the dependencies the clients system is still unaware until some predefined amount of time for some sort of refresh?
I should mention that we are assigning a default android display setting, and update interval of 10 minutes to all displays we add to the system. So we are expecting the system to update the default layout within the very maximum amount of time, of 12 minutes.(The default layout is the only thing scheduled, and it is just 1 image of 226KB, so really is should be much sooner. Client internet connections are all 5MB+ down, servers upload bandwidth is not maxed and has 10MB+ Up.)
Can you please tell me exactly the steps you do to make this issue occur?
Is it just:
player is displaying some content
you change the default layout
wait
hmm wait more…
Or do you change something on the layout that is currently displayed?
Do you have ‘Expire Modified Layouts?’ ticked?
Any long durations on your layouts?
Basically I’ll try to run some different scenarios and see if I can encounter this issue.
If anyone would like to tell me step by step what you did to have it, that would be great.
If you’d also send me your layouts (via pm) that were causing this issue that would be even better.
So I did some tests, all the information below are with collection interval 10 min, R59, 1.7.6 CMS
I tried changing default layout to:
Layouts that hasn’t been downloaded by the player yet
Layouts that was already downloaded (cached) by the player
Made changes to current layout (added new images / region etc)
I was using some simple layouts in this process, few images on each (some with ~8 images).
Details:
9:25 connected to the CMS
9:26 changed the default layout to a different layout (that my player hasn’t downloaded yet)
9:35 connected, received new schedule information - shows splash screen (status similar to Colin’s screenshot) - X in CMS status
9:45 connected, showing correct default layout
That’s the worst case scenario I was able to recreate.
With lower collection interval it would take less time to change the default layout of course.
Really long durations on previous default layout can potentially cause even more delay.
If layout to which you want to change your default to is already downloaded by the player the change seems to happen correctly on next collection interval.
Sometimes when I changed the default layout(to new layout or adjusted something on a current layout), on the next collection interval device has X in logged in and ‘last accessed’ is delayed
10:25 - last accessed
10:26 - some changes
10:35 - not logged in
10:37 - connected again (so 12 min for collection interval) and is displaying the correct layout
But that’s not a big problem.
Editing currently displayed default layout seems to be fine too - it goes to splash screen for a time needed to download new content (of course + collection interval, more or less fortunate depending on the collection interval setting and last accessed time).
If there is something that I didn’t cover or if you have some more details for me, please let me know.
So here is our scenario. We’ve got a display that we are just using the default layout and not scheduling anything. Fairly simple layout of background image then a few region’s. I first noticed the issue when I moved the clock region it wouldn’t move until I either set the display to use another default layout and switched back or rebooted the client (using istick a300). Also if I have a region with images and add a new image in the region of doesn’t display the new content until the same steps above. The content can be new or existing.
I’m pretty sure that’s all :).
I should add I never see my display change to the default splash screen after collection even through it shows that it’s collecting, downloading, and finished in cms. The only time it shows the splash is when I changed layout or reboot. I should also add I’m using 1 min collection
I think that scenario was covered in Peter’s testing above which is strange.
You’re aware we specifically advise not to run in the way you are? The default layout is there as “last resort” content to be shown and shouldn’t be where you’re putting your content. Your content should all be scheduled.
Are you using the Expire Modified Layouts setting? What durations do you have on this layout with the clock?
The other information is critical though. Are you using Expire Modified Layouts? What durations do you have on the layout? And what is the collection interval.
Say for example you’re not using Expire Modified Layouts and have a region on the layout that has a duration of 6 hours, then you could have to wait 12 hours for the display to update regardless of the collection interval. We really need that information to be able to help you.
Brand new Android system, Install the Xibo 1.7 R59 Client from a USB drive. We then open the program which brings us to the screen to connect to the CMS. We enter the address(Non-HTTPS) and password and click connects. Next in the CMS We bring up the displays screen, find the screen and select “Edit”. From here we change the Display (Name), yes for license, and Change default layout to “Default Layout”. On the location tab, we fill out longitude and latitude. On the Advanced tab we settings profile to Android (More below on that), and Interleave Default to yes. Then click on save. We then immediately, tell the Client to connect again, which it does and then ask if we want to register the client, where we click no. On the client we go to Settings. Here we change the splash screen to a simple jpg file of 226KB, check for Root and grant Root via SU. Next we exit Xibo by hitting the right mouse button a few times, followed by reopening it. Then we wait. This is where it sits for us. If we leave it for a long time, say an hour, it at some point will finally change to the Default layout that we set.
So for us, the problem cannot be that another layout just needs to finish playing that is long, or need to wait a long time for files to download in a layout. All clients have 5Mb+ down connections, while the server has 10 Mb+ up. We have checked to make sure we are not maxing out our bandwidth during this process just to make sure. We are not even coming close. Checked the routers capacity to see if another connection could be adversely affecting the connection. All are good.
On the layout Default Layout - it is one region of 1080 scale. It has one image on the region timeline. Like stated above, image is JPG and 226kb. Edit Image screen:
So, it’s the same image for splash screen and your default layout?
Can I please have this image/layout? Just in case, I’d test it with truly exactly the same layout.
So I did exactly what you did (I did a fresh install too) with the same settings and interleave default etc.
I was not able to fully recreate it, it took 12min to show the default layout after installation.
Then when you change the default layout just after collection interval it can take up to 22 min to make this change - so pretty much the same as my yesterday’s tests.
Screenshots/notify layouts seems to work quite well too.
Pretty much the only way besides things that I already mentioned yesterday, to delay it further would be failed CMS connection. If it fails to connect it will make another attempt next collection interval (10min) so that way it could be delayed quite a bit - but I don’t suppose that’s what happened in your case?
I made a mistake in what I told you about the jpg image. I forgot that we had two different setups with two different Default Layouts that we use. One does use the same 226kb jpg for the default layout, the other uses the same png file of 193kb for the default layout and the splash screen. Both have the same problem. But to keep things consistent, through your testing and mine, I will send you the layout I have been playing with in trying to figure out the problem. Again sorry for the confusion, I know that throws things off a bit.
[quote=“Peter, post:17, topic:5179”]
So, it’s the same image for splash screen and your default layout?
[/quote] On the layout we have been playing with that has the PNG file, we are using a different jpg file for the splash screen.
I will send you the exported layout and the jpg we are using for the splash screen via PM
Update: I should mention the two systems are setup identicaly on the Display profile, and layout settings.
Interleve default may be the issue. Android is resource constrained so the Player will prepare the next layout while the current one is running. If you’re interleaving the default with itself I suppose conceivably it could have multiple copies of itself queued up to run. Dan would be able to confirm or deny that completely.
I’ve run these tests personally and I just can’t replicate it across three different devices. The default runs, I edit it or change it for a new layout and then shortly thereafter the change is reflected in the Player.
I would think that with Interleve Default on, if content was already scheduled or if a default layout had already been selected and downloaded to the client, that it would explain that situation.
I don’t think that explains the problem for our situation. As we start with a new fresh client that never has had, anything scheduled on it or a Default Layout.
