Closed danrahn closed 6 months ago
I got info from Plex today.
HKLM and HKCU are used. (64 bit native and with 32bit on 64) There are also legacy with wow6432 node stuff.
Would that help supporting various 32-on-64 and 64-64 installs?
Separate thought..
There was the idea of putting the whole script in PS.
Given the tool is a big while loop with functions, how tough would it be to just port the whole thing?
FYI. Another piece of info:
There is an OPEN TICKET. The AppleTV app makes a lot of requests for transcoded posters and is the biggest reason for the uncontrolled growth.
While it makes sense to add prune, Plex Engineering has the task to find a 'reasonable' size for the cache.
HKLM and HKCU are used. (64 bit native and with 32bit on 64) There are also legacy with wow6432 node stuff.
I can look into checking WOW6432Node
as well. From what I can tell, that should only affect InstallFolder
though, at least as far as entries we care about goes (InstallFolder
and LocalAppDataPath
). I can't definitively say that's the case though, other than Plex's support docs saying it should be set in HKCU
).
There was the idea of putting the whole script in PS.
Given the tool is a big while loop with functions, how tough would it be to just port the whole thing?
That's something I was considering as well. I really just have a passing familiarity of PS and Batch, but I don't think it would be terribly difficult to port everything over, and it'd be nice to keep everything contained in a single script. Not sure when I'll have the time to dig into it, but hopefully within the next week, if not sooner.
My expertise with windows will fit on a 8" floppy disk. LOL I don't know how that all works
As for the big PowerShell script with the functions, in a big "loop until told to exit / quit" hope it wil be easy.
As a quick update, I took a stab at porting the existing batch script to PowerShell, and have an initial implementation that after some very light testing seems to do the right thing (https://github.com/danrahn/PlexDBRepair/commit/e4d99393ebdfd1836b99d87fab42a6decddc0eb8). Currently it just takes named parameters and will do them in a set order if present (Stop > Auto > Prune > Start), but I'm hoping to look into the "loop until told to exit / quit" tomorrow (but probably keep the limited feature set for now, to be expanded upon later). If I'm able to get that in a good state I'll abandon this review and open a new issue/PR for "convert everything to PowerShell".
Add support for
prune
on WindowsThis change also adds some initial command-line options, maintaining existing behavior - that is, passing in no arguments results in automatic database maintenance/rebuilding and nothing else:
-prune
cacheAge
.-cacheAge [age]
-skipDB
This change also introduces a PowerShell script that does the actual pruning, since efficiently working with dates in Batch is pretty much a non-starter from what I can tell. The only okay solution I found was to create a temporary file with a manually set modified date, then use
xcopy
to do a dry-run (/L
) date-based (/D
) copy of that temp file to a PhotoTranscoder image. If the dry-run tells us the copy would succeed, we know the photo is older than our maximum cache age. While that worked, it was very slow on my system, taking 8-10 seconds per 1,000 files, while the PowerShell approach took ~5 seconds for all files (>80K), a >100x improvement.Validation:
Ran
DBReapir-Windows.bat
with various combinations of arguments:-prune
- databases successfully rebuilt, images older than 30 days successfully removed ("Removing 6184 files over 30 days old (out of 86082 files), freeing 1.54 GiB").-prune -cacheAge 29 -skipDB
- skipped database rebuilding, images older than 29 days successfully removed ("Removing 1173 files over 29 days old (out of 79884 files), freeing 223.96 MiB").cacheAge 28 -skipDB
- Does nothing, both pruning and DB repair skipped.Fixes: #148