Radarr: Categories not working with qBittorrent

Created on 18 Oct 2017  路  21Comments  路  Source: Radarr/Radarr

Hello,

I have a strange behavior, when Radarr find a torrent, this one is correctly sent to qBittorrent, but not in the correct category (the torrent is actually uncategorized when he is added).

Thx !

OS Version: Ubuntu LTS 16.04
Radarr Version: 0.2.0.870
Mono Version: 5.4.0.201
qBittorrent Version: 3.3.16

Logs:
radarr.txt

bug sonarr upstream

All 21 comments

https://github.com/Radarr/Radarr/issues/1937

Seems to be the same problem, except that the problem occurs every time for me.

Edit:
My bad, it's exactly the same problem, sometimes it's working, sometimes not.

Probably going to need debug logs to understand what's happening when a movie release is added to qBittorrent. It would be likely that a failure of some description is happening (at least what Radarr thinks is a failure), causing the movie category of "radarr" or whatever is set in the download client settings to not be added.

Sorry I've only those I provided (can't see any others). How should get them ?

The log level provided is INFO level. Debug/trace logs would be useful to understand what's going on with Radarr and qBittorrent when a movie release is added.

You can adjust this by going to Settings on the General tab, then set the log level accordingly.

Then repeat grabbing a release and note when the category is not added and capture that log info if possible.

radarr.debug.txt

Should be this one, made with the movie "Minority Report"

Thanks. So it looks like this part of the log is of interest here:

17-10-19 16:42:29.1|Debug|Api|[GET] /api/release?movieId=36&sort_by=releaseWeight&order=asc: 200.OK (14912 ms)
17-10-19 16:42:38.8|Debug|ReleaseModule|Couldn't find requested release in cache, cache timeout probably expired.
17-10-19 16:42:38.8|Debug|X509CertificateValidationPolicy|Certificate validation for https://localhost:8082/command/download failed. RemoteCertificateChainErrors
17-10-19 16:42:39.0|Debug|X509CertificateValidationPolicy|Certificate validation for https://localhost:8082/command/setCategory failed. RemoteCertificateChainErrors
17-10-19 16:42:39.0|Info|DownloadService|Report sent to qBittorrent. Minority.Report.2002.1080p.BluRay.x264-MELiTE
17-10-19 16:42:39.3|Debug|Api|[POST] /api/release: 200.OK (482 ms)
17-10-19 16:42:45.2|Debug|Api|[GET] /api/history?page=1&pageSize=15&sortKey=date&sortDir=desc&movieId=36: 200.OK (7 ms)
17-10-19 16:42:57.0|Debug|X509CertificateValidationPolicy|Certificate validation for https://localhost:8081/jsonrpc failed. RemoteCertificateChainErrors
17-10-19 16:42:57.0|Debug|X509CertificateValidationPolicy|Certificate validation for https://localhost:8081/jsonrpc failed. RemoteCertificateChainErrors
17-10-19 16:42:57.0|Debug|X509CertificateValidationPolicy|Certificate validation for https://localhost:8081/jsonrpc failed. RemoteCertificateChainErrors
17-10-19 16:42:57.0|Debug|X509CertificateValidationPolicy|Certificate validation for https://localhost:8082/query/preferences failed. RemoteCertificateChainErrors
17-10-19 16:42:57.0|Debug|X509CertificateValidationPolicy|Certificate validation for https://localhost:8082/query/torrents?label=Movies Radarr&category=Movies Radarr failed. RemoteCertificateChainErrors

Can you confirm that Minority.Report.2002.1080p.BluRay.x264-MELiTE was the selected release passed to qBittorrent and didn't have a category?

One thing I would try as a test, looks like you've got qBittorrent configured to use SSL on localhost? That's not really needed, given traffic on localhost isn't going outside the machine Radarr is running on, also the SSL is throwing certificate errors. Have you tried disabling SSL and connecting over plain text. As it looks like Radarr and qBittorrent are running on the same machine, this shouldn't be an problem/a security issue in this case.

Also (and this just a stab in the dark). Looks like your movies category has a space in it. Out of interest have you tried using a label without a space as a test? Perhaps test with "radarr" which is the default.

Yes this was the correct release. Yes I know that SSL in localhost is not really needed, but qbittorrent allow only one type of http connection (http or https), and I use the secured one because I access it throw internet sometimes.

Anyway I tested without SLL, and the category seems to be correctly set everytime, BUT sometimes Radarr doesn't see it (I don't have any notice in the "Activity" tab).

Here the new logs (with the right category but not displayed in Radarr):
radarr.debug.txt

This time the release is "Minority.Report.2002.1080p.BluRay.H264.AAC-RARBG"

Thx for your support

edit: ops sorry I didn't read your last sentence, I will test it !
edit 2: No I've changed the category name and sometimes it's working, sometimes not

@Mzartek Hi. Sorry for the delay. So when it selected the release I didn't see any error, so difficult to understand why the download wasn't listed in Radarr's activity tab.

So, based on testing, disabling SSL makes the category assignment consistently work? Interesting. Is there any specific usage case that can consistently cause the set category to not work. Its just difficult to try and reproduce.

I personally don't use the SSL option in qBittorrent, instead I connect via HTTP on localhost, but use a reverse proxy for accessing the qBittorrent Web UI and category assignment has been stable on my production setup, since the upstream changes to the API for qBittorrent were merged.

No worries take your time. Good idea the reverse proxy, It's what I've done after your answer. And after that categories are correctly set most of the time. Yes most of the time because even after that sometimes categories are not set correctly, but now this case is rarer than before (it's happening for like 1/20).

Sorry can't help you more on this because when I had this case, it was on sonarr with mulltiple automated downloads and I couldn't reproduce it by launching the downloads manually on Sonarr or Radarr.

The only thing I could say is that the symptoms are the same than this issue on Sonarr:
https://github.com/Sonarr/Sonarr/issues/2155

If it's start to be annoying I could simply switch of torrent's client

Thanks for the update. Yeah, I noticed that same issue on Sonarr, but sadly no further information/logs was provided by OP. Based on what you describe then, it sounds like having SSL enabled makes category assignment less stable, but it can still work. At this point my only explanation for that is having invalid SSL, your logs were showing certificate errors, likely due to using a self signed certificate in use and maybe that might not be helping.

Reverse proxy is the better way to go for SSL anyway, exposing qBittorrent directly to internet is a bad idea, better to have something like Apache or Nginx between the two, which has a much better SSL/TLS implementation.

We'll leave this open for now for more investigation, but if you have an updates, do let us know!

I'm coming back because I have some new stuff.

The problem happened again, but this time without the SLL activated, and in the log nothing seems to be an error:

radarr.debug.txt

The bug appears with the release "ParaNorman 2012 REMUX 1080p Bluray DTS-HD AVC MA 5.1-LEGi0N"

It's really weird, I'm starting to think that the problem come from qBittorrent himself

And an other one, with the same problem:

radarr.debug.txt

Release name: "The Pirates! Band of Misfits 2012 1080p BluRay DTS x264-HDMaNiAcS"

Edit: It seems to happened everytime, on Sonarr too, don't know what is happening

@Mzartek Can confirm, it is happening on Sonarr too, a release for a TV Show ended up with no category.

Maybe an upstream issue or the way both Sonarr and Radarr are interacting with qBittorrent API. As far as I know, we are both in sync currently with the qBittorrent download client code. See what qBittorrent devs say.

Fixed on the latest release.

can you point to the commit that fixed this @galli-leo ? looking through recent commits for the past couple days I can't seem to find anything to indicate this being fixed..

Yeah this was fixed a longer time ago, 2 months or something?

@galli-leo supposedly this isn't fixed actually..as I've seen reports of it still not adding categories in the latest release..

There's a discussion on the Sonarr forums which notes that the problem seems to only occur when torrents are added via magnet links. Although the exact cause of the problem isn't identified, one of the suggestions to fix this is to set the category when the torrent is added rather than as a separate action after the add request is made.

A recent update to Sonarr from about a month ago appears to do this. Perhaps this was the update that you had in mind, @galli-leo?

I haven't done any development in C# before but the change was to only one file so I've forked, made the change and committed it back. I don't have the development dependencies set up on my machine so I wonder if someone else could confirm whether this works or not. I can make the PR now if that would help.

I can tell you now @themagicbullet that the change the sonarr devs had done doesn't fully work either as things still tend to get added without a label/category. So there still is no fix at the current time for this issue on either sonarr nor radarr.

@themagicbullet A PR sounds good, the build system should verify that it's building correctly. (Though not much has changed)

@JourneyOver If this change really does not fix the issue, it seems like an issue with QBittorrent itself. Since there isn't much more we can do.

@galli-leo I mean the fix the sonarr devs done does seem to be a bit better on adding the label/category, so I'd still suggest getting it added either way but it's not anywhere near a full on fix for the whole label/category problem between sonarr/radarr and qbittorrent just yet as it'll still miss setting the label/category here and there.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

scope999 picture scope999  路  3Comments

davidbonnici1984 picture davidbonnici1984  路  4Comments

jurpeedurp picture jurpeedurp  路  3Comments

danielb2 picture danielb2  路  3Comments

alpinewinter picture alpinewinter  路  3Comments