DZMM

I've never used Jellyfin so I'm not sure. line 160 is the line you'd need to update - basically triggering a Jellyfin scan if any files are deleted.

Sorry - it's taken me a while to get nzbget optimised and I'm short of time to try another service. I've had a quick peek at AltMount and it looks like you just need to mount it's webdav via rclone instead of nzbdav's. which bit are you stuck on?

Post your radarr mappings. Post your docker mappings. Make sure the mapping to your mount uses R/W Slave:

I learnt the hard way not to use the orphaned files option as it removes all files not added yet to your library! Broken symlinks are more an issue with Decyoharr. NzbDAV's repair tool will eventually get there, but it could be weeks if your library is big e.g. around 50% of my library is still waiting to be checked

Yes - it's the library ID Yes - it means it found no broken links to delete.

it's considered more efficient as rclone can provide responses to e.g. the arrs

The guide was before NzbDAV included rclone rc support which allows long -dir-cache-time

what version of the script are you using? There was a version where I stupidly was testing --read-only in the mount command to try and fix some 403 errors in rclone which would cause this problem. I also added: --uid 99 --gid 100 --umask 000 \ to more recent versions to ensure rclone mounted the folders with the right permissions.

Try changing your radarr and other mappings pointing to the mount to R/W Slave which works better with mounts. Make sure you also have hardlinks turned on in Radarr

In the last logs it worked! On every run it does checks first to see if the mount is already up: [2026-05-15 23:32:25] CHECKING: NzbDAV Mount integrity... [2026-05-15 23:32:25] [!] NzbDAV process/mount missing. Bypassing patience window... [2026-05-15 23:32:25] [!] Failed: NzbDAV is DOWN. If down it remounts and then checks up to 5 times to see if it worked ok - I've found sometimes it can take a while for the mounts to settile. It checks for up to 30 seconds and moves on as soon as it works. Yours worked on the first attempt: [2026-05-15 23:32:25] REBUILD: Initiating In-Place Rclone recovery... [2026-05-15 23:32:27] Launching Rclone Mount... [2026-05-15 23:32:27] WAITING: Mount stabilizing (Attempt 1/5)... [2026-05-15 23:32:33] SUCCESS: Mount stabilized.

Great news. What did you do differently in your array start script as I use this one to do everyting - I just set it on a 3 min cron? How are you finding playback? With the settings I put as defaults I'm getting launches typically under 2-3 seconds, for non-4K content mostly before I can count to "one"!

yes you need to have the rclone plugin installed and to have used rclone config to create a WebDAV remote nzb-dav:

@impostrrlobstrr can you try the latest version I just uploaded as I realised myself when I had to temporarily disable Decypharr that the script failed. The new version is a lot simplier overall https://github.com/BinsonBuzz/unRAID-rclone-mounting-scripts-for-NzbDAV/blob/main/Scripts/Mount%20Script

3rd script added to the collection that scans for broken NzbDAV or Decypharr symlinks, deletes them, and tells the arrs to replace https://github.com/BinsonBuzz/unRAID-rclone-mounting-scripts-for-NzbDAV/blob/main/README.md

New version posted - with some helpful new features https://github.com/BinsonBuzz/unRAID-rclone-mounting-scripts-for-NzbDAV/tree/main ## Changelog: v1.5.2 → v1.5.11 Focused on making the script smarter and more resilient so it spends less time fixing things and more time staying out of the way. --- ### Key Improvements & Fixes * Smarter Recovery: The script now checks for specific subfolders to verify a mount is actually working, rather than just checking if the folder exists * Decypharr Stability: Added a "wait and retry" loop for Decypharr mounts. If it isn't ready immediately, the script will give it 10 chances to wake up before giving up * Safety First: Added a "Port Cleaner" that automatically clears blocked connections before attempting a remount, preventing "address already in use" errors * Notification Support: You will now get Unraid system notifications if a mount goes down or if a recovery is successful * Database Awareness: Full support for Postgres-based apps (like the *arrs) ensuring they are stopped and started in the correct order during a reset * Performance Monitoring: The summary report now tracks how many days of data your cache is holding and shows exactly how much of your cache drive is full * Better Resource Handling: Improved how the script handles high server loads to prevent it from accidentally making a slow system even slower --- ### What’s New in the Summary? The bottom of the log now gives a one-line "health check" showing: * Mount Age: How long your mounts have been stable * Cache Health: Total files primed, cache disk usage %, and data retention days * System Vital Signs: Current server load and available RAM