Hi,
I try the last version of xibo (1.8) and y hav a problem.
A display is connected with the xibo player 1.8 for Windows.
In dashboard, my display is “RED” but is correctly Logged and Authorised.
In “Display” page, the display hav a “status” : X. And the last accessed is up to date.
The server run in Windows with XAMPP 3.2.2
How to solve this problem ?
Thank you for your help
First try clearing the Player cache. To do so, edit the Display record, and then save it making no changes.
Then allow the Player time to connect in.
Ok,
I try this, but without success
I cleared configuration from Xibo player, and deleted display from Xibo server.
I have reconfigured everything, but the problem is always present.
The collect interval is as 1 mins.
And it is impossible modify the configuration the display into ‘edit’ :
Thanks
There’s a problem with one of the time settings in your Display Settings Profile.
Please edit that, and check that all time values are populated. If they are all 00:00, try changing them to a fixed time (eg 00:10), and then saving, and then back to 00:00 again.
With 1.8.0 and XMR, your Collection interval does not need to be at 1 minute. We recommend 30 minutes as a minimum. Please see the CMS post installation guide which explains this.
I applied your recommendations.
This problem persists.
I’m using the default display setting.
I am having the same problem. All Display Settings Profiles are set to times other than 00:00. Timezones are correct on Server, CMS and Player. Clearing Cache does not resolve the Error either.
I saw that this was patched Trailing Data Error
How can we apply this patch?
If you’re using Docker, you’d apply the patch as follows.
Firstly, find the name of your cms-web container.
So run docker ps and you’ll see a list of running containers. The one we’re interested in has cms-web in the name. In my case, it’s xibodocker_cms-web_1. The exact name will depend on the name of the directory you’ve installed in.
Once you have the name, run:
docker exec -ti xibodocker_cms-web_1 bash
That will get you a shell inside the container. Now patch the file as follows:
cd /var/www/cms/lib/Controller
mv Display.php Display.php.old
wget https://raw.githubusercontent.com/dasgarner/xibo-cms/b855401b4c44dbe8278afe1b27ca2a42be419047/lib/Controller/Display.php
chown www-data.www-data Display.php
exitExcellent! That solved the issue, thank you!
Is it possible to schedule the player cache to clean automatically?
No. The cache is cleared selectively when needed.
There’s generally no need to clear the Player cache, but in an error condition (as a result of a bug for example) sometimes it can help to clear it.
Most cache items have a relatively short TTL, so all you’re doing is speeding up a resolution in the course of troubleshooting.
I would like to create a cron job to run a php code that clears the cache of all players in a certain range of rempo.
Without having to open the platform and do one by one.
Can you help me? at least pointing me out the way.
You physically can’t do that.
You could clear all the cache on a schedule by emptying the cache directory in the CMS library, but all you’ll do is destroy your CMS performance and prevent any in-progress downloads from succeding.
It’s a really bad idea. Don’t do it.
I’m asking this because I created a script in php that compresses the images.
and updates its data in the database “size and md5”.
But I realized that sometimes, even if the player has already downloaded the updated file, cms continues to report that the file was not found in the library, or the player keeps trying to download the file infinitely.
Maybe the player is still checking the original md5.
But after clearing the cache of the player, everything returns to normal.
Image files, their size and md5 are immutable. The Player won’t expect them to change, and you’ll cause issues.
You can’t just amend those values in the database. You’d need to add them as new media items replacing the old ones, and you’d need to do so via the API.
My script compresses the images,
Then it gets the new size and a new md5 based on the new compressed file and updates in the database.
Apparently it’s working.
Again, you cannot change the size or MD5 of a file. The Players will not expect that to change ever.
The system is not designed that way, and trying to work around it might be successful in some cases, but ultimately you’ll have problems, and we can’t support you with that.
All your edits to media must be made via the API.
Ok I understand.
The correct thing is that the file is compressed at the time of download!
Unfortunately I could not find the code in the cms that I downloaded so I could try to implement the compression this way.
How can I access the API to try to implement the compression of ticker files at the time of download?
You’d probably need to implement something like that in middleware, rather than via the API.
I can’t walk you though it because I’d have to implement it in order to know how to guide you. If you want someone to look at that on a paid basis then please be in touch with our team and we may be able to help you. sales@xibosignage.com
It’s not a bug. That must be a fully qualified path. You should not be using relative paths there.
In addition, the web root of the webserver should be the web directory. The rest of the code and the library should not be web servable. Please see the manual which explains that in detail