Are images from HTML sources uncacheable?

Hello forum!

One of our main uses for Caspar is to combine playout of a HTML-based news display with our webradio stream.

When building the display page, a lot of thought went into resilience since we rely on external RSS feeds providing content from a public webserver. After each display cycle of 10 news articles, the content is re-read (if available) and stored on a local web server, images are fetched and stored locally as well. After a browser has made the initial request for the page, there is another level of resilience. All content is fetched via AJAX calls, and if our local webserver would go offline, the content currently in cache would spin indefinitely.

On regular browsers this works fine, but Caspar does not seem to be able to cache images. When switching the server off, as soon as the next article is displayed only the text and html layout is preserved, the background image is missing.
It would be a great addition for this sort of application if Caspar could:
A. Keep a local file based cache for HTML-related content
B. Honor the different cache headers to control it, especially the fairly recent stale-while-revalidate directive.

Would this at all be possible to within the current HTML producer library, or would it require massive amounts of work to pull it off?

Best regards
Alexander
Lead IT technician
Ålands Radio och TV Ab

Whit out knowing if it is possible I would vote against it, as in most cases it is good, when Caspar only displays, what it gets, as otherwise it would be hard to change stuff via dynamic data.

How often does your local web-server goes down? What about adding a second web-server etc. And what do you do, when Caspar goes down, instead of the web-server?

Yes, but that would be where the cache headers come in, possibly combined with a switch in the config that could default to off?

So far, both the webserver and Caspar has worked admirably, and the problem has only arisen during maintenance. So this is more of a theoretical what if. Of course, we could double up on everything, servers, switches, NICs, Caspar + Playout servers. but as always, it’s a matter of cost.

Perhaps also a matter of elegance. When developing it’s always satisfying to have consistent behavior, to be able to expect that certain standards are followed, tools are available. In practical terms, CasparCG contains a browser that just happens to translate rendered html into video. In that respect, it would be nice if it would behave as closely as possible to a modern ditto.

But I fully understand if this is considered a niche situation, I’ll probably just have to live with it!

I understand that, but you see, browsers are the most moving targets in software development these days. Caspar uses the last CEF build, that is available, when the version is built and then freezes it, to reduce support nightmare. The release interval of Caspar is, and needs to be, longer than the one of the browsers. A browser can be restarted by the user, when it crashes, a broadcast CG should not crash at all. As long as you test your work on a Caspar and not in a browser, it works consistent. The nice thing about Caspar being open source an therefor free is, that you can deploy one on each developers machine whit out paying license fees. So you can test on it and not on something else. That is the workflow I would suggest in any case.

I’ve built CCG with caching enabled for a project that uses remote HTML templates, no big changes needed. I mostly referred to rocketbeans fork with the changes, but can double check if I made any further modifications if you are going to build your own.

As always I recommend that anyone that is comfortable with building CCG on their own check the forks listing I maintain if they are looking for features that haven’t been PR’d to the main repos of CCG2.3 or NRK 2.1, there’s usually plenty of interesting things to find there.

But on to Didi’s point, this needs to be implemented carefully on the remote side (what to cache and for how long etc) and probably isn’t what most users want. Service workers are also an option for this on an individual template basis. If the template is always running it’s easy to not update data or images if updated content can’t be downloaded (simply by checking if the RSS is empty and updating images in placeholder img elements and only moving them to the displayed img elements if they successfully load.

1 Like