• Content Count

  • Joined

  • Last visited

Community Reputation

7 Neutral

About TDD

  • Rank


  • Gender
  • Personal Text
    Keeping the hard drive manufacturers in business.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well - tested it myself by initiating a manual backup. It does not purge old backups until the running one is complete - as expected and safe. Is it a big ask to have an option where the backups are purged according to the plan prior to the backup? TY. Kev.
  2. Wonderful plugin. TY! Question - with any backup about to proceed, are any out of date .tar backups deleted prior to the commencement of the new backup? I ask as my (small!) 1TB drive that holds the current .tar would not hold another in progress and would of course run out of disk space and error out. TY! Kev.
  3. Hi All. I also upgraded without incident. Looks superb...thank you to all the team! I do want to pass along a GUI issue. I don't obviously see now what dockers are due for an update in the dashboard? I seem to recall they had an indicator stating as much. A right click on one due for an update does show the option, so this is just a cosmetic fix. TY. Kev.
  4. Backups are another story - let's say in this instance that I will be revisiting my backup strategy once I have everything back together and at least disk protected via parity. I've never tried bringing an outside disk, let's say an XFS one, into the array and not zeroing it. Is that possible even to make the system accept it as-is? As long as you rebuilt parity later, what would it really matter what was/is on the disk? Kev.
  5. HI all. For a myriad of reasons, I needed to do some file recovery. As I am moving recovered files off a drive which has been removed from the array (hence UR is down) and to secondary storage, am I ok to then move those files back onto the same array drive? I don't believe there is anything special about the XFS that UR uses. I know this invalidates parity but I will worry about regenerating that later. I could network copy but that will be slower. I could also attach the drive and copy via unassigned devices but then it will be a bit slower as the p
  6. This makes sense. I have just mapped my two folders into docker and have re-pointed all my tv libraries to the mountpoints inside the root of Sonarr. I think now that this was some kind of limitation from way back when I first started Sonarr and I never bothered to change it or even think of this. This should fix it nicely...TY for making me see the obvious! Fingers crossed it will work now! Kev.
  7. I am. Here are my specific docker maps: All my internal Sonarr TV paths are then accessed via /mnt/user/TV, /mnt/user TV (Kids), etc. which are the unRaid shares across my array. Perhaps I am not getting why the rules of fill and disk choice would not be followed in this case? All other accesses to the same follow the rules. Copying anything (like with MC) into /mnt/user/TV is following the rules...?! Kev.
  8. I am at a loss to fix this. I have now modified my system so that my main array (disks 1-8) are exclusively for data. They all are set to allow any share included and excluded none. My Docker and various appdata now resides on a cache disk. The cache shares are explicitly set to ONLY use the cache disk. The array shares are explicitly set to NOT use the cache disk. Somehow when Sonarr imports a file, it transfers it out to the TV share in my array (paths are set as /mnt/user/TV) but it ends up on the cache disk despite the rules with the same folder structure.
  9. An FYI that this bug is still in play. Somehow my Sonarr still gets past the include/exclude and it drops into my disk explicitly set as exclude but preferred overall?? because of the high-water setting. Kev.
  10. Well, no combination of include/exclude makes it work. This is a bug and unique somehow to the situation. Even shelling into the server and copying via MC respects the rules. This is a Sonarr thing as mentioned above. My share setup, attached, is for review. Seems sane to me! Kev.
  11. Yes - I have tried explicitly setting exclude disk 1 and and setting include (all others) to really force the issue. I have moved the disk to another slot too to ensure it isn't a slot issue (ie: disk 1 vs 8 or something). From my understanding, it is not necessary to explicitly complete both the includes and excludes for the same share. I will still fuss with this but it mysterious. All other copies look to respect things just fine. Kev.
  12. Well, this certainly seems to defeat the point of the include/exclude parameters? This still doesn't explain why an internal move/copy ends up inside an excluded disk via Sonarr, when an external move/copy works fine. I can take the files that should NOT be on disk 1, place them into a different directory on the same disc, shell in and move them with MC back to the /user/TV share and they respect the exclude and end up anywhere but disk 1. Is this a unique Sonarr thing that is bypassing the rules? Kev.
  13. I am at a loss other than to believe it a bug somehow. I tried a new config and moved the disk 1 to disk 9, changing my shares accordingly so the TV share excluded disk 9 - just to remove the chance that that this was tied to disk 1. Same thing arose - files somehow dropped on disk 9 in a TV folder. I am manually moving the files being dropped on disk 1 to another disk then copying back to the user share to workaround this issue. I am hopeful that somehow it gets "fixed" with 6.4 coming up.
  14. Hi all. This one I cannot figure out. With 10 disks, I have a "TV" library set to span all the disks *except* disk 1...hence 2 -> is open game. The share in question is appropriately set to exclude 1, and include the rest. My understanding is that this alone should force any copies to the share to of course exclude 1. This *does* work when I copy files to the share myself. Where it fails is when Sonarr picks up a show and drops it into the TV library. Said show suddenly appears on disk 1. For note, the work flow is that NZBGet fetches a show, drops it i
  15. Hi all...again. When setting up a share and the included disk option, is there any way (perhaps in the future) that share would "follow" the disk in the system (let's say one reorders the drives and starts a new config) rather than just be tied to the physical disk in that slot? I imagine for safety reasons it at least ensures some kind of share would appear but moving disks around forces me to go through all the shares and vet them again. Kev.