Radarr: System Alert for uTorrent Paths with Spaces in Them?

[MikeFalcor]

Describe the bug
For Radarr, I have utorrent using a path with a space in it to place completed downloads. Radarr has been freaking out about this since the bump in version number, but Sonarr DOES NOT. So now, my status page lists "Remote download client uTorrent places downloads in C:\Users\uTorrent\Downloads- Radarr but this directory does not appear to exist. Likely missing or incorrect remote path mapping." as an issue when the real issue is probably that this folder check on the backend is not surrounded by quotes.

To Reproduce
I am fairly certain that if you have uTorent move completed downloads to a folder path with a space in it, you will get this system alert. I am not going to change ANYTHING on my computer to figure out if this is the case as everything is completely automated for me.

Expected behavior
It is OBVIOUSLY a good path else my completed downloads would break. Also, why is this even a thing?! Why is RADARR checking my uTorrent paths in the first place when uTorrent is responsible for the damn path it places completed downloads in?

Screenshots
N/A

Platform Information (please complete the following information):

• OS: Windows
• Mono Version: N/A
• Browser and Version: FF 81.0.1
• Radarr Version: 3.0.0.3898

Debug Logs
Attached, but I highly doubt that this is something that would be logged...
radarr.debug.txt

[ta264]

Sonarr DOES NOT "freak out" because it doesn't have the check.

It's a new warning that helps people discover incorrect settings. There may be false positives, if you want to help us diagnose a potential false positive then please join the discord server and we can work it through (though hopefully with less attitude).

I suspect that if it's a remote client like it says and the output directory is in C:\Users then it is indeed not accessible by Radarr - it's trying to help you out!

I think it's very unlikely to be an issue with the space, that's all handled automatically.

[austinwbest]

but Sonarr DOES NOT.

Well this is Radarr not Sonarr :)

as an issue when the real issue is probably that this folder check on the backend is not surrounded by quotes.

I wouldn't ASSUME that because a UI formatted message doesn't contain quotes that the backend doesn't :)

I am fairly certain that if you have uTorent move completed downloads to a folder path with a space in it, you will get this system alert.

Well that can be tested to see using your exact path

I am not going to change ANYTHING on my computer to figure out if this is the case as everything is completely automated for me.

Is there a note somewhere that says it is REQUIRED to change how your system is setup without even looking at the issue? Please link it so we can address that, as it surely isn't the intent.

It is OBVIOUSLY a good path else my completed downloads would break.

There is OBVIOUSLY that possibility that the programs are running by different users with different permissions, or a number of other things...

Also, why is this even a thing?! Why is RADARR checking my uTorrent paths in the first place when uTorrent is responsible for the damn path it places completed downloads in?

It is a thing because the amount of path/permissions issues support has to deal with is by far the most so things like this to try and help find possible issues is there. It is only INFORMATION and not breaking anything.

[MikeFalcor]

A few possible, giant assumptions are made in this error check:

1. That uTorrent is installed on the same machine as Radarr,

2. That Radarr even needs access to that folder,

3. That, given 1 is false and 2 is true, the same user/password is used on the remote machine.

There are more, but I think I would be wasting time enumerating them.

Radarr does not need access to the folder uTorrent uses unless completed download handling is enabled. What's more, Radarr WOULDN'T have access to that remote folder unless more advanced configuration was done in the first place (i.e. same user account on both computers, same password for that user, or advanced permissions set allowing different users access to the user folder, among other things). Given that Radarr specifically asks for Host and Port information when configuring a download client, why would you assume Radarr would ever have direct access to ANY folder without completed download handling enabled? Why would you have it verify the configuration of ANY other piece of software you access via API or WebUI?

And the really funny thing is that the account running Radarr on machine 1 has access to the folder in question on machine 2. The real problem is that, when accessing folders on remote Windows computers, you don't get to folder structure of another computer by using its local path. You use the UNC path to the folder - so now your error check on a piece of software you shouldn't be checking is completely invalidated.

I get that ta264 saw my frustration and took it as hostility, but I simply wanted to point out that this is a very dumb error to have or even consider just adding on a whim. I write code for my clients and myself just about every day. Part of coding includes the need for error-handling. But this? This is not error-handling. This is looking for a solution where there isn't even a problem. Not even...it's looking for a problem where you have no business looking.

[MikeFalcor]

uTorrent is available for Windows, Mac, Linux, and Android.
Radarr is available for Windows, Mac, and Linux.

The ONLY time the path configured in uTorrent would allow access to Radarr is if it were local and running as the same user. So why implement this error check?

And I get that it is not breaking anything to have the error check there, but WHY?! And why RED?!?!

[austinwbest]

So it seems this entire thing could have been as simple as...

Can we remove the download folder location check if "Completed Download Handling" is disabled? Reason being is that it throws a warning when it doesn't need to.

That would have been a valid request, simply stated & eliminated all the hostility :)

Whatcha think bud?

[MikeFalcor]

Oh no no no. I wasn't being hostile in any way. Sarcastic, yes. As I said, I code myself. A LOT. Across multiple platforms and languages. This is a huge learning opportunity and with it comes a bit of a slap. You need to learn when it is OK to make an assumption and when it is not OK. I have done this to myself plenty of times and had others do it to me.

So, with this, assuming a contributor reads it, they won't make the same mistake in the future. No more "Maybe it would be a good idea to throw an error-handle in there." without consideration for multiple scenarios (actually, more failing scenarios than successful outcomes) where the error-handling would absolutely fail.

Since we are leaning in on hypotheticals: Say it WAS coded in such a manner that it would prevent the download client from being used. The assumption made would therefore break a completely functional task all because a dev didn't think outside the box before implementation. Or at the very least did not consider even one scenario where that particular line of code would cause an issue instead of help resolve one.

Could I have been less sarcastic? Yes. But...c'mon! They used RED for an inane alert. Red should only ever be used for a hard failure of some sort... And yet, yellow for when an indexer is down or unavailable. Sheesh...

[austinwbest]

FFS guy.. I know for sure none of us are going to catch everything, we are not on your level i guess of perfection. So here is the solution...

At the top click Fork, download that to your local, set it up & apply that perfection wizardry you speak of and start knocking out some of the issues and helping.

As that is very unlikely to happen because it is so much easier to sit there and be a keyboard warrior about how everyone should be, you can keep being sarcastic and talking retarded to the people who would be the ones to fix it.

Way wrong approach to this entire chain of events & it doesn't seem to have an end. Good luck with it and i hope to learn from your PR's myself.

[bakerboy448]

You do realize you're effectively being hostile and attacking two of the devs on the project...

I am aware it may not be your intent, but that is how the tone and wording of your messages come across...

[MikeFalcor]

K. Fine. I will stop applying logic to my post. Actually...fuck it - Since I am 'talking retarded' when applying logic to a completely dumb scenario in which a line of code would only be accurate 16.667% of the time (please, allow me to explain that math to you), I will go ahead and ignore an alert generated from an error-handler that should never have been added in the first place.

I'm the asshole here. Issue CLOSED.

[bakerboy448]

You're the one aggressively pointing out and having an attitude man.

It's a beta ffs, things happen, bugs exist.

Either be a good user and help figure out where the problem lies or be a good dev and make the PR yourself.

There's no need to be an asshole about it man, things break. Either fix it or help fix it.