TDD Posted September 28, 2017 Share Posted September 28, 2017 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 into a folder on disk 1. Sonarr sees this and should pick it up and drop it into TV which would bypass disk 1, but it doesn't. The TV share is set to high-water and split of the first two directories. FYI, my shows are contained within sub-folders of TV (ie: TV/Family Guy/SXX...). There are no explicit references to any "/mnt/disk1" or anything like that. Everything is via the "/mnt/user/TV" path. Is this a bug with somehow it being greater than one directory level? Kev. Quote Link to comment
Lev Posted October 15, 2017 Share Posted October 15, 2017 I think I hit this condition repetitively over the last few weeks. Finally narrowing it down to what conditions it's triggered under and I don't think you're alone in what you're experiencing. Quote Link to comment
TDD Posted October 16, 2017 Author Share Posted October 16, 2017 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. Quote Link to comment
itimpi Posted October 16, 2017 Share Posted October 16, 2017 It is a quirk of the way move is handled at the Linux Level. If it appears the source and target may be on the same mount point then a rename is tried and only if that fails does a copy/delete take place. Quote Link to comment
TDD Posted October 18, 2017 Author Share Posted October 18, 2017 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. Quote Link to comment
DZMM Posted October 18, 2017 Share Posted October 18, 2017 have you tried include rather than exclude? I have all my sonarr activity on disk 3 and completed downloads obey my include rules and aren't written to disk 3 Quote Link to comment
clowrym Posted October 18, 2017 Share Posted October 18, 2017 I have noticed Sonarr & Radarr don't seem follow the free space rules either. Quote Link to comment
trurl Posted October 18, 2017 Share Posted October 18, 2017 13 minutes ago, clowrym said: I have noticed Sonarr & Radarr don't seem follow the free space rules either. The only free space rule is "don't begin writing a file to a disk that has less than the minimum free setting". There is nothing to prevent writing a file that is too large for the available free space. Minimum free must be set to be larger than the largest file you will ever write. That is the way it has always worked. Don't know if that explains what you are talking about or not. Quote Link to comment
TDD Posted October 18, 2017 Author Share Posted October 18, 2017 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. Quote Link to comment
DZMM Posted October 18, 2017 Share Posted October 18, 2017 3 minutes ago, TDD said: 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. I'm fairly certain you only have to exclude or include, not both. It works fine for me just using includes. Quote Link to comment
trurl Posted October 19, 2017 Share Posted October 19, 2017 Exclude means "use all except the listed drives". Include means "use only the listed drives". There is never any reason to specify both, and it is not recommended. Quote Link to comment
TDD Posted October 20, 2017 Author Share Posted October 20, 2017 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. Quote Link to comment
DZMM Posted October 23, 2017 Share Posted October 23, 2017 I'm not sure if this is exactly the same bug, but I spotted one over the weekend that the LT team said will be fixed in the next release. I'm not sure if this is 6.4RCx Quote Thank you for the report. This is a known issue and fixed in next release. Cheers, Tom From: LimeTech [mailto:[email protected]] Sent: Saturday, October 21, 2017 1:16 AM To: [email protected] Subject: unRAID User Bug Report (ID #1343) Bug Report Bug Description: moving files between directories in mc doesn't respect disk include/exclude options How to reproduce: I have two shares /movies_adults (disks 5,6 only) and /movies_kids (disks 3.4 only). I moved movie1 from mnt/user/movie_adults/movie1 to mnt/user/movie_kids/movie1 Expected results: movie1 shoud have been moved to mnt/disk3/movie_kids/movie1 or mnt/disk4/movie_kids/movie1 Actual results: mnt/disk6/movie_kids/movie1 i.e. not disk 3 or 4 Quote Link to comment
TDD Posted January 23, 2018 Author Share Posted January 23, 2018 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. Quote Link to comment
TDD Posted February 11, 2018 Author Share Posted February 11, 2018 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. This is the only docker/app that seems to do this. It seems to ignore the cache directives and just follow the share rule for high-water hence it ends up on my most free disk? Any insight here? Kev. Quote Link to comment
Squid Posted February 11, 2018 Share Posted February 11, 2018 If you're mapping /mnt to /mnt or /mnt/user to /mnt/user and referencing all the paths in sonaar from a single path mapping then what you're seeing is correct and expected Quote Link to comment
TDD Posted February 12, 2018 Author Share Posted February 12, 2018 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. Quote Link to comment
Squid Posted February 12, 2018 Share Posted February 12, 2018 It's because of mount points. Any OS when moving a file will look to see if the source and destination are on the same mount point (in your case /mnt) since that's what you mapped to the container. If they are then it'll just renames the file to the new location instead of a copy and delete operation. Net result is that your file winds up on the cache drive in violation of the rules. Solution is to map another path of /tv mapped to /mnt/user/tv and have sonarr move the files to /tv instead Quote Link to comment
TDD Posted February 12, 2018 Author Share Posted February 12, 2018 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.