How I ended up using PlexCache-D as my manual mover

[DeLo1585]

Hey guys,

First of all, I hope I’m not getting too annoying here. 😄 I feel like I’ve been pretty active around the project over the last week with issues, feature requests and a PR. So I promise I’m not trying to turn this into my personal support channel. 😂

I just wanted to share a little bit about how I’m currently using PlexCache-D, because I’ve ended up using it in a way that I didn’t really expect when I first started using it.

I currently have Tdarr running through a large part of my library to remove foreign-language audio tracks and subtitles. The processed files are written back to the cache.

This is mainly a one-time cleanup job, though. Once Tdarr has worked through my existing library, the number of files being processed will obviously drop significantly. After that, it will mostly just be handling new or changed files as they come in.

That means I currently get a lot of new files showing up under Maintenance → Untracked Files in PlexCache-D.

And honestly, I really like the way this works.

Instead of letting the normal Unraid Mover decide when everything gets moved to the array, I can go into PlexCache-D, see what Tdarr has finished processing, select the files I want, and then move exactly that amount of data to the array.

So for me, “Move to Array” has basically become my main mover. 😄

The nice part is that I can control the amount of data myself. For example, if I know I have enough time/network bandwidth for another 200–300 GB, I can just select the appropriate files and move them. Then I leave the rest on the cache until I want to move more.

It’s a pretty simple workflow, but it works surprisingly well for me.

That’s also why I suggested the total selected file size in my feature request #220 . When you have a lot of processed files, knowing that you selected 37 files is useful, but knowing that those 37 files are 284 GB is much more useful when you're basically using the feature as a manual mover.

I was curious if anyone else is using PlexCache-D in a similar way, especially together with Tdarr or another application that continuously creates/updates files on the cache.

Just thought I’d share the workflow. 🙂

[Brandon-Haney]

Not annoying at all, the reports over the last week have turned into real fixes, so keep them coming.

Thanks for writing this up, it's a use of Untracked Files I hadn't thought about. I went through the Move to Array code with your Tdarr setup in mind and found one thing worth knowing.

The normal caching run already treats the cache copy as the newest version: if a file on cache differs in size from its backup on the array (a Sonarr/Radarr upgrade, or a Tdarr pass), it copies the cache version across instead of restoring the old one. Move to Array in Maintenance didn't do that check. For rows marked Has backup or Has copy it assumed both copies were the same, restored the array version and deleted the cache copy. So if Tdarr ever leaves the old file on the array next to the processed one on cache, Move to Array would have kept the old version. Rows marked Cache only were always fine, those get copied and verified before anything is removed.

I've put up a fix in #222 so Move to Array follows the same rule as the caching run. Until that's in I'd stick to Cache only rows for anything Tdarr has touched, and only move files once Tdarr has finished with them.

Also worth keeping in mind that untracked files aren't on PlexCache's exclude list, so the Unraid mover will still pick up whatever you leave on the cache the next time it runs, unless you've changed the mover schedule or share settings. So it works as a "move these now" button alongside the mover rather than a full replacement.

[DeLo1585]

I made an observation today that (luckily) I only had 2 files in the plexcache, which i had a run through tdarr which Changes The Original file on the Array.

I can remember that I had a message in Maintrance that it changed you originals and I can clear the cache file.

But I didn't think about paying attention to which version would be restored and deleted.... But I still have the message about it

I'll check later which file was restored so I know if I need to process it again.

And I already have deactivated the unraid mover in my scheduling. Because the mover of plexcache is better at the moment😅😅😅😅

[DeLo1585]

Thanks a lot for the quick fix, Brandon, and sorry for the late follow-up.

I saw that #222 has already been merged, great turnaround. I haven't updated my container yet, so everything below refers to the version from before the fix.

About my two files:

Tdarr had modified the original on the array, and Maintenance told me I could clear the cache file. I cleared them via that hint before I used Move to Array, so Move to Array never touched those files, and the processed versions are still on the array.

That means my case neither confirms nor contradicts the scenario you described. It did make me wonder about the opposite direction, though: if the array copy is the processed one and the cache copy is the stale one, and both show up as Has backup / Has copy, would the new "different size means the cache copy is newer" rule copy the older cache file over the processed array file?

Since Maintenance already detects when the array original has changed, maybe that information could be used here as well. I haven't verified any of this.

I'll reproduce both directions with test files, first on my current version as a baseline and then after updating to the version with the fix, and report back with the exact Maintenance messages and results. If it turns out to be a real issue, comparing the modification time in addition to the size, or flagging the row for manual review when the array copy is the newer one, might cover both directions.