To be completed by the original poster:
windows 4 R400.6-400
The latest server and the latest windows client on two players. Both players refuse to download the last 12 files needed to update content. The keep getting stuck at 12 files. This seems to happen every time I update the datasets that some of my layouts pull from.
I have had to uninstall and reinstall the client on both machines twice now to get the new content dataset, or any dataset content to show up.
Can you check in the CMS → Tasks page and see the status of the Widget Sync task? This task is responsible for warming up the data cache for widgets, and if it isn’t running the cache will never be filled.
oh, and reinstalling the client after uninstall and cache folder deleting, did not fix the issue this time.
Turns out I needed to open each layout in design and let the dataset load and then commit the layout. for what every reason seems to have fixed the screens. but doing this evetime I change a dataset is going to be painful.
So what ever updates the template with the updated datasets, seems to be broken. I should not have to open the layout and then save it back out just to get the data in the dataset to update.
I wonder if these XMR errors have anything to do with it. This is from my thrid player, that has not been reinstalled and was offline till just now. I brought it online thinking it would pull down the latest layouts and start running them, but still, the datasets do not display. so I opened the layouts in design and then recommitted them. This is when I got these errors about XMR. I have seen these a lot as a new player.
Can I ask what you have the Update Interval set to in your DataSet widgets?
I think they are all set at a default 5 mins. the content only gets updated once a day ish, so this could be a lot longer but I have not played with it.
So I think I understand why it doesn’t update immediately, but I don’t understand why it doesn’t update at all.
I’m setting up something to attempt recreation locally so that I can debug.
I can’t make my test environment fail to update when using a v4 player (I can with a v3 player). For me, with my collection interval on the display set to 5 minutes and the update interval on the dataset widget at 5 minutes, it takes a maximum of 10 minutes to update.
This is definitely a regression on where it used to be, and I’ve opened an issue to look at making an improvement.
Essentially, in our efforts to make the system more scalable, there is more disconnect between editing the data and how that data gets to the player. We will review and discuss how we can improve that.
In your case, I can connect to your CMS and look directly to see what the problem is? If you’re willing to allow that please DM me a super admin account and the CMS URL.
I have a similar issue with android. Android players R400 dont sync at all. I have tried clear cache on android xibo client and also purge all on cms. Nothing seems to work.
Our configuration: self-hosted v4.0.2 (docker) + 16 v3 android players + 8 v4 android players.
UPDATE: Solved. Was my fault. I didn’t note that I had a display setting with download window activated.
I’ve finally discovered the issue here and will have a fix available soon.
Basically the XTR process was/is using a different cache than the rest of the application, the cache was always “Not ready” regardless of how many times the Widget Sync task was run; it was caching in a different cache.
Every time I debugged, the correct cache was used due to how the process is debugged (manually run). Every time you previewed or loaded into the editor, the correct cache was generated for widgets which are not display specific.
A real difficult one to track down, but super easy to solve.
I’ll come back here with a new tag to put in your docker file if you want to patch ahead of 4.0.3.
Your sir are amazing. A new tag would be great, this has been driving me nuts.
thank you
You can get our latest build here: xibo-cms versions · xibosignage · GitHub
We have a few more issues to iron out, but I think the main player downloading issue at least is solved in that build tag.
put the image in the docker-compose file and got an error so I tried pulling the image directly and I get the same error.
docker pull Package xibo-cms · GitHub
ghcr.io/xibosignage/xibo-cms@sha256:d0683afdf0334051ef91b29bdbecd8a8b09d2f65eadfd3174412022687650e3d: Pulling from xibosignage/xibo-cms
unsupported media type application/vnd.in-toto+json
Sorry I should have been more specific, in your compose yml file you change this:
image: ghcr.io/xibosignage/xibo-cms:release-4.0.2
to
image: ghcr.io/xibosignage/xibo-cms@sha256:d0683afdf0334051ef91b29bdbecd8a8b09d2f65eadfd3174412022687650e3d
thats the first thing I tried and got this error:
root@docker-ubuntu-s-2vcpu-4gb-intel-nyc1-01:/opt/xibo# docker compose up -d
[+] Running 0/1
â ą cms-web Pulling 0.3s
unsupported media type application/vnd.in-toto+json
Here is a copy of the compose file.
version: "2.1"
services:
cms-db:
image: mysql:8.0
volumes:
- "./shared/db:/var/lib/mysql:Z"
environment:
- MYSQL_DATABASE=cms
- MYSQL_USER=cms
- MYSQL_RANDOM_ROOT_PASSWORD=yes
mem_limit: 1g
env_file: config.env
restart: always
cms-xmr:
image: ghcr.io/xibosignage/xibo-xmr:0.11
ports:
- "9505:9505"
restart: always
mem_limit: 256m
env_file: config.env
cms-web:
#image: ghcr.io/xibosignage/xibo-cms:release-4.0.2
image: ghcr.io/xibosignage/xibo-cms@sha256:d0683afdf0334051ef91b29bdbecd8a8b09d2f65eadfd3174412022687650e3d
volumes:
- "./shared/cms/custom:/var/www/cms/custom:Z"
- "./shared/backup:/var/www/backup:Z"
- "./shared/cms/web/theme/custom:/var/www/cms/web/theme/custom:Z"
- "./shared/cms/library:/var/www/cms/library:Z"
- "./shared/cms/web/userscripts:/var/www/cms/web/userscripts:Z"
- "./shared/cms/ca-certs:/var/www/cms/ca-certs:Z"
restart: always
links:
- cms-db:mysql
- cms-xmr:50001
environment:
- XMR_HOST=cms-xmr
- CMS_USE_MEMCACHED=true
- MEMCACHED_HOST=cms-memcached
env_file: config.env
ports:
- "80:80"
mem_limit: 1g
cms-memcached:
image: memcached:alpine
command: memcached -m 15
restart: always
mem_limit: 100M
cms-quickchart:
image: ianw/quickchart
restart: always
I can’t pull it either, but I have no idea why.
We’re going to push out a 4.0.3 release early this week with these fixes included, which will mean we merge into latest tomorrow, so you could use that, or wait for the actual release, likely on tuesday.
Thank you, that will work. Just FYI, it seems to be affecting the weather updates as well. I am assuming its the same cache issue. Both my weather layouts where tree or four days behind, before I noticed it.