pretty sure it is configured to update on boot, so it would pull the file from github and replace your modified .txz every time.

So you could change the script in the .plg file to stop if from doing that, or even to pull from your own personal fork at boot.

 

Or you could have a small script that goes in and replaces the age_mover file after the fact, which is probably safe but remember to remove it if the plugin is properly updated again.

Hello,

 

I switched from the older Mover Tuning plugin to the one that supports v7 but I'm still on v6 for now. I've kicked off a manual move but it's been going for over 24 hours. I see the mover_tuning file growing in size. Is this expected?

 

I love the auto age process but I was wondering if there's a way to skip the priming of the cache. It'll end up filling in anyways over time but I figure it's sort of silly to move stuff to the cache drives only for it to be moved off in a few days.

 

Thanks

I switched to the "new" mover today because I realized the older one wasn't working anymore since I moved to unraid 7.  Here is my question because some options with size and date filters have changed:

 

1. I want to always move files older than 10 days... no matter what the % of the cache drive is full.  This option is either missing now or the first filter of:

 

2. Only move if above this threshold of used Primary (cache) space.  Why is it stated like this???

 

3. The old plugin had an option to run on size OR days.  This is what I want.  IF the size is over 75% run down to like 50% or something like that... and move the older files first.  BUT when it runs anything over 10 days is moved regardless of the % full.  I don't need anything over 10 days sitting on the cache drive.

 

Why was this in the old one but not the new one?  And if it does actually work like this "size OR days" then this needs to be more clear.  The first filter stated the way it is makes it sound like or is making it only run if its over a certain % full.  If this is the case and it doesn't even move older files anymore unless the % is met this needs to be changed back or at least the option to select OR.  

 

Thanks!

2 hours ago, slikone27 said:

Why was this in the old one but not the new one?

may as the author rewrite it completely and decided like this

 

and you are always free to use it or not, its a plugin written by someone in his free time, this is not a Unraid feature, its a extra plugin.

 

personally, this makes absolut sense to me as is, but it may doesnt fit your personal needs, so if you would like a feature and are not willing or able to write a plugin yourself, may rather ask if the author would implement the feature you would like to have ...

https://github.com/R3yn4ld/ca.mover.tuning/pull/69

If some one else can test will be cool ...

12 hours ago, alturismo said:

may as the author rewrite it completely and decided like this

 

and you are always free to use it or not, its a plugin written by someone in his free time, this is not a Unraid feature, its a extra plugin.

 

personally, this makes absolut sense to me as is, but it may doesnt fit your personal needs, so if you would like a feature and are not willing or able to write a plugin yourself, may rather ask if the author would implement the feature you would like to have ...

Apologies... That is what I was doing, it was just late lol... So is it indeed not working unless it goes over that % threshold?  Haven't had it installed long enough to see.  And could someone please add the "OR" option lol... For me I want to keep new shows etc on the cache drive for 10ish days (so people can watch them and they start quickly) and then after that time move them to the array regardless of the % full the disk is.  I like the % option as well incase I am grabbing large shows with lots of seasons etc and I want it to move stuff off when it gets full before it becomes completely full... Just really want the "Either/OR" so its whichever one comes first. @Squid

Edited February 7, 20251 yr by slikone27

5 minutes ago, slikone27 said:

So is it indeed not working unless it goes over that % threshold? 

 

yes

 

5 minutes ago, slikone27 said:

Just really want the "Either/OR" so its whichever one comes first.

 

should be pointed to @Reynald who is the current dev of this plugin

I doubt @Reynald is still active on the project, he hasn't given sign of life for more than a month, be it here or on Github. We might have to make yet another fork.

19 minutes ago, slikone27 said:

For me I want to keep new shows etc on the cache drive for 10ish days

 

Did you checked `Move files off Primary (cache) based on age` flag ?

10 minutes ago, foux said:

I doubt @Reynald is still active on the project, he hasn't given sign of life for more than a month, be it here or on Github. We might have to make yet another fork.

 

Well i posted pr based on @DToX_ changes for fix issue with spaces , i hope he will check/merge it ?!?

5 minutes ago, Masterwishx said:

 

Well i posted pr based on @DToX_ changes for fix issue with spaces , i hope he will check/merge it ?!?

We can only hope, but given his last message, it seems like he has moved on from Unraid to Truenas

 

 

3 minutes ago, foux said:

We can only hope, but given his last message, it seems like he has moved on from Unraid to Truenas

 

 

we can wait if no i can move it to my github and compile it but not sure if can handle along this project ... but prs will help ...

19 hours ago, MrMatt said:

Hello,

 

I switched from the older Mover Tuning plugin to the one that supports v7 but I'm still on v6 for now. I've kicked off a manual move but it's been going for over 24 hours. I see the mover_tuning file growing in size. Is this expected?

 

I love the auto age process but I was wondering if there's a way to skip the priming of the cache. It'll end up filling in anyways over time but I figure it's sort of silly to move stuff to the cache drives only for it to be moved off in a few days.

 

Thanks

I believe I solved the issue with mover running for a long time. I think it was due to having Docker as a directory instead of a vdisk. The directory had tons and tons of little files, many of which were hardlinked to many other files to keep the overall size down for duplicates. But this lead to the mover going through each file to figure out what it was going to do and taking a very long time.

 

I switched back to a vdisk and the mover ran a dry run in only a few minutes.

 

As for the second part, I guess it would be a one time issue, so maybe I'll just let the mover do what it wants and be done with it.

 

Overall, I like the newer mover tuning plugin, just some things to be aware of.

4 hours ago, alturismo said:

 

yes

 

 

should be pointed to @Reynald who is the current dev of this plugin

 

4 hours ago, foux said:

I doubt @Reynald is still active on the project, he hasn't given sign of life for more than a month, be it here or on Github. We might have to make yet another fork.

well shit that all sucks lol... how does the days even work then?  If I have that selected does it have to be over the threshold and past the days?  That really seems crappy.  I really want to move if it goes over a percent so the disk doesn't fill up but keep anything under 10 days on so people can start the episode without waking disks.  to me that seems like the best use for this plugin and how i always used the old one.

 

if he isn't active anymore... is anyone planning on forking it?

This might be a silly question but is it possible to have multiple Ignore file and folder listed text paths.

For example If I have 

File list path: /mnt/user/system/plexcache/plexcache_mover_files_to_exclude.txt is there a way to add an additional path/.txt file for it to check through/ say  

 

File list path: /mnt/user/system/plexcache/plexcache_mover_files_to_exclude.txt, /other/path/to/file/ignore.txt 
Or some other formatting to achieve this? Thanks! 

Edited February 7, 20251 yr by Healzangels

4 hours ago, slikone27 said:

if he isn't active anymore... is anyone planning on forking it?

 

Created a fork here, adding the fix for empty file path from @DToX_ and includes another bug fix that I discovered where the sparseness setting does not work at all. Untested as I'm away from home atm, but if someone could test and open issues/PR's as appropriate I'd be happy to merge them.

 

I rewrote the packaging code to make it easier to bundle it into a Github action later so definitely let me know in case the latest plugin archive doesn't work.

On 1/5/2025 at 8:00 PM, Reynald said:

Sorry if I were away for too long.

 

I'm going to catch my backlog and restart maintenance and updates of this plugin next week 

Hi @Reynald, may a Info note if you are still considering to maintain this project ?

 

just before we may cut here and open new support Threads for forks.

 

Thanks ahead for a Info

11 hours ago, slikone27 said:

if he isn't active anymore... is anyone planning on forking it?

Already forked and made pr. waiting if no reponce will try compile and post new version ....

if the plugin should unmount and destroy zfs datasets ?

49 minutes ago, Masterwishx said:

if the plugin should unmount and destroy zfs datasets ?

i cant imagine this plugin will touch anything on the FS ...

 

simple rsync from a to b by rules

Hey, I wanted to use the setting "Move files that are greater than this many days old: Auto".

Unfortunately this will calculate share usage of shares that have no mover enabled. The shares are on their own single disk pool for a reason, but the mover still is trying to calculate share usage, and on this single disk shares it takes days to calculate share usage.

 

Is there a way to not take single disk shares with cache disabled into account for the calculations of the AUTO settings?

 

 

Feb  8 09:11:10 Tower move: Primary storage: storjone - size: 19TiB - used:  38 % (6.9TiB)
Feb  8 09:11:10 Tower move: Secondary storage: none
Feb  8 09:11:10 Tower move: Share Information: Name: storj1 - Path: /mnt/storjone/storj1
Feb  8 09:11:10 Tower move: Mover action: no action, only storjone used (cache:only).
Feb  8 09:11:10 Tower move: => Nothing will be moved. Share usage is taken into account in the calculation of the threshold for other shares.
Feb  8 09:11:10 Tower move: Calculating share usage... (can take a moment)

 

The second to last line is what I'm referring to. Nothing will be moved but the share usage calculation will take days (and there are more of such single disk shares that come after this one)

25 minutes ago, alturismo said:

i cant imagine this plugin will touch anything on the FS ...

 

simple rsync from a to b by rules

Yep, checked again can't find in code, but unraid mover has it, will try to add it to plugin... 

Should we get the older incompatible mover tuning plugin version formally added to the 'known issues' for v7.0.0 release?

Also could we possibly work with the 'fix common problems' code to highlight the issue for those who were unaware and have upgraded already i.e. before filling up other old plugin users cache pools? Maybe even consider the new automated unRAID patch mechanism to upgrade from old to new plugin versions although I saw a post above that might be conflicting? Just wondering how many other folks out there might've upgraded to v7.0.0 and not yet noticed their cache pools filling up and also have no idea why

Is it worth asking @Squid to temporarily add a warning to the top page for this thread?

 

In the meantime for anyone else just wanting an emergency quick fix on unRAID 7.0.0 - removing the old incompatible mover tuning plugin and running the stock mover should work before adding the newer fixed plugin version back and configuring it again.

On 2/8/2025 at 4:17 AM, Masterwishx said:

we can wait if no i can move it to my github and compile it but not sure if can handle along this project ... but prs will help ...

Yeah, a long time ago I added some functionality to this plugin and had the intention of probably taking it over once hugenbdd was planning on moving on. Eventually I decided I would rewrite the plugin from the ground up because the code was starting to become janky implementation slapped on top of more janky implementations and it was just getting too messy to even consider adding more advanced functionality. I progressed pretty far but graduated and got a full-time job as a robotics engineer and never touched it again...that was about a year ago. Turns out it's really hard to have spare time / effort and energy when you have a full-time job lol. I've got a lot of respect for the people that seem to have a million side projects and somehow balance them with a good work-life balance.

 

I would like to pick up my development again because I had a lot of fun doing it, but I probably won't publish it because I can't commit to maintaining it and there are so many changes for me to go back and read. It's more of a class / object oriented approach so additional functionality can just be added in quite easily. I need to learn how to write tests for it because doing manual testing is so killer and wastes so much time, but having to write tests is also time consuming and not very motivating.

1 hour ago, Swarles said:

I would like to pick up my development again because I had a lot of fun doing it,

would be great

 

i even wrote myself a "simple mover" plugin for now, abusing the ignore function from mover tuning (which works) as i didnt wanted to replace the buildin mover ... but mine is mainly designed for media moving ... way more simple, but fast

 

lets see what time brings