Terebi

you don't need to use the age or size threshholds in mover tuner anymore unless you want them for reasons outside my script. If you run mover every day, it will run my script, and as long as you are below the script threshhold, nothing will be moved. If you are above the threshhold, oldest files will be moved off to get you under the threshhold.

.sh not .sv you don't need to create moverignore.txt, it will be created by the script. you only need to change target dir if your media share/directory name is different.

If you are talking about a plex/emby/kodi library, the general recommendation is that it should be on the appdata share, and most people keep appdata as cache only (and exclusive) for performance reasons. If that data is part of the appdata share, just set the mover to move from array to cache, then run the mover. After everything is moved, disable secondary storage and make sure the appdata share is set to exclusive. To get a subset of files back to cache you could also set the mover from array->cache, and then manually run the mover on a given subdirectory by using the following command find /mnt/user/DirectoryNameGoesHere* -type f | /usr/local/sbin/move& ^^^^^^^^^^^^^^^^^^^^^^^^

Mover tuning. The only thing my script does is tell mover to ignore up to X newest bytes of content in a particular directory. Its to keep my media share full of newer content to keep drives spun down. Other shares, or other settings from mover or mover tuning are not affected.

During bulk transfers where you don't want to use the cache, either disable the cache temporarily, or copy into the disk shares directly to skip past the cache. Mover tuner cannot control what happens with the cache at any time OTHER than moving. So all of your bulk imports or whatever, mover tuning is completely irrelevant. It has no interaction whatsoever with file creation/copies etc going on. Currently there is no "read cache" to move some files off of the array onto the cache, while simultaneously moving other files from the cache to the array (for the same share)

I honestly think my script will do what you want with only variable tweaks. Set my script to your media dir. Run mover hourly. disable all other tuning settings (age/size) Every hour, everything NOT on the media dir will move to the array. Every hour the media share will get moved to the array, BUT skip the newest files up to the threshhold. each time a new file is downloaded, the next hour, an equal amount of the oldest data should move.

#3 can be dealt with using either mover tuning settings, or by adding in this script

The array is (or should be) protected by parity against disk failure. But if you have a single cache drive, then the files there are not protected. For users not using mover shenanigans like this script, thats probably ok, because things will get moved to the array every morning. But using this script, things may stay on cache for weeks/months, so if you don't have mirrored cache setup, there is increased risk of data loss if the cache drive fails. If you do have mirrored cache, then the risk is pretty minimal.

Yes, you can remove the tuner threshhold which will let my script incrementally move things off each day

Some interesting changes. If I ever need to make big updates to the script I may port some of these back into the main line.

You can stick it there, just without a schedule yeah. As long as the mover plugin has read access to that folder (and it runs as root I think, so it should?) It doesn't really matter where it is, you just want it someplace that it can be run without spinning up drives. You will def want tuner to call it tho, because then its up to date as of the moment mover is about to run. Otherwise data could change between the time the script was run and mover was run.

Several of us were using those tricks to get fan control before, but since pwm polarity is reversed in that setup, none of the other plugins that control fans work. With these drivers, polarity is correct, and so you can use other fan plugins. There may be other additioal reasons to use the driver, but since it was just added to unraid we are all still figuring out what we can do.

Although you can use the other mover tuning settings like age and threshold the script works fine by moving every day so that everything not listed keeps moving off cache (files of different extensions) and the script sort of self manages keeping cache full

Kind of the other way. Each night when mover runs it will run the script and list files up to 750gb from newest to oldest. The mover will then ignore those. So on day 1 there will only be a small handful of files listed (whatever you downloaded that day). And that list will keep growing each day until you get to 750gb. At that point the oldest files will not be added into the list and will get moved.

Moz it's the amount of space to use for files to stay on cache. So if you have a 1tb drive you would like to leave 25% free, set it to 750gb in bytes.. this does not account for files in appdaya etc that may also be taking up spacz so adjust accordingly.

This plugin is just drivers, by default it will probably not alter default behavior. There is an existing LED plugin in the appstore that may work now, once these drivers are installed, but I'm not sure. The only thing I have used them so far is fan to enable fan control.

Nothing I've read indicates that won't work anymore. lic is still bound to the key, and you can attach whatever configs you want to it.

Thats the wrong math. Even if upgrade costs are higher, you still get the lifetime lockin now. So its $60 for something you may never use. And if you do use it, in the worst case scenario the price to upgrade to takes your total price to the new lifetime price(unless someone is really dumb/malicious). I did an xtra basic license buy. and honestly im not likely to use more than 6 devices on a second box, so thats probably my total investment. But even if I did need to go big, I doubt its worse off, and high likelyhood its better off.

It was vague communications/default messaging, with a somewhat buried workaround posted week+ later that I hadn't seen. I'm upgraded, so I can't see it anymore, but I swear the CA app itself gave a message saying 12 was required, and it did not mention old versions remaining available.

I completely understand the need for more revenue, as a "buy once" model indeed does not allow for the actual cost of maintenance. This doesn't personally affect me, as I have 2 lifetime licenses and am very unlikely to need more than that, but just thinking about the bigger problem space : * As others have mentioned, security patches * CA won't even launch anymore on < 6.12. Assuming that pattern holds in the future, you could have a fully working system with apps, that you would never be able to install any new apps on, never upgrade any apps, and if you ever needed to reinstall an app or rebuild your server from scratch, you may not be able to get back to status quo. ed : per responses, this is incorrect I like the idea of feature locking instead of version locking that others suggested, as it removes the need to backport fixes into old versions, but still encourages upgrades for the new features. But if the intent is that "security/bug fixes" and "CA compatibility" requires the subscription fee, it would really depend on what the annual cost is, and being very up front that that is the model.

If this is still on offer, Asustor Lockerstor 4 Gen2 AS6704T https://m.media-amazon.com/images/W/MEDIAX_849526-T3/images/I/71GIE-onlSL._AC_SX679_.jpg

@Scheev @flyize @Mamaun @dopeytree @Swarles @mrpops2ko @ItsRaining

@bukunraid @alturismo @akimboflix @HDT @Andiroo2 @NGHTCRWLR @CS01-HS

The default fan speed seems to be 850 for me, and I keep it at like 1200 even when things are cool, in my script since thats below where I can hear it most of the time. I think the trick with drive temps will be checking the temp without spinning them up. (or rather not checking the temp of a spun down drive). But I guess if you list only the NVMEs it won't matter.