Swarles

See item #3 on the FAQ. Make sure the file is readable, double check the file is actually in that location, it's likely that the mover could have moved it after the first run. If it still isn't working, you'll have to provide the latest ".logs" files for me to see what is going on. See item #1 on the FAQ for providing logs

The way it's done on the share page is an onclick event that calls the following: $.post("/plugins/ca.mover.tuning/moveShareNow.php?Share='<?echo $shareName?>'"); The "moveShareNow.php" script executes the following: exec("/usr/local/emhttp/plugins/ca.mover.tuning/share_mover {$shareName} >> /var/log/syslog &", $output, $retval); You can definitely call that script from cmd and just provide the share name as an argument: bash /usr/local/emhttp/plugins/ca.mover.tuning/share_mover 'shareName' NOTE: The share_mover script in the current plugin does not consider the mover tuning settings and will move everything off that share

FAQ - Frequently Asked Questions I'm putting these here for some of the common problems, and will try to update it as more questions/issues come along. How do I enable logs / provide logs? Mover wont run after installing Mover Tunning? Mover isn't ignoring files or folders? Issue Reporting Template

Oh okay during boot makes sense, I have found the issue. line 113 of "ca.mover.tuning.plg" if [[ ! -f /usr/local/bin/mover.old ]]; then mv /usr/local/bin/mover /usr/local/bin/mover.old; fi I uninstalled the plugin and rebooted and it would appear that unraid does not initialise a "mover" file in "/usr/local/bin/mover" (on 6.12.8 at least). "move" is located in "bin" and "mover" is located in "sbin". I don't know enough about unraid to know why this is the case or what the configuration is in older OS. It's probably important for people on older OS. I can confirm that this is not an issue to worry about though. We could change it so it checks if "mover" exists rather than if "mover.old" doesn't exist, thoughts @hugenbdd? If it is really bothering anyone, for the time being you can remove the line in "/boot/config/plugins/ca.mover.tuning.plg" or suppress its output.

@2TC @modem7 @BazzT92 @wgstarks Hmm I can't seem to recreate this issue after having updated to 6.12.8. Would someone with the issue be able to clarify the following: Does this error message happen whenever Mover is trying to start or during boot of the machine? Does this error message happen during scheduled mover or when using "Move" button on main page? (With "Move now button uses mover tuning" enabled.) Can you verify that the file exists manually? ls -l /usr/local/bin/mover Output: -rwxr-xr-x 1 root root 161 Feb 25 11:05 /usr/local/bin/mover* Are the permissions the same as above? Check the cron entry and verify cat /etc/cron.d/root Output: # Generated mover schedule: 40 3 * * * /usr/local/sbin/mover |& logger Check if your output is the same. If you verified both steps 3 and 4 to be true, try uninstalling the plugin, reboot, and reinstall. You can backup your settings with the following: cp -r /boot/config/plugins/ca.mover.tuning /boot/config/ca.mover.tuning.backup Once you have reinstalled, you can restore your settings with: mv -f /boot/config/ca.mover.tuning.backup /boot/config/plugins/ Let me know if issue persists.

Thanks! I'm in the process of implementing similar functionality in the plugin and also fix some bugs. It might be some time though so for the time being I think this is an excellent solution for those that want it Great work and appreciate the effort!

There could be a couple reasons this is happening, it sounded very similar to an issue posted a week or so ago but I have checked and it is not quite the same. It seems as though it is encountering an non-numerical value and thus cannot perform the numerical operation. While we could simply put in some code to handle and ignore these cases it would be beneficial to understand where it is coming from. If you are still occasionally receiving the error, could you please turn on mover logging and test mode and then provide the latest file located at "/tmp/Mover/Custom_Mover_Tuning_[TIMESTAMP].list" If you don't know how to enable these settings:

Oh yep, that'll do it, fixed now. Should be fixed in the next update. Thank you for spotting that

Can you confirm if the path that exists is, /mnt/cache.nvme or /mnt/cache_nvme It could be that perhaps the code is treating the ".nvme.cfg" as the full extension and removing it, but I have checked this and it should not be the case. But for a better understanding you should provide some logs. Go to Settings>Scheduler>Mover Settings Set "Mover Logging" to Enabled. Go to the Mover Tunning settings and set "Test Mode" to "Yes" Set "Move Now button follows plug-in filters" to "Yes". On the Main tab press the "Move" button to run the mover. Running in test mode will generate logs but not make moves. Go to "/tmp/Mover" and get the most recent file ending in ".log" You can revert test mode and logging now. You can supply the .log contents here in a spoiler or send them to me privately. This might help me understand why you are experiencing behaviour that is unexpected.

The mover tuning plugin uses the cache pool configuration files located in "/boot/config/pools" to determine what pools exist and their settings, check to see if you have a file called "cache.cfg" in there in addition to your "cache_nvme.cfg" file. Let me know if you don't have one, or if you only have "cache.cfg" check inside it to see what the cache name reports back.

Not 100% sure but it seems like you might be getting an invalid file size for some of the files that are performing an array>cache move. Could you check the contents of your "/tmp/Mover/Custom_Cache_Tuning_$NOW.list" file, you may have some entries that are missing a number at the end.

Can you confirm if you have a cache pool called "cache" and if the location "/mnt/cache" exists? My first thoughts are that your cache pool is not called that but you may have some left over cache pool config files located at "/boot/config/pools". Check that location and see if all your pools are correct.

Just to clarify, the mover tuning plug-in settings won’t affect “Array > Cache” shares, but the mover itself still affects them. They will be treated as if it was the normal mover and an attempt to move all files in that share from the Array to the Cache will be made regardless of the settings in the mover tuning plug-in. The mover tuning plug-in settings only affect moves made from the cache to the array. You’ll notice that if you click into a share, the option to override the global mover tuning settings is only available for “Cache > Array” shares. This is not to say that it can’t be supported in the future, it just hasn’t been so far and is probably a pretty niche use case.

Have you tried testing it or are you just going off the code? That part of the code is only meant to exclude the top level folder path or individual files if they have been specified in the exclude list, it doesn't exclude anything underneath a folder. The find string will then use a -not -path "/mnt/cache/MyShare/KeepOnCache/*" to exclude the files underneath the folder.

What issue are you noticing? Inside the "exclusion.txt" file you will need to make sure that each path for exclusion is going through the "/mnt/cache" pool name share and not the "/mnt/user" share. You also need to make sure that if you are using the override settings for a particular share, you should include the exclude list inside those override settings too because it won't use the global exclude list.

Yeah it's not possible at the moment because the threshold is for the entire pool and in it's current state, the logic is not there to be able to easily implement it for shares. I will be looking to implement this eventually, but it will likely come with a big rewrite of the mover tuning logic so I wouldn't expect it anytime soon. Some considerations need to be made like which thresholds take precedence. For the share that you want to move daily, are you using any other mover tuning settings? There would be a way to setup a Cron job to always move that share but it would ignore the mover tuning settings, similarly to pressing the "Mover share now" button under the shares settings.

Yeah so it should only be the source of the issue if you had "Override Mover Tuning settings for this share:" set to "Yes", but didn't have the skip list supplied. It's a sort of feature flaw that's a result of how the per share settings is implemented. If you had it set to "No" then it should be a different problem.

Hmm strange, might need to provide some logs to really get to the bottom of this. If you enable logging in the mover settings under scheduler, you can also put it into test mode, so that it doesn't move anything but will still go through the whole process. Then you can find logs in the syslog and at "/tmp/Mover". My initial thoughts are: If you're using the mover tuning settings override for the "data" share, make sure that you enable the skip list and provide the list in those settings too. Double check that "Skip files listed in text file:" is set to "Yes" and that the correct path is supplied under "File list path:" Perhaps the list is written in CTLF instead of LF. Recreate the skip file using nano in terminal: nano /mnt/cache/appdata/ignore.files *paste in your list* *ctrl+o to save* *ctrl+x to exit* Run in test mode again to see if it ignores the list.

What path are you using in your skip list? You will want to always avoid using “user” and instead use the name of your cache pool. Eg. /mnt/user/data/media/linux-isos <--Bad /mnt/cache/data/media/linux-isos <--Good

I took a quick look at your latest log, my first guess is the threshold. 1) Threshold: currently set to 50%. Files won’t be moved at all until more than 50% of your cache is exceeded. From the logs it appears your highest cache is only 49% full? So you could try reducing the threshold to see if it moves the files, or loading on more content. 2) Also your move-all threshold is set to 95%, this won’t be causing issues but is important to know that if the cache storage ever exceeds 95% it will attempt to move everything off, ignoring all mover tuning settings.

I think you're the first to mention it, I have my files set to move over 30 days and it is working just fine on 6.12.4 with zfs. Would you perhaps be able to share the ".log" file in "/tmp/Mover" which should give more information on what the mover is actually doing (can send in pm if you want, or review it yourself). The ".list" files also show lists of what files should be moved.

You should be able to put the ignore list .txt anywhere, I personally put the skip lists on my usb. It has been a while since I did the implementation and testing, but I thought I made it so that it could handle spaces just fine. Best practice is to not use spaces in paths though.

Which one? For step 3 did you check if the relevant line was inside the file? Step 4 only requires checking if the file exists.

In mover tuning settings, enable "Ignore files listed inside of a text file:" setting. Below it, supply a path to a .txt file that will contain the paths of the files and folders you want the mover to ignore. eg. /mnt/cache/files/ignore_list.txt And then inside the .txt file supply the path to the folder you want to ignore. If the folder is called "CatPics" it will be like this: /mnt/cache/files/photos/CatPics It is very important that you supply the path to the cache pool ("cache" in my example) and not on the "user" share. If you supply "/mnt/user/files/photos/CatPics" it won't skip the folder on the cache.

Hey, sorry for the delayed response, very very busy. The following link is a comment I created a little while ago to try to troubleshoot issues. You can ignore MOST of it. Just skip to steps 3 and 4. Try those and let me know if one of those was your issue