Swarles

Yes this is correct, though I think the description could probably use an update because as you said it doesn't reflect this. It will probably take me another 5 weeks before I work on anything as I am in the process of finishing up my studies. In the meantime, even the old code worked for skipping folders (just had a few edge cases). I suspect you may have given it a path on the "user" share, you will want to make sure any file or folder paths you give it are on your "cache" (or whatever yours is called) share/drive. Eg. /mnt/user/data/media/linux-isos <--Bad /mnt/cache/data/media/linux-isos <--Good This happens because mover tuning never goes through the "user" share and only deals with "cache" and "disk#" directly. I may create a fix for this in the future where it detects if it's on the user share and replaces it with the cache, but this could potentially be problematic on systems with multiple cache pools. Hopefully that fixes, your issue

Haven't had the update pushed yet so every time you restart the server it will revert unfortunately. I know it's not ideal but I think it's a bit of work to push an update so just have to wait until hugenbdd has some spare time. Would you be able to confirm if you have "Move now button uses mover settings" enabled though?

If it's just a random file or folder within a share then do the move manually, recommend going into the cache and moving it to the disk# avoiding "user". If you want to move everything on just one share, go to the "Shares" tab and click on the share. There should be an option to move all from the share underneath per-share mover settings. This doesn't follow plugin filters and will move everything on that share to the array.

Hmm okay strange because this is how the mover tuning plugin runs the scripts. Only other thing I can think of without digging deeper is if they are executable? Try the following: ls -l "/mnt/user/[FILEPATH]/script1.py" and if it is not executable (there are no -x in it) try this and run it again: chmod +x "/mnt/user/[FILEPATH]/script1.py"

How are you running your script? Does your script have spaces in the path (this shouldn't cause issues)? "./script" or "python3 /script"? Can you try the following for me in terminal: eval "/script" and eval /script

Test mode won't actually move any files so they won't appear in syslog. You have to go to "/tmp/Mover" and look at the .list files. Those will show the files that will be moved. That's also were you'll find the detailed mover tuning log file. I'm wondering if on the latest unraid when you update a plugin if it removes the .cfg file for its settings. I'll have to test.

Some great info thanks! Yeah I suspect the "ca.mover.tuning.cfg" missing is the main culprit for people whose movers aren't doing anything at all. I'm just not sure why it's come up, nothing in the code relating to that changed in the latest update. Hmm. Fix should be pretty easy to issue though regardless.

Oops, I edited my message to make it make more sense haha. I think adding the link to the unclean troubleshooting is a great idea, could also potentially result in less people asking here what to do. I'm not sure if this is helpful, but I collected system logs during my shutdown procedure and start up procedure (which resulted in the spurious "unclean shutdown" message). I was preparing to make a post asking about it in the forums because I hadn't initially realised it was incorrect and couldn't figure out why it was unclean. If you think those system logs might be helpful at all I'd be happy to send them through.

Oh man I just had my first power outage that was long enough to require my server to shutdown. Boy was I annoyed when I still got an unclean shutdown message after power came back! Very glad to know it is just a bug, I just finished my quarterly parity check this morning! EDIT: I completely forgot to mention the part where the power outage was long enough for my UPS to issue the shutdown. I thought my UPS had gone ahead and failed or something resulting in the unclean shutdown.

Tagging some people this is relevant for (don't have to do it if you don't want): @Robbie G78, @Kloudz, @sourCream, @wibble, @WWGT, @knights_of_pine, @Chunks, @Taddeusz, and @Magic815 Okay so for everyone where the Mover Tuning Plugin is no longer working and the mover wont run please follow these steps to help me figure this out Fill out this quick template: Troubleshooting - Try each step one at a time, if it does not fix your issue try the next one: Enable mover logging! "Settings>Scheduler>Mover Settings" (Manual Moves Only): Is "Move Now button follows plug-in filters:" (In "Settings>Scheduler>Mover Tuning") set to Yes? If not, make this change and run the mover again. If this now works, PLEASE LET ME KNOW. Check to see if "share.cfg" exists. Check to see if "ca.mover.tuning.cfg" exists. Check to see if all your user shares exist in "/boot/config/shares" If all else hasn't worked please try make changes to the "mover.php" file. If you run through these steps and it is WORKING please add the following to your starting template: If you run through all the steps and the is is still NOT WORKING, please add the following to your starting template: Thanks guys, doing these steps and reporting back to us will really help us figure out what exactly is wrong. None of these issues are occurring for me personally so it is very hard to troubleshoot.

So from my understanding the Mover Tuning Plugin just goes through each share listed in "/boot/config/shares/" and for each share it will determine which pool it is part of and then calculate if that pool is over the global threshold which in your case is 50%. Currently there is no way to set this value on a per-pool basis, so it should run on your Download_drive and not your Cache, as it stands. Files not moving could be a couple things, it would be easiest to determine why with the latest ".log" file in "/tmp/Mover". You may have other settings enabled in Mover Tuning Causing most of the files to not be moved. Perhaps you are experiencing the same issue that others here are experiencing with the Mover not working properly when mover tuning is installed. In complete honesty, I have no idea what is causing the problems. I will make a post below, please try those steps.

This is primarily the behaviour the per-share settings were made for, so that is definitely possible I'm glad you included this information as it may be your issue. The Move button on the Main tab ignores the Mover Tuning plugin by default. What you should do is ensure the "Move now button follows plugin filters" option in 'Settings>Scheduler>Mover Tuning' is set to "yes". This will use your mover tuning settings when manually hitting the run button. On a side note, are you also on the latest Mover Tuning plugin update? It is interesting your mover tuning is working with the latest Unraid and moving all files, a lot of users have said it is no longer working for them. It's a strange divide. Hmm.

They need to have actually run in the background for the logs to be created. If you just run them manually it won't pop up unless you use the run in background button. It's most likely they just haven't executed yet.

Oh lol I literally just did that today? I can run any of my User Scripts scripts from the usb using "bash script" I suppose I can't make them executable with "chmod +x script" or run them like "./script".

I have found some very strange behaviour with CA User Scripts and was hoping to get some help on it. TLDR: Behaviour different to executing script in terminal. When making sqlite database query to pull info it is consistently leaving some of it out. The specific command I am running is to grab chapter information out of an audiobook in the audiobookshelf database. echo "$(sqlite3 -readonly "/mnt/[path-to_db].sqlite" \ "SELECT chapters FROM books WHERE title = '[booktitle]';")" Running this command in terminal behaves as expected. Running the script in user scripts causes some of the data to be excluded. It consistently breaks at the same point for the same book and for some books it might not break at all, for some it might remove some data from the middle, or it might only take some data off the end, but it always has the same behaviour for the same book. Running from user scripts but in the background also broken. Running the script in terminal but directly from "/boot/config/plugins.../script" (so the script created by user plugins) works as expected too.... There is no correlation between where the data is missing from either. For example it doesn't break after 1024 characters, it doesn't break when encountering a certain letter or symbol. It's just so weird. Any help or insight would be much appreciated. I can only assume it's something different in the environment or how user scripts prints out stuff.

Do either of you get the "mover: started...mover: finished" syslog? Also, are either of you using the "Move now button follows plugin filters" set to yes? Robbie G78: Being able to invoke the mover from the share is strange because it calls the mover in the same way that using the move button and the schedule does. Just and FYI I am on 6.12.3 with Mover Tuning 2023.08.22 and both the schedule and move button working for me. Strange indeed.

I agree this feature would be very nice to have as I use my cache pool in the same manner. So I am just letting you know that it is certainly in my sights and at some point I would like to implement it However, there are some factors that need to be considered making it's implementation time consuming which means it likely won't be added by hugenbdd or myself in the near future. I wont have free time for a couple more months. Some of these considerations are: When a cache pool starts to exceed it's threshold: Should the oldest files be moved first? Should removal be based on ctime, mtime, or atime? Should these settings be configurable? Should they be configurable per-share in the pool? Should the user be able to have a preference system for which shares on the pool are targeted first? Should a limit or threshold be specifiable for individual shares? Eg. on a 1TB pool, should you be able to "allocate" 200GB to "share1" which if exceeded performs the balance. What takes precedence when there are other mover settings stopping the oldest files from being moved? What if the other setting stopping files from being moved affect many files to the point where moving all the allowable files doesn't bring it below the threshold? Then there are considerations on where and how all this should happen in the code which need to be worked out. This is sort of to just provide an update on where my thought process is at. I can answer many of these questions myself but I know that implementing all of it will take a while + testing, and I won't be starting it for at least 2 months. With that said if you can think of more features I am more than glad to hear them, I'll mull them over in my mind for now.

I'm running zfs on my system and it appears to be working as expected, folders on cache are being deleted. If the folder isn't removed on second run like hugenbdd said, can you specify if these said folders are datasets themselves? If they are this would make sense as datasets need to be destroyed and can't be deleted normally.

My first guess will be that perhaps you are missing the shebang at the beginning of your script? The shebang has to be on line one and point to the location of your python interpreter. For example: #!/usr/bin/python3 But edit it ^^ to make sure it is your location. This is my best guess and you should test you can otherwise run your script with just "./mnt/user/[rest of path]/1.py" in the terminal. If it does run properly but the shebang doesn't fix it, you will have to go to /tmp/Mover and provided the latest ".log" file in there for me to see what the mover is doing.

Yep that appears to be your issue as I don't see anything else wrong. The process appears to be fully executing but just not finding any files to move. Check the following location: ls /boot/config/shares You must have a file called "Media.cfg". I'm not sure how unraid processes this side of things, did you at any point rename the capital letter? If you directly rename the file to "media.cfg" it will work for the mover tuning plugin, not sure how unraid will handle it. Perhaps try renaming the share (in settings) to something completely different, saving etc, then renaming it back to "media" and see if it changes

I can try help with this, first thing to check would be if "share.cfg" exists. Go to “cd /boot/config” and identify if “share.cfg” file exists. If it does, verify that the line 'shareCacheEnabled="yes"' is in there. If no to either 1 or 2, do one of the following: To have the file created by the system, edit your global share settings (edit, save, revert). "Settings>Global Share Settings" OR; Paste the following in the terminal: echo shareCacheEnabled='"yes"' >> /boot/config/share.cfg If the file did exist and you verified step 2, do the following: Enable Mover Logging. Set “Move Now Button Follows Plug-In Filters” to yes. Set “Test Mode” to yes. Run mover. Go to “cd /top/Mover” and share the contents of the most recent ".log" file.

Use the "Skip Files List" setting. To do this provide the path to a .txt file which contains file paths you want the mover to ignore. In that .txt put the path to the sabnzbd folder. Full support for this will be in the next update but for now as long as you don't have another folder called sabnzbd1 or similar it will work just fine as expected.

Config>Special>ignore_unrar_dates

With those settings applied to the "media" share, no files in the media share will be moved until the time it was last modified (mtime) exceeds 7 days. If there are other files in the media share you want to move sooner than 7 days they won't move either and there's no way to do this. Those settings will only apply to the "media" share and no other share. Note, if you're using usenet you might need to disabled a setting that preserves the original timestamps of a .rar file. Otherwise this will result in the 7 days being unreliable because. If you store metadata or cover art etc with your media, I'd recommend using the skip file types setting to keep those on the cache for whenever they are loaded, this will stop the disks spinning up when someone is browsing.

What would be helpful is if you do the following: Go to “cd /boot/config” and identify if “share.cfg” file exists. If not follow the steps from my comment above yours and see if it is now working. otherwise: Enable Mover Logging. Set “Move Now Button Follows Plug-In Filters” to yes. Set “Test Mode” to yes. Run mover. Go to “cd /top/Mover” and share the .log file. This should help us identify where the mover is progressing to / stopping.