Hello eveybody,
I have understood that upon deletion “the asset will remain cached on the player until the SD card is either running out of space or is reformatted” as stated in the FAQ.
But is there a way to explicitly delete that cache to free space ?
Many thanks to any contributor on that point.
Hello again,
I can’t believe, with so many experts here, that nobody knows the answer to that question.
It can be useful for instance if one want to reduce the size of the used SD card (to save money).
I challenge you !
And the winner is … :
Are you talking about deleting the .cache folder inside the container?
Thank you for contributing.
I don’t believe so.
What I have is Screenly OSE, and it seems to me there is no container, no Docker, etc. : only Screenly installed over Raspbian (= Raspberry Pi OS).
What would be the complete location of the .cache folder you are evoking ? I mean : WHATPATH/.cache/ ?
The root of my interrogation is what is told here :
How long does it take to remove an asset from the player after it is removed from the assigned playlist? – Screenly Support
As I understand it, no asset is really deleted until you run out of space. It remains in cache.
I want to avoid this and to correct it for past assets who may still be in cache in order to regain space, that would allow me to use SD cards with a more modest capacity.
Or maybe this “caching” thing is only with some particular editions of Screenly ?
Kind regards.
@PasserBy , that support page you’re reading is for Screenly the commercial version, not OSE.
Really ? Well, in that case, that solves my problem !
And I understand you also gave the solution for the commercial version : you have to “delete the .cache folder inside the container”.
Thank you so much for your insight !
Well, not necessarily, I was just trying to help with the OSE version which I thought the question was directed at, not commercial version since they do not share the same code and are built completely different.
Are you having an issue with SD memory and assets with your OSE version?
The only issue I get is that after being on with no interruption after durations like, for example, 39 days (braodcasting assets that are typically a succession of 2 or 5 static pictures for 10 seconds each), it may become stuck on one asset and not reachable anymore by its web interface.
Powering off and on brings it back OK for another long duration, but I know this can corrupt the SD in some cases.
Apart from that, I find it wonderful !
Oh ok, so you are running into out of memory issues most likely, i can only assume this based on my experience unless you can provide journalct logs that show the errors right before it being stuck and not responding…
I can provide a few different ways we can try to troubleshoot and tackle this but if you want a simple solution I can tell you what I used to do, which is a simple cron job that would restart the Screenly viewer service once a week and that should prevent it from running out of memory and thus your problem is solved without restarting the Pi since that does add to the SD card in terms of writing bytes to it and reducing its longevity.
Great idea, thank you very much !
I am going to try it and will report (in a long time, since this is a matter necessitating a long run) if it solved the case.
I trust your experience on this, as well as on the periodicity but nevertheless : is “@weekly” the optimal periodicity ? Why not “@monthly” or twice a month, to further reduce wear and tear of the SD card ?
Kind regards,
The reason why you would want to do it every week is because a month might be too long and the memory error which causes the pi to freeze might happen before the 30 days is up, and also it depends on how many assets you have and how long it takes for the memory to be full and reach that point where it will cause the pi to become unreachable.
Normally, one of the only I/O happening to the SD card/disk during a normal operation of Screenly OSE showing an asset is what gets logged to the journal and if you’re using latest branch then the QtWebEngineProcess is another process doing disk writes to shared space which i think it might be RAM… anyway… everything else is mostly on RAM. Example, you add an image or a video or a URL to OSE Assets, it goes on SD card as an asset once of course, but all of the loading and reading and temporary writing operations happens on RAM, not on the SD card, but when the Screenly viewer logs that event that an asset loaded, it goes to the SD card because of journaling. You can see this by using disk I/O stats and seeing what process writes to disk during normal operation, it will be mostly jbd2 (updating file system journal) and QtWebEngineProcess.
If you want to save the SD from wear, and you dont care or need to keep logs (or just turn them back on if something starts to happen where you need to go back and read the logs), you can simply disable journaling and maybe move /tmp directory to RAM, but that gets complicated because of the directory sizes needed for things while also RAM needing space, etc… so look into that if you must but i recommend just disabling journaling…
Since the recent releases of Raspbian OS already comes with the /etc/fstab noatime option, and OSE already disables swap, this ext4 journaling disabling is the only other thing I can think of that will help you achieve longevity on that SD card combined with the cron job under the sudo user for systemctl restart containerd.service in the latest branch, or systemctl restart screenly-viewer.service if using the old production branch.
References:
durability - How can I extend the life of my SD card? - Raspberry Pi Stack Exchange
Disabling ext4 journaling remote - Raspberry Pi Forums
What a wealth of information. Thank you so much !
I am going to take into into account and will report.
Have a nice week-end !