In the realm of terminology the obvious choice is “Flush.” The less humorous choice is “Clean Cache” or “Garbage Collection.”
Regarding your implementation description -
Why not allow “age” to be passed to the utility (e.g. “1w” or “7d”, or something similar) rather than restrict to the 30 days that PMS may, or may not, actually enforce?
Offer an option to hard-link the duplicates?
Offer an option to take into consideration total utilization of the storage device (e.g, “Never allow PhotoTranscoder directory to consume more than X% of device storage.” and remove older files, regardless of age, until the total cache size is reduced below X%)?
And if you have access to the PMS source itself, some options that might be worthwhile in creating and managing the cache:
“Global” or “Combined Cache” vs “Per-Client cache”
JPEG image quality (set quality threshold on JPEG compression for the cache assets)
Also, your utility calls out specifically removing JPG files. I see in my PhotoTranscoder cache files with the extensions “jpg” “jpeg” and “ppm”. All three of these seem like good removal candidates.
I am trying to figure out how to implement " Settings / Preferences "
When I have figured out a way to do that (without making the script HUGE), I’ll add alot.
Yes, I’ll get JPG, and JPEG. I need to ask engineering about PPM files as I know those are in the DB.
While your other requests / recommendations are valid, this tool is a shell script.
There’s a limit to what I can do with /bin/sh. This tool was created to run in all environments PMS runs on. Not all NAS platforms offer /bin/bash.
Its primary focus is the DB and to do what PMS can’t while PMS is running.
There are limits to what I can do/publish in non-compiled code (specific APIs, etc)
Yep. Was just looking at the script and contemplating patches to submit back. The various flavors of bash, sh, ash, zsh etc offered in all these various environments will make it a challenge to make a single utility that will run everywhere. Especially once Windows (even Windows + LinuxShell that MSFT has been pushing for a while) is taken into account.
I’m always open to hear about new things which are of benefit to all the Linux platforms.
The nicest thing to have at this point would be a Windows equivalent.
I don’t know powershell . I’m largely Windows illiterate
(WSL doesn’t even have everything I need at this point. The old CIG_Win package comes the closest)
Of the options provided (purge, remove, clear, clean, delete) my vote is for “purge”. I would use “purge” when referring to stuff that can be re-created when prompted by an end-user action with a minor impact on key resources (time, storage).
This got me thinking about the drama of Doctor Who (Classic) “Castrovalva” (Season 19, Episode 2). The Master (The Doctor’s cackling foe) set the TARDIS on a course traveling back to the biggest explosion in history “Event One – The Big Bang”. Australia’s pioneering space and time traveler and, actually more capable space/time machine pilot than you might think, Tegan Jovanka, successfully jettisoned 1/4 of the TARDIS to avoid destruction. Disaster averted! TV series saved!
So, how about using the term jettison?
P.S. I’ve been using PlexDBRepair for about six months now. I use it on a regular basis (about twice monthly) to check and optimize several instances of Plex Media Server (2x Docker containers on 2x Unraid servers – total 4x instances of Plex Media Server). I love PlexDBRepair. Love your work!
As currently implemented in your script you’re basically forcing the Cache garbage collection that some users report isn’t happening. Thus the most technically accurate description in the tool should be something like “Force PhotoTranscode Cache Garbage Collection”. Since your menu system allows for the option of typing the first several letters, perhaps it could be reworked as “PhotoTranscode Cache - Force Garbage Collection,” thus creating the (probably) unique option “phot” if a user goes that route.
If we stick to the functionality, I think we’re better off.
The other terms are DB-centric but their meaning is clear.
This new function, while not DB-centric, must also have a clear meaning keyword.
We are selectively removing files from the photo transcode cache.
In this context, ‘prune’ is the better term.
to cut off or cut back parts of for better shape or more fruitful growth . prune the branches. intransitive verb. : to cut away what is unwanted or superfluous.
with emphasis on: to cut away what is unwanted or superfluous.
When the function completes, we’ll have only those image files which have been accessed within the last N (30) days.
I need attend family now. I’ll contemplate this a while longer before sharing a forum preview for review.
The problem with switching from mtime to atime is that many modern distros now recommend mounting with -noatime (at least if you are using an SSD). Using that as your filter criteria may not work the way you’d hope. I’m unsure of the outcome, but I’d suspect that no files will ever match because atime will be missing altogether.
While I like the term purge as well.. I have ‘remove’ coded in the menu
BUT it responds to both ‘purge’ or ‘remove’
Try it, you’ll see I reference both for now so we can gauge which looks best.
ALSO
I have the other part of this release ready for you all to kick the tires.
ZFS users will like this
Initial support for customizing DBRepair is a reality
Database ‘page_size’ may now be set. (DBREPAIR_PAGESIZE)
Environment variable DBREPAIR_PAGESIZE allows setting the DB’s internal page size.
– Linux ext4 & xfs users need not bother with this as the filesystem already matches the DB page size (4096)
– ZFS users can now increase the page size to match their ZFS datasets and recover some of the performance lost to HDDs
Must be a multiple of 1024
– May not exceed 65536 (SQLite limit)
– Rounds to the nearest 1024 multiple if you can’t do the math! lol
Can be undone by unsetting the environment variable and rerunning “automatic”
Cache age maximum may now be specified (DBREPAIR_CACHEAGE)
I like the sounds of Exsanguinate.
lol
is limited.
