foamy

Thank you. Logs cleared, will check it in the AM. Much better :) Automover session finished - 2025-11-12 06:00:01 Duration: 0s Usage below threshold — nothing to do cache usage: 1% Threshold:75% Stop Threshold:0% Automover session started - 2025-11-12 06:00:01 ------------------------------------------------

Thx, I think we have a new bug. It seems to be ignoring the Threshold % setting, and just moving everything on every run. I have mine set at 75%, and the most recent run (after today's updated plugin) moved 2 files totaling less than 10GB of my 3TB cache. It no longer emits the percentage comparison into the log, so I think it's skipping the check. I have mine set at 75% and 0%, for the respective settings for threshold and stop threshold. Automover session finished - 2025-11-12 00:02:45 Duration: 2m 44s Completed jdupes step for media No duplicates found. Jdupes processing share media Using existing jdupes database: /mnt/user/appdata/jdupes_hash_database.db Cleanup of empty folders/datasets finished Finished move process Finished qbittorrent resume of torrents Starting qbittorrent resume of torrents Skipped 1 in-use file(s) Finished move of 2 file(s) for share: media Starting move of 2 file(s) for share: media Finished qbittorrent pause of torrents Starting qbittorrent pause of torrents Finished move of 0 file(s) for share: download Starting move of 1 file(s) for share: download Starting move processBTW, if you'd prefer these as GitHub issues, I can do that. One monolithic forum thread isn't a great medium for this type of thing. :)

I'm not sure if this is a bug, or just expected behavior. Reconstruct write should ideally only be enabled if there is content to move. I was scratching my head as to why my drives were spinning up unexpectedly, only to find the correlation in turbo write enabling being tied to the cron schedule of the plugin. I have a 3TB cache, and don't fill it quickly, so the unexpected spin-ups are just wasted electricity for me. Automover session finished - 2025-11-08 08:00:01 Duration: 0s Usage below threshold — nothing to do cache usage: 15% Threshold:50% Stop Threshold:0% Enabled reconstructive write mode (turbo write) Automover session started - 2025-11-08 08:00:01 EDIT: Adding some clarity. My observation is this: The plugin enables turbo write before checking if it's actually going to move anything. This should move to after the check It doesn't revert the turbo write setting back to whatever it previously was. In my case, My array is broken out into 3 user shares across 7 drives. I expect 3 of those 7 to be spun down nearly all the time. 1 of the 7 is specific to time machine backups, so it's spun up when backups are occurring/most of the time, and this is how I spotted that turbo writes were still going even when the automover plugin wasn't doing anything.

Was there a driver behind hardcoding it for the video file extensions? I know it's a common use case, but it does limit it.

Chef's kiss, looking good now. Also, awesome work incorporating jdupes. I haven't tried it yet, but looking forward to replacing the custom Docker container I built just to run that. Mind sharing the arguments you pass for that command?

Vertical is good, but now the first column spills over horizontally. Yeah, I know, CSS sucks. I hate it as much as you do. :)

Another CSS tweak would be making these consistent, since both are logging containers. Right nmow, they use different margins for the text containers I'd even go further to suggest stacking them, with the run history on top and made less tall, to allow for the file migration log/history to be wider. That current layout is hard to use since it wraps so much of the content. I only see like 5-8 file migration log lines due to the current wrapping.

I'm using Waterfox 6.6.4 on macOS Tahoe. I get the same behavior in Safari. Note, I'm not on an enormous screen, if that matters, I'm using a 13" Macbook Air. The browser width is ~1265px. I only know this because it trips a separate bug where there is a horizontal scroll bar due to a bad CSS default for the whole web UI. I'm hoping Unraid 7.2 fixes that. I believe the issue is that the rectangle the content intends to live in is set to a fixed height, so it doesn't flex when child content wants it to be taller. It probably shouldn't be based on viewport height if the intent is to use it as a wrapper for variable height content that can be taller than the viewport. In DevTools, if I disable the height and max-height CSS in the class below, it renders properly both with and without the Qbit checkbox enabled #automover-settings { flex: 1; height: 105vh; /* can probably remove this */ max-width: 450px; /* this may not be a good idea for variable width screens */ max-height: 105vh; /* can probably remove this */ }

7.1.4

The latest version 2025.10.80 has a bit of broken CSS. When the QBit checkbox is enabled, it causes the checkboxes to overlap the bottom of the container.

Yeah, it restored the Unraid stock mover script on reboot. I had to manually clean the automover plugin from USB, then reinstall it. It seems happy now, and I see content being moved to the array. I didn't realize that the whole base linux OS is basically just running in memory, not form the flash itself. Learned a few things, today, so, all's good. Thanks!

The one released on October 6. I'm going to do a reboot of the server, to see if that will restore the base binary.

It is set up that way, and that never changed. Unless the mover binary is supposed to be 0 bytes, that's my issue. Something in this setup/t-shoot 0'd that, otherwise.

This forum won't let me edit my recent post. I'm guessing my issue here is that the mover binary got nuked as part of this plugin install/troubleshooting effort. Both the backup and the in-use one are 0 bytes... root@AERIS:/usr/local/sbin# ls -al *mover* -rwxr-xr-x 1 root root 0 Oct 6 23:33 mover* -rwxr-xr-x 1 root root 0 Oct 6 23:30 mover.automover*