Andiroo2

This is so great. Thank you!!

Is there a way to reduce the time scale for each disk that is listed in the plugin? When I go to the disk listing to see what's causing a disk to spin up, i have to scroll through disk activity from up to 24h ago. I only want to see activity in the last hour or so. Can I specify this? Thanks!

Fascinating...I wonder where these values came from. I had several shares with huge values for the minimum free space (400-700GB). It actually caused overflow from the cache to the array for several shares and answers some other questions I had. Thanks for the fast turnaround!

Diagnostics attached. Min free space on cache is set to 0, with warning and critical thresholds set to 95% and 98%, respectively. tower-diagnostics-20231103-0949.zip

Seeing a ton of these messages in the logs: Nov 3 04:14:17 Tower shfs: share cache full Nov 3 04:14:17 Tower shfs: share cache full Nov 3 04:14:20 Tower shfs: share cache full Nov 3 04:14:20 Tower shfs: share cache full Nov 3 04:14:21 Tower shfs: share cache full Nov 3 04:14:21 Tower shfs: share cache full Nov 3 04:14:21 Tower shfs: share cache full Nov 3 04:14:22 Tower shfs: share cache full Nov 3 04:14:22 Tower shfs: share cache full Nov 3 04:14:33 Tower shfs: share cache full Cache is ZFS, sitting around 95% full with > 400GB free. Curious to know what process thinks the cache pool is full. Mover is set to run at 95% usage via Mover Tuning, so I expect it will run soon, but would like to know if something is failing and throwing these messages.

Aha, I run mover on this share a couple times per week. Would this "destroy" the dataset once it empties it out?

I have some interesting lines in my log every day at noon: Sep 28 12:00:01 Tower shfs: /usr/sbin/zfs unmount 'cache/CommunityApplicationsAppdataBackup' Sep 28 12:00:01 Tower shfs: /usr/sbin/zfs destroy 'cache/CommunityApplicationsAppdataBackup' Sep 28 12:00:01 Tower root: cannot destroy 'cache/CommunityApplicationsAppdataBackup': dataset is busy Sep 28 12:00:01 Tower shfs: retval: 1 attempting 'destroy' Sep 28 12:00:01 Tower shfs: /usr/sbin/zfs mount 'cache/CommunityApplicationsAppdataBackup' This folder is the first dataset/folder alphabetically in my cache pool, which is a RaidZ1 setup. This dataset is not part of an auto-snapshot or auto-backup (I recently set up automated snapshots for my appdata and domains datasets via the SpaceinvaderOne tutorial). Here's the view from ZFS Master: The destroy is failing (thankfully?) but I'd like to know what's trying to kill it.

Just installed the latest version of the plugin. Thank you thank you thank you!

I will kiss you if this makes the list! Purely consensual, of course...

This post should be stickied.

No errors that I can see in the backup log (regular and debug). I created a debug log to share with you, ID 8eed7224-7ebd-4120-872c-6e3afb6c0459 in case you can see something I cannot.

Forgot to add, I had to change the VERSION tag as well, otherwise the docker container will update to the latest version available when it runs: I am back to proper 4K hardware transcoding with tone mapping on Quick Sync.

Where are the logs for each backup stored?

Not by Unraid. I have achieved something similar a couple of different ways: I use the Plexcache python script to move all On Deck media to the cache for my Plex users. This is really handy. I have a huge cache (8TB NVMe) and I set mover tuning to keep it full (95%) before running Mover, and then only move files that are 3 months old.

I rolled back to a stable version and it works again…see attached.

Trying to restore for the first time today and I'm having issues. When I try to select the backup to restore, I get an empty dropdown. What am I missing here? I have plenty of backups to choose from. Thanks!

Plex docker is no longer hardware transcoding on Intel Quick Sync as of v1.32.6.7468. No changes otherwise...docker updated after backing up last night and now I see crazy CPU usage due to 4K transcodes using CPU instead of GPU.

Docker failed to start when I tried this, so I rebooted the server. When it came back up, I was able to delete the container and re-install from the “Previous Apps” section of Comunity Applications. Everything is working now.

AI wrote this, right?

Same thing happening to me. I had an orphaned image and I deleted it, but still can’t start or delete the main Docker container for the same app.

I recently changed my cache from BTRFS to XFS, and now I can't seem to scan the root of /mnt/cache in this app any longer. I get a greyed out list of folders, perhaps a permissions issue? I can scan them individually, but not at the root level of the cache drive(s):

Failed for me now too on 6.12.1. I feel like it started failing before the upgrade to 6.12 though...

Feature request (is this the right place to ask?): A option to invoke the mover once I hit a certain threshold (95% in my case) and move the OLDEST files from the cache to the array until I hit a free space threshold on the cache (say 80% free) and then stop moving. I like to keep as many files on my cache as possible for fast access and to keep my array spun down whenever I can. I do this today with the mover tuning plugin by only running the mover once I hit 95% cache utilization and only moving flies over a certain age, but with the above feature I would be able to keep the cache exactly where I want it at all times.

Not urgent. I will watch for this next time and if it's a recurring problem then I'll reach out. Thanks for the offer.