I have added a URL as an asset but when I change the image associated with that URL Anthias still displays the old image.
Any ideas on how to stop this
To confirm:
You add an asset that is a URL but it is an URI that ends in an image?
Example: http://www.somewebsite.com/filename.jpg
And when you update that filename.jpg on your server, anthias keeps displaying the old cached image?
Yes exactly, although it is a PNG to be specific
I dont want to get too much into the ScreenlyWebview (uses QtWebEngine) current config and cache settings because most of that compiled configuration might not be āeditableā, I have to get a refresher on the config and its location etc before I can tell you if its possible to change the current caching mode of the ScreenlyWebview browser.
But, in the meantime, if you want to manually delete the current cache, as far as I know you need to go into the container docker exec -it screenly-srly-ose-viewer-1 bash and remove rm -rf all the files in this location:
You might also need to delete cache from the location in the same container in:
.local/share/ScreenlyWebview/QtWebEngine/Default/Local Storage/
I will try to mess around with an idea of creating a symbolic link to /dev/null so that cache folder doesnt really get cached but instead goes into the abyss so every time you load a asset/URL it will not be in the cache thus theoretically load fresh every time, have to see if its even possible.
Okay thatās good to know I can just run an hourly cronjob and that should resolve my issue, only problem is Iām having a little difficulty getting that cronjob working
Any Idea why this isnāt working?
That is not how you run commands inside a container, the -i is for interactive, which is not something you are doing.
Basically you are looking for something like:
docker exec -d screenly-srly-ose-viewer-1 sh -c "rm -rf /data/.cache/ScreenlyWebview....."
But as I am testing, I think there is another location for session data in /data/.local/.... as wellā¦
I guess you can play around with deleting different folders and not worrying about messing anything up since restarting the container will recreate those temporary directoriesā¦
Hello Iāve been poking around trying to find where Anthias is storing web cache for display so I can accomplish the same as above. I have flushed the above location and it seems to repopulate the dir with new information but it has no affect on the images displayed. Iāve been through all the other containers as well hoping for a solution. Our website is updating with new imagery but Anthias takes quite a long time to pull new information. (Thank you for having this here by the way, I had been looking all over to where cache might be stored and the best I could find is that it would just be pulling from RAM)
@Alwaysataloss ,
Maybe @nicomiguelino can try and help and give you some guidance as to which folder is storing the cache if itās not one of the ones I mentioned.
I am not sure if redis is caching the images, it might beā¦ 
1 Like
Got it, @ealmonte32. Currently investigating an issue related to running the installer on a 32-bit Raspbian Lite. Iāll get back to this topic when ready. Thanks.
1 Like
that is def more important.
And ugh, 32-bit is a pain, you will probably run into library issues and pypi issues as well that the installer doesnāt address since it targets x64 only as far as i rememberā¦ 
1 Like
@nicomiguelino Whenever you can. I would appreciate it. Until then Iāll continue to look around to find where this is getting stashed. And thanks for the ā@ā @ealmonte32
1 Like
@Alwaysataloss, I was not able to replicate the issue, but Iāve observed something that might help us.
I was able to add a URL asset (that points to an image Iāve uploaded in my GitHub repo) successfully. After that, I changed the image, but left the filename unchanged. Here are the details:
- I currently have two active assets. (The first one is an image asset, the second one is a URL asset that points to an image).
- It took around two cycles before the URL asset image changed.
Let me dig deeper.
In the meantime, what Pi hardware and OS version are you using? Like to hear back from you. Thanks!
Updates
- I made that URL asset to point to the original image. It took around 6 to 7 cycles for the changes to take effect. (Still, there are two active assets, and each of them has a 20-second duration).
@Alwaysataloss, @ealmonte32
I can confirm that the cache is getting dumped at the following paths inside the anthias-viewer service ā /data/.local/share/ScreenlyWebview/QtWebEngine, /data/.cache/ScreenlyWebview.
Hereās a snippet of the start_viewer.sh used by the viewer container:
#!/bin/bash
# ...
# Fixes caching in QTWebEngine
mkdir -p /data/.local/share/ScreenlyWebview/QtWebEngine \
/data/hotspot \
/data/.cache/ScreenlyWebview \
/data/.pki
chown -Rf viewer /data/.local/share/ScreenlyWebview
chown -Rf viewer /data/.cache/ScreenlyWebview/
chown -Rf viewer /data/.pki
chown -Rf viewer /data/hotspot
# ...
As a temporary workaround, you can use a cron job to remove the cache during a device startup (when the containers start).
I was wondering if we could set an environment variable (for instance) so that the WebView binary will recognize the variable and not dump cache in those directories mentioned.
@vpetersson, I added an environment variable for anthias-viewer inside docker-compose.yml ā QML_DISABLE_DISK_CACHE, in an attempt to disable the cache. Cache files are still being generated when the containers start.
Are there alternative ways to disable caching or tweak Qt cache settings?
This is very helpful and Iām going to see about setting up a Cron to schedule clearing these dirās every few hours or so and see how it reacts. Hopefully this will work as a nice band-aide and Iāll look into Qt a bit more when I finally have some free time and perhaps learn something about browsers in the process. With any luck itāll just be an on/off flag though lol.
Thank you for looking into this! Iāve been futzing around with it for a while now and needed the help with the under-the-hood dirty work.
@nicomiguelino , how are you trying to accomplish this? by not assigning a directory for cache?
If the QTWebview was hardcoded to use cache, maybe the only thing that would work is creating a symlink to send cache to /dev/nullā¦
Just a quick follow up to this - I havenāt had much time to come back to this, although, I discovered while creating the cronjob to clear out the folder /data/.cache/ScreenlyWebviewā¦ I found this folder in each container related to Anthias - This included nginx, viewer, celery, websocket, and server. And theyāre all storing the same cache or related cache that was generated each time QT pulled and image.
When I originally had it dump the folder in the Viewer container every 10 minutes I was still getting extreme delays before the images would update. I followed up and added the jobs to remove the same same content in the other containers and now - it still takes time, which I find odd - but it only takes about an hour for it to completely cycle though. Which, for my purposes, is acceptable.
For the record - these are the simple cronjobs I have set:
1 Like
Replying to myself here - Thought that perhaps that even though all these files are being dumped that it may have been working on Ram too. But I dumped that and still no change when I ran a new image to test.
Just thought Iād ask, nico had mentioned two locations for the cache, and your cron job only shows you are removing one directory, can you try adding both directories he mentioned there for each container? Just curious because obviously a user shouldnāt need to dump ram memory to reload content on a process like a browser, ram does not work like that, it doesnāt overwrite a processes cache, ram is not persistentā¦
anyway, add that other directory he mentioned and report back, i am curious about your results.
I apologize, but I neglected to mention. I didnāt see any files in that directory that appeared related to cache. When I tab out from /data/.local/share - I get the following -
And I was hesitant to delete the entire dir. (This dir is also in the other containers as well)
As you may have picked up on - not entirely fluent in the matters at hand, but if you say I should be able to remove it, I will, otherwise I will create a dummy SD card to test it on.