"You should not download to a root folder."?

Help & Support
#21

from the support side…

when you have say

F:\Some.Downloaded.TvShowName\ (downloaded release) and F:\TvShowName (show folder in sonarr) wires get crossed; glitches happen; and bonus points for users break things and it’s quite frankly not very smart to mix you’re organized files with your messy downloads.

You’re free to use or not use Sonarr…but your unproductive complaining about a new check designed to prevent support issues because you don’t care and you have no issues…well I wasn’t aware you, 1 user, represent tens of thousands of users.

#22

The new check design complains, so I complain about the new check design.

Others may choose not to complain since their folder setup structure has been working for them without any issues regardless that this “new check design” complains about something that is not causing those other users any problems.

Sooner or later that “new check design” will escalate to several other annoying errors and warnings like: Your current version of .net is no longer supported, you must upgrade, or your current version of download client is too old and is no longer supported, you must upgrade…etc, etc.
At least provide us with the option to turn it off/on either globally or individually.
Same for the constant hourly update checks, either provide us with a simple on/off option or at least a “check interval” like once daily, or once-weekly, once every so many hours, without users having to create and configure their own scripts and schedules for sonarr.

#23

why? because at some point your download client may try to clean up from a corrupted/badly formatted job and deletes everything underneath - meaning it could wipe out all your media.

the primary reason you use different download and media paths is security. so that you can deny your download clients any access to the media path, only sonarr has access to both the download and media paths.

that way there is no possibility of your download client ever accidentally cleaning up your media data.

i can make my password “password” and state that ive never been hacked so its a perfectly good password - are you going to use it on your account after someone points out that its just a matter of time?

1 Like
#24

I reported this same issue a few weeks back on GitHub and got the same BS, insulting, and arrogant “users are stupid” answer. It’s my personal belief that the Sonarr devs have approached detecting this configuration issue poorly.

What this warning has revealed is that Sonarr has, in the past, had undocumented or poorly documented processes that causes some imports to change the root folder configuration without the users awareness and some don’t. Not surprising with an app that changes internally so frequently.

The most likely scenario for download client folders being added as Sonarr library root folders is that at some point in the past, unbeknownst to users, Sonarr itself added the folder as a root media folder, not the user. The explanation of this warning is terrible and unclear which is why users end up on the forum or reporting a bug.

Fine, the download folder shouldn’t be a root folder, so Sonarr shouldn’t ever add it as a root folder itself and should warn users if they’re trying to manually do it. The explanation of the warning should be more clear that the folder in question is configured both in the download client AND in Sonarr and a root MEDIA folder. Simply put, the warning’s explanation is clear as mud.

#25

But there’s not a single line of code in sonarr that does what you say, so… no?

Again, sonarr doesn’t add root folders itself, see above.
Consider that once upon a time you configured sonarr by adding a root folder. Then you add indexers, download clients, all other settings.
Then your download client starts reporting the first completed download, and gives sonarr the same path as your sorted media library to pick up and move the download.
So how should sonarr have known this upfront and tell you not to do it?

I do agree that the message / wiki explanation could have been clearer.

General remarks:

If software and devs were infallible, Marcus and colleagues would have knocked out Sonarr v1 in a couple of afternoons years ago, and we’d still be using that because all software is perfect from its conception.

By the way, y’all are beating a dead horse in a topic of a user who reported this and after getting a explanation reacted basically with “oh ok, now I understand” and considers it resolved.

The angsty, ridiculous responses to what’s basically the devs putting up a warning to help you avoid potential issues in the best way they can because it can’t be coded makes me pray you never ever switch to the dev branch where things can actually break all the time (in theory). It’s the branch for the grown-ups who accept this fact and want to help out by basically letting the devs use their system as a test bed.

1 Like
#26

Any suggestions for editing the wiki on it? (Or feel free to contribute (the new wiki at wikijs.servarr.com) PRs or direct wiki contributions w/ GH auth welcome)

As far as clarifying in app / edit the message the best way IMO would be to rename everything in code from root folder to media folder or something along those lines…but I don’t see that happening anytime soon.

And otherwise you hit the nail on the head as usual Thirrian. Perhaps some people who don’t like things should fork it and create their own app & infrastructure if they hate the developers so much. Not to mention not only is no one forcing anyone to use any of the *arr apps… users made the conscious choice to use said apps and they paid absolutely nothing at all. Having/getting a Free open source app with all volunteer support and all volunteer development and expecting premium (paid) development and that as a “customer” one is owed something absolutely do not jive.

#27

On GitHub I was told by someone I believed to be a dev that certain kinds of Sonarr imports either currently or at some point in the past did exactly that. My point is, there has been code in Sonarr at some point that did that. My installation is years old, and I can tell you with 100% certainty that I’ve never added anything but my actual library paths to Sonarr as root folders. Adding the download clients folder as a root folder to Sonarr is an obvious bad idea and I’ve never done it. Yet it ended up there.

I am salty over this because of how the devs reacted to me on GitHub. When this health check was added, the error made no sense because the wording is poor and on my many year old Sonarr install, I had never done what the devs insisted I had. It very much smells like a bug, or a botched configuration created by a previous bug. When I subsequently checked my Sonarr root folder config and found about a dozen different temp paths I’d used for imports in the past and the download clients download folder had been added by Sonarr (again, I never added them) and it all needed to be cleaned out of the config. Clear evidence to me, that Sonarr has behaved in undocumented or at least unexpected/unintuitive/unnecessary ways adding paths used in other functions (like imports) as root folders.

I really don’t care what the devs say about the code as it is today. Fantastic if it doesn’t do it now but at some point in the past, Sonarr code added all those paths, not me. Had the wording of the error been clearer, this threads OP nor myself would’ve needed to come waste anyone’s time.

#28

Sounds to me like you had done previous imports using the library import method. As the only way a root folder is EVER added to sonarr is by the user or vis the API.

Literally if their are root folders in sonarr than the user added them as a root folder there has never been any code I’m aware of for that to happen automagically

So yes the devs were correct in saying what you did.

What you should be using is manual import not library import (formally just called import)

The error is clear…mostly it primarily stems from users not understanding what a root folder is in the context of sonarr when that nomcleture is found all over the UI.

Maybe instead of complaining, either provide suggwstions (or make a PR or edit directly) for the healthcheck section wording in the wiki…or make a PR for sonarr to fix up the error wording.

If all anyone here wants to do is complain and provide nothing constructive, well maybe some sand should be pounded and rocks kicked.

#29

Here are two suggestions.

1.) A recent update has implemented a new nagging messaging system for long existing setups; fine and noted… now provide your end-users with a simple option to turn it “off/on” or an extended delay reminder notification schedule.

2.) As I have already mentioned in a previous post, provide end-users with the option to simply turn “off/on” auto-updates or to only check at scheduled intervals.

Other categories and sections of sonarr already provide users with options, so why not do the same for “messaging notifications” and “auto-updates”.

1 Like
#30

1.) A recent update has implemented a new nagging messaging system for long existing setups; fine and noted… now provide your end-users with a simple option to turn it “off/on” or an extended delay reminder notification schedule.

For dismissible healthchecks: https://github.com/Sonarr/Sonarr/issues/481

As far as turning it (healthchecks) on/off - unlikely

2.) As I have already mentioned in a previous post, provide end-users with the option to simply turn “off/on” auto-updates or to only check at scheduled intervals.

Well everything you’ve said about updates hourly and related complaints A) you’re lying or B) you have literally no clue what you’re talking about.

  • an update check occurs every 6 hours; no plans to allow customization of the task interval
  • main has received only two updates in the last 3 months; I have no idea where you get the idea that sonarr is updating multiple times a day. That simply is not true.
  • develop which you absolutely should not be…may from time to time receive multiple updates in a single day; however, even this hasn’t occurred recently
  • on every OS, except windows, you can disable automatic updates
  • WE LITERALLY CHECK AT SCHEDULED INTERVALS OF 6 HOURS; any statements to the contrary are either lies or a complete and utter failure to understand basic English I guess…literally cannot grok how one can get the idea that sonarr is updating multiple times an hour or every few hours that simply is factually incorrect.
#31

Thanks for confirming my point.

#32

As far as turning it on/off - unlikely

Then why do you even mention that we should make suggestions if you are going to dismiss them with that type of attitude, no wonder some users don’t bother making suggestions or complaining since this is the attitude that they will receive.

WE LITERALLY CHECK AT SCHEDULED INTERVALS OF 6 HOURS

No, no, and no: Regardless whether it is “actually” updating once a day, once a week or once a month; checking every 6 hours without providing us with the option to change it or to turn it off is ridiculous and overkill. You want all the control and not allow us to make the choice by taking away the option to change either of these two categories.

an update check occurs every 6 hours; no plans to allow customization of the task interval

Again, with an attitude like that, what is the point of making suggestions as you previously mentioned.

I have no idea where you get the idea that sonarr is updating multiple times a day. That simply is not true.

I didn’t say it was “actually” updating multiple times a day, you said it, I din’t, go back and read one of my previous replies to you where I clearly mentioned checking and not actually updating, you are the one making assumptions, jumping to conclusions, and misunderstanding everything, go back and read where I clearly mentioned the following:

Same for the constant hourly update checks

may from time to time receive multiple updates in a single day; however, even this hasn’t occurred recently

Perhaps not recently, however, it has occurred in the past as you just admitted it.

1 Like
#33

I’m done here. Clearly you can only argue in bad faith and cherry pick statements to suit your narrative of Sonarr sucks, the devs suck, and you are always right, so you Sonarr should do exactly what you want.

You’re literally cherry picking sentences and phrases to attempt to change the facts to suit your narrative.

Oh and to quote you

Same for the constant hourly update checks

Update checks do not occur hourly. More evidence of your bad faith arguing.

And to reiterate my statement of your cherry picking and again arguing in bad faith

What I said:

  • develop which you absolutely should not be…may from time to time receive multiple updates in a single day; however, even this hasn’t occurred recently

what you twisted this to mean:

may from time to time receive multiple updates in a single day; however, even this hasn’t occurred recently

Perhaps no recently, however, it has occurred in the past as you just admitted it.

What you’re also missing the point of DEVELOP:

  • develop - Current Develop/Nightly - (Alpha/Unstable) : This is the bleeding edge. It is released as soon as code is committed and passes all automated tests. This build may have not been used by us or other users yet. There is no guarantee that it will even run in some cases. This branch is only recommended for advanced users. Issues and self investigation are expected in this branch.

And again multiple updates in a day… NOT updates hourly

#34

So who is cherry picking between hourly and every six hours? and to quote you:

an update check occurs every 6 hours; no plans to allow customization of the task interval

The point is not whether it is checking every hour, every two hours, or every six hours, the point is that checking “every few hours” is overkill and we should have the choice to change it or to turn it off.

My argument has nothing to do with the development of alpha/unstable.

You are completely missing the entire point and are getting caught up in the “hourly” vs 6 hours vs multiple times in a day.

The point is about providing the users with the option to change the rate check interval (schedule) and/or to turn it off completely as well as the nagging messages.

1 Like
#35

And then they’ll come here with a version from the stone ages to complain that something isn’t working which was fixed long ago. Examples available to anyone who wishes to search these forums or github.

Speaking for myself here, I’ve had to handle users for years, and taking control away from them in areas they have no expertise in is a Good Thing :tm:
As is trying to warn them when they make mistakes that can potentially bite them in the ass later. Which is the entire summary of this topic.

I’d say provide some information on your setup and why you feel the warning is in error, maybe something was overlooked and that can be coded in, but I have no high hopes of that actually happening.

1 Like
#36

taking control away from them in areas they have no expertise in is a Good Thing

New users of sonarr have no expertise “anywhere” within the application, should options be removed in all other areas as well?
The update option is a simple off/on option, no expertise is required for that, we should have that choice.

Not all users should be treated the same, if you are in the IT field in an IT management position for a large corporation, your non-technical upper management will tell you that. I understand and I can relate from a technical perspective that this would be a good thing and the best method for everyone for a number or reasons, however, in the actual world, this is unacceptable to upper management.

The developers can also make mistakes and cause an update to break things like they did with raddar a while back, and yes, I give them credit for fixing it right away, but the point is that experts can also make mistakes.

1 Like
#37

This literally exists for all OSes, except windows.

The developers can also make mistakes and cause an update to break things like they did with raddar a while back, and yes, I give them credit for fixing it right away, but the point is that experts can also make mistakes.

I don’t believe radarr has ever shipped any broken master releases?
If it’s nightly that breaks, well that is completely warned about as being a possibility ahead of time…which is why things stew and are tested before being pushed out to master/main.

We see a lot of “developers”,“system administrators”, and other individuals who claim years of various experience… yet they always tend to 1) think they are right and did nothing wrong 2) the software is always wrong and 3) fight with the staff when they’re trying to get support. The resolution typically ends up being what something someone who is allegedly knowledgeable should know about.

But I digress.

Why do you continue to make a disingenuous comparison of free, volunteer, open source apps to corporate paid apps? They are not at all the same. Upper Management has no relevance at all nor due any customers…as there are no customers.

You know I think you’d have a better time switching from Sonarr since it clearly will never meet your expectations of paid corporate perfection.

None of the issues you think are issues are actual issues. The general goal is to prevent user stupidity and reduce support issues. It seems you believe you’re a perfect user who can never do anything wrong ever…well maybe you should go find a perfect application to match…good luck.

Frankly it sounds like you just can’t accept being wrong or doing things in a potential-issue-causing way as it’s worked perfectly fine for years. By your logic, there’s nothing wrong with a broken clock at all because it is correct 2x a day.

#38

This literally exists for all OSes, except windows.

Yes, but some use windows, so what is your point?

Why do you continue to make a disingenuous comparison of free, volunteer, open source apps to corporate paid apps? They are not at all the same. Upper Management has no relevance at all nor due any customers…as there are no customers.

There you go again, making assumptions, jumping to conclusions, and misunderstanding everything.
I’m not comparing this software to any paid ones; In my reply to Thirrian, I was referring to end-users in a corporation whether they are employees, upper management, clients, customers, etc. Weather it is paid or non-payed software has nothing to do with it and I never mentioned any other ones or compared it to any; once again, you are getting off on a deviated tangent like you have done in some of your other replies.

A full nonsensical rant completely out of context and off the subject matter.
So basically, you inform users that if they don’t like or disagree about something in the software than they should find another one,…what a great attitude you have there!, very professional. Try that in a business environment and see how fast you will be rectified by upper management.

It’s clearly obvious that you have never worked for a business or corporation and never learned how to relate to customers or treat them in a professional manner, therefore, just because this is a free software, you can say and treat the end-users with the contemptible attitude that you know everything, you are always right and everyone else is always wrong regardless of their experience, knowledge, skills, profession, or with things that have worked for them for years;…once again, great professional attitude you have there!.
That’s right, I read some of your other responses to other users on this board where you condescend, insult, talk-down, and backhand them with your contempt responses.

This is about providing a simple “choice” for the end-users. You want to be the one who is always right and everyone else is wrong because you know something others do not,…NO, it just makes you a fan who has spent “more time” with the application and it’s technical aspects than most others. As a fan you will never see it any other way. You should try working for an actual corporation so that you learn how to professionally and courteously treat customers or in this case “end-users”.

As I mentioned to Thirrian; not everyone should be treated the same as not everyone has the exact same setup and configurations, not everyone requires or needs all the same features and functions of a software, and some prefer the option to change updates and messaging notifications which is something that you clearly cannot understand.

You mentioned earlier that instead of complaining that we should make suggestions…well, I made two, and your only capable response was an argumentative, defensive, and offensive one; so then what is the point of making any suggestions?. It is obvious as to why some users do not want to make complaints even if/when they are of a positive criticism or suggestions that you immediately shut down without even considering that it may be looked into.
With a contemptible attitude like that it is no surprise that some respond to you in the same manner.

2 Likes
#39

well thats shit logic because his clock actually continues to show the correct time up until it breaks. it will be his fault it broke because he ignored the warning but thats on him.

he does have a good point though - and it is a suggestion, so please calm the hell down with the completely off tangent crap and stick to the suggestion instead. why exactly is it bad idea?

think of it this way - its a warning, not an error, so it cant be that bad. if it was a really bad thing then sonarr would not import from a root path in the first place would it.

(and yes i fully understand the shitstorm it can create if it screws up, i pointed it out. im not an idiot so dont even think about it)

is it any wonder that people want to adjust when the checks get run if all they do is spit out pointless (to them) warnings that are meaningless.

the devs could compromise and have it configurable from 6 hours (default) up to seven days. the warning nags are still there, the user knows and understands the risks of only having health checks run once a week (because they changed the slider value) so if anything goers wrong its on them.

plus, its always on them anyway. its not like they can blame sonarr is it.

i personally would love the ability to adjust the series refresh/scan task out to 24 or more hours, but thats been denied, its locked to 12 hours - even though i, and i would presume anyone who changes its value, fully comprehend the issues i may have (which wouldnt be issues for me)

if even the clever people get it wrong, then why dumb/lock everything down to cater for the stupid?

#40

That is certainly something we weighed, but decided to let people see the warning and then they can fix it, as-is it’s less aggressive and doesn’t break existing setups. People would be more upset if Sonarr stopped doing what it used to do as opposed to telling them to fix it.

That’d only matter for some things, a lot of health checks are reactionary to a setting being changed. In the case of this particular check it executes when a download clients, root folder or remote path mapping is added, updated or removed.

They can and do, for all sorts of ridiculous reasons. The bigger problem is if someone configures Sonarr in a sub-optimal way that we either assume would never happen or a bug causes an issue things get moved to the wrong series and worse files get deleted, which has happened in edge cases related to people downloading into the root folder.

So they too don’t get it wrong, but in the end there is no reliable way to limit some people and not others. We’ve previously erred on the side that people wouldn’t set up their config in a way that could cause issues, but we know that eventually some people do, it causes issues, in this case in the form of “Sonarr isn’t renaming files, it’s leaving them as the download name and not putting them in a series folder” (or something to that affect).

TLDR, it’s a warning not an error to encourage people to fix their setups to avoid a potential issue and not break things outright and just because it has been working for weeks/months/years doesn’t mean something couldn’t go sideways in the future.

1 Like