URL asset image doesn't update when changed

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… :man_shrugging:

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

:+1: 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… :thinking:

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!


  • 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:


# ...

# Fixes caching in QTWebEngine
mkdir -p /data/.local/share/ScreenlyWebview/QtWebEngine \
    /data/hotspot \
    /data/.cache/ScreenlyWebview \

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. :thinking:

@vpetersson, I added an environment variable for anthias-viewer inside docker-compose.ymlQML_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:thinking:

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.