ok thank you that helped a little. What i'm trying to do is keep large files like movies/tv off the cache, otherwise keep the most recent files moved to the share on the cache, up to 80% of the cache's capacity (Or something like that) has anyone setup a system like this?

1 hour ago, bobloadmire said:

(Or something like that) has anyone setup a system like this?

You can check some pages back for this

I wish there was an way to specify folders that should always included in a move, ignoring other settings.
For example, I have sat it to generally move files above 30MB off the cache.
I wish I then you could also specify that content in X folders is always moved off the cache.

2 minutes ago, Mihle said:

I wish there was an way to specify folders that should always included in a move, ignoring other settings.

For now you can only ignore files, folder etc

And use other settings currently available...

56 minutes ago, Masterwishx said:

You can check some pages back for this

any idea how I would find this? there's 137 pages. We really should have github discussions for this.

29 minutes ago, bobloadmire said:

any idea how I would find this? there's 137 pages

Just list a couple of pages back or search for synchronise in the thread

I have had an issue that I dont think was caused but he mover, but how mover works may have Affected what happened.

In short, My NAS went down while mover was running I think? Or at least while I was uploading quite a bit of data to my NAS.
When it came back online, things looked fine.
Unraid GUI/file browser said the data was in cache still.
But, when the mover did run again, both on schedule and started manually, there was some uploaded files on a share that should have been moved in a share, that wasnt moved. May be relevant at the time I set it to use mover not rsync but changing to rsync after the fact doesnt change it.
Not even while going to the share and pressing "move now" button that is supposed to ignore settings didnt seem to move it either.
But new uploads to the NAS was moved as they should when mover did run.

So, I am thinking maybe the mover "lost track" of the files being on the cache while Unraid file browser said they still where dere? Is that possible?

Edited December 15, 2025Dec 15 by Mihle

15 hours ago, Mihle said:

So, I am thinking maybe the mover "lost track" of the files being on the cache while Unraid file browser said they still where dere? Is that possible?

Every time you run mover tuning it check your plugin settings and make new lists of moving files. You can check them in /tmp/ca.mover.tuning/*.list.

So its make new files lists every run...

My current config, mover allows cache to fill up to 80%, then moves data to the array until the cache has 70% utilisation. But it's unclear to me what the 3rd option does (bellow configured to 0%).

I think because the helper is using the legacy terminology it's confusing me more (doesn't take a lot!)

How I read interpret this setting, is that is moves data from array > cache (until the cache hits this threshold of used space?) But under what circumstance? What's use case is there for moving files form the array > cache (until x% of cache is full)?

And in my case, where I don't want to move anything from array to cache , is 0% the right setting?

I susspect I'm missunderstanding the use case / purpose of this setting, hence would appreciate anyone who's able to help.

Thanks

Mover still seems to run when parity check is running. I have a check running and ca mover is still kicking off and running. version 25.12.13 on 7.2.2. Going to just temporarily disable ca mover but may be something to look into.

EDIT: I do have it set to not allow mover when parity check is running

Edited December 16, 2025Dec 16 by totalhavoc

Yesterday I setup the Mover Tuner as per Trash’s guide and I set dry run to true and ran a “move now” on the plugin and fclone repaired hardlinks.

I thought nothing was suppose to happen in a dry run?

It also stopped qbm and didn’t restart qbm at the end of the run.

Unraid 7.2.2 and the CA latest version of the plugin.

Has anyone noticed this behaviour before?

Today I’ll run another test as per the schedule I have set and see what a “normal” run is meant to do.

On 12/16/2025 at 4:28 PM, johnyb said:

I think because the helper is using the legacy terminology it's confusing me more (doesn't take a lot!)

Secondary to Primary it's the new terminology, cache:prefer the old one.

You can see also array->cache.

Thease all mean move data from secondary storage to primary (cache) until cache filled xx%.

So if you don't have share like this, you can leave default.

On 12/16/2025 at 4:39 PM, totalhavoc said:

Mover still seems to run when parity check is running. I have a check running and ca mover is still kicking off and running. version 25.12.13 on 7.2.2. Going to just temporarily disable ca mover but may be something to look into.

EDIT: I do have it set to not allow mover when parity check is running

How do you run the mover?

Is mover was runned after parity check is already running? Can you post the syslog of starting the mover after parity check already running?

8 hours ago, Dhoges said:

Yesterday I setup the Mover Tuner as per Trash’s guide and I set dry run to true and ran a “move now” on the plugin and fclone repaired hardlinks.

I thought nothing was suppose to happen in a dry run?

It also stopped qbm and didn’t restart qbm at the end of the run.

Unraid 7.2.2 and the CA latest version of the plugin.

Has anyone noticed this behaviour before?

Today I’ll run another test as per the schedule I have set and see what a “normal” run is meant to do.

If you think have issue, you can open github issue for this

12 hours ago, Masterwishx said:

How do you run the mover?

Is mover was runned after parity check is already running? Can you post the syslog of starting the mover after parity check already running?

built in mover is disabled as suggested with new versions. It's configured to run via "Mover Tuning schedule:" cron kicked off age_mover every time even with parity check running. Check is done now but I do have a drive to install in a few days which will cause another check. I'll post logs then.

18 hours ago, totalhavoc said:

Check is done now but I do have a drive to install in a few days which will cause another check. I'll post logs

then.

If I run parity check then move button, I got message in syslog that mover tuning not running Becouse of parity check

I am having the same issue of the mover running during a parity check. Unraid v7.2.3 and plugin v2025.12.13.

It is causing the parity check to be extremely slow. Goes from 1 day to 50+. When I pause parity I see the message that mover is running. Have to force stop mover. Disabled for now while the parity check runs.

7 hours ago, Space409 said:

I am having the same issue of the mover running during a parity check. Unraid v7.2.3 and plugin v2025.12.13.

I will check it... Maybe when mover tuning runned by cron some bug exist...

On 12/19/2025 at 11:08 PM, totalhavoc said:

cron kicked off age_mover every time even with parity check running.

Yes a bug exist, Will be fixed in new version.

Is it possible to fully disable the cron job for this? I disabled the built-in Unraid Mover, but the Mover Tuning schedule still seems active. I’d like to disable that as well, because I only want the mover to run when I manually trigger /usr/local/sbin/age_mover start from my script.

2 hours ago, JonasH said:

Is it possible to fully disable the cron job for this? I disabled the built-in Unraid Mover, but the Mover Tuning schedule still seems active. I’d like to disable that as well, because I only want the mover to run when I manually trigger /usr/local/sbin/age_mover start from my script.

Yep, this will be fixed in new version, will release it today

@Masterwishx

Is there anything that needs to be set with owner rights and the plugin?

Files I extracted today through a Windows VM have a specific user ownership instead of Nobody. I noticed during the scheduled-tuned-move tonight those new files were being moved and not following the rules set for age, as the archives themselves did not move?

2 hours ago, RowdyBurns said:

Is there anything that needs to be set with owner rights and the plugin?

No it should be managed automatically.

2 hours ago, RowdyBurns said:

I noticed during the scheduled-tuned-move tonight those new files were being moved and not following the rules set for age, as the archives themselves did not move?

Need more info for it, post debug.zip

Recently I've noticed a lot of errors when moving using rsync. I'm running Unraid 7.2.2, ca.mover.tuning plugin version 2025.12.21.

Dec 30 04:11:09 vault move: Moving "/mnt/cache/./backups/My-PC/.directory_pool/Hm/Hm1xtLoM3T17669522931091642465/Collection Collage - Bob's Top Albums of 2023_ Top 100.zip" "/mnt/cache/./backups/My-PC/.directory_pool/RN/RNrLvrHkZy1766681513820862178/Collection Collage - Bob's Top Albums of 2023_ Top 100.zip" "/mnt/cache/./backups/My-PC/.directory_pool/XC/XC9RKQvneP1766591317730667060/Collection Collage - Bob's Top Albums of 2023_ Top 100.zip" to /mnt/user0/
Dec 30 04:11:09 vault move: 6089 files remaining from caches to array (255GiB)
Dec 30 04:11:09 vault move: Moving "/mnt/cache/./backups/My-PC/.directory_pool/Hm/Hm1xtLoM3T17669522931091642465/Collection Collage - Bob's Top Albums of 2023_ Top 100.zip" "/mnt/cache/./backups/My-PC/.directory_pool/RN/RNrLvrHkZy1766681513820862178/Collection Collage - Bob's Top Albums of 2023_ Top 100.zip" "/mnt/cache/./backups/My-PC/.directory_pool/XC/XC9RKQvneP1766591317730667060/Collection Collage - Bob's Top Albums of 2023_ Top 100.zip" to /mnt/user0/
Dec 30 04:11:09 vault move: rsync: [sender] link_stat "/mnt/cache/backups/My-PC/.directory_pool/Hm/Hm1xtLoM3T17669522931091642465/Collection Collage - Bob's Top Albums of 2023_ Top 100.zip" failed: No such file or directory (2)
Dec 30 04:11:09 vault move: rsync: [sender] link_stat "/mnt/cache/backups/My-PC/.directory_pool/RN/RNrLvrHkZy1766681513820862178/Collection Collage - Bob's Top Albums of 2023_ Top 100.zip" failed: No such file or directory (2)
Dec 30 04:11:09 vault move: rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.4.1]

It took me a while to figure out what was happening, but it seems to be that the mover tuning plugin doesn't know when files are hardlinked, so it runs an rsync command for every instance of the file it finds, regardless of whether or not a hardlink exists. When it moves it the first time, the file (and all its links) are successfully moved, but since the file is no longer on the original drive, when it attempts to move the same underlying file again in a different filepath, it errors out, spitting out thousands of these erroneous warnings and errors.

Switching the moving utility from rsync to the original mover does seen to fix it (or at least I don't see all the errors). However, I would like to be able to use rsync if possible, so if that could be fixed it would be awesome.

I also noticed that when I try to run any age_mover --help or age_mover status command while it is running, there is no output.

3 hours ago, happa said:

plugin version 2025.12.21.

Update to the latest version