Sonarr: qBittorrent 4.3 won't import finished downloads

[bakerboy448]

Xref from Radarr https://github.com/Radarr/Radarr/issues/5032

Confirmed issue with qBt 4.3 (alpha) torrent sub folder no longer created which breaks importing as ARR expects the subfolder

Sonarr Code ref https://github.com/Sonarr/Sonarr/blob/phantom-develop/src/NzbDrone.Core/Download/Clients/QBittorrent/QBittorrent.cs#L151

[ta264]

Probably need to finish this one up https://github.com/Sonarr/Sonarr/pull/3346

[markus101]

Sounds like QBit being Qbit and breaking things in a minor release, unless it's a bug on their side, but with 2.7k open issues who knows if it'll get seen any time soon.

[ThatNerdyPikachu]

cross-posted from Radarr issue for visibility

qBittorrent 4.3 does not create subfolders with a the name of the downloading torrent

That... does not seem like intended behavior on qBittorrent's side.
What does it do instead?

Also:

Did the default value for Create subfolder in API change?

[ShadwDrgn]

I'm not certain what your screenshot is from but it doesn't appear to be anywhere in 4.3.
in 4.3 there's a "Keep Top level folder" option instead and it does not create folders whether it's checked or unchecked. it only decides whether to delete the top folder in torrents with 1 folder and no other files or something along those lines. I believe they intended this because they have commits and PRs addressing this new "keep top level folder" option all over the place talking about how it was supposedly confusing to people.

What it does instead is just writes the torrents contents to the directory you've got set for "move completed torrents to"
and the save_path API item in the json returned is that folder so all files in the torrent are found in that folder and not a subfolder of the folder like before.

[ThatNerdyPikachu]

You're correct, it's 4.2.whatever the latest minor version is.

That change is.. what... the old option was fine, why did they change it!? (Obviously, I am an example of a user who is confused by it.)

However, the Web API still has create subfolder:
https://github.com/qbittorrent/qBittorrent/blob/master/src/webui/api/torrentscontroller.cpp#L576

Also, I'm a tiny bit confused by your explanation, sorry; do you mind giving an example? Single file torrents have always lived under the save directory you've picked, create subfolder doesn't seem to do anything (no matter if it's enabled or disabled -- default is enabled.) on 4.2 for a single file torrent, or am I just missing the purpose of this (create subfolder) option...?

and the save_path API item in the json returned is that folder so all files in the torrent are found in that folder and not a subfolder of the folder like before.

If it was a single file torrent, wouldn't it be that folder anyways, instead of a subfolder?

I'm probably saying a lot of wrong things, and I apologize.

[ShadwDrgn]

I'm not clear on what you're wanting me to clarify. Here's the issue restated with an example:
torrent named: "test"
Torrent completed save dir set in QBT to "/torrents/"
torrent contents are:
test.txt
/videos/
video1.avi
video2.avi

in QBT 4.2 (apparently) you would get:
/torrents/test/test.txt
/torrents/test/videos/video1.avi
/torrents/test/videos/video2.avi
save_path would be WRONG and say "/torrents/" when in fact the files are in "/torrents/test/"

in QBT 4.3 you get:
/torrents/test.txt
/torrents/videos/video1.avi
/torrents/videos/video2.avi
save_path is CORRECT and says the ttorrents contents are in "/torrents/" which is exactly where they are

[Taloth]

Create subfolder was renamed to Keep top-level folder, no functional difference there but there's also other commits that might be affecting it, specifically https://github.com/qbittorrent/qBittorrent/commit/dc3d23c045ff1a879e0a96fb3c4c9c8d6b64eb95 and https://github.com/qbittorrent/qBittorrent/commit/564d845d8729febb4e12eb35a1e616bd4c1d8ab9 but I haven't studied them in detail.

From what I understand there are two separate issues:

1. In <=4.2, with 'Created subfolder' aka 'Keep top-level folder' enabled, the 'save_path + torrent Name', the resulting path would point either to a file (single file torrent) or a folder (multi file torrent). This is the behavior that Sonarr&Radarr relied upon.
   Now with the new version, regardless of that option, the torrent content is put in save_path without a per-torrent subdirectory. That's based on what people say, I haven't tested it.
2. With 'Created subfolder' aka 'Keep top-level folder' _disabled_, save_path doesn't actually point to the actual storage location if the user manually changed it to a subdirectory, but always points to some root folder. based on the ticket in qbittorrent.

They may have been caused by the same regression, but it sounds like two separate issues to me.
save_path used to point to the category folder, or whatever folder specified while adding the torrent.

Again, I haven't tested or studied it in details because I have enough on my plate to spend time on debugging qbit.

PS: From my perspective there's no _wrong_ or _correct_ behavior, there's simply existing behavior and changed behavior.

[ShadwDrgn]

@Taloth There is a LOT of confusion about some setting in QBT. All I can tell you is that in QBT <= 4.2.5 subfolders were made for multi-file torrents resulting in save_path + torrent name being the contents of a folder. In > 4.2.5 (I'm told) and the entire 4.3 branch (which I'm on and have tested) no subfolder is made and save_path seems to be an accurate representation of wherre the torrent contents are. I believe talk about the "create subfolder" option and "kee top-level folder" option is irrelevant as it was never what created subfolders which is why it got renamed. It actually has nothing to do with this that I can tell

Note when I say wrong or correct, i'm not saying QBT is doing something wrong. I'm saying save_path is not an accurate representation of the path to the torrent contents when i say "WRONG" and when i say "CORRECT" I'm saying save_path IS an accurate representation of the path to the torrent contents.

[Taloth]

There is a LOT of confusion about some setting in QBT. All I can tell you is that in QBT <= 4.2.5 subfolders were made for multi-file torrents resulting in save_path + torrent name being the contents of a folder

That's what I said and the behavior that Sonarr/Radarr has depended upon in the past.

I believe talk about the "create subfolder" option and "keep top-level folder" option is irrelevant as it was never what created subfolders which is why it got renamed.

I'm not so sure about that, because that option is what causes the stripRootFolder function to be called.
Yes, stripRootFolder pertains to folders defined by the torrent file and isn't the same as the automatically generated torrent folder, but how do you think Qbit 4.2 implemented that 'torrent name = root folder' stuff? Via the torrent metadata. To be precise, it's actually libtorrent-rasterbar that implements that functionality by manipulating file paths inside the torrent, not qbit itself.
This is likely also why save_path points to the category folder, rather than the actual torrent sub folder. Because the 'fake' torrent folder is considered part of the torrent.
I don't know if stripRootFolder is called inadvertently, or that a bug in qbit or libtorrent prevents libtorrent from properly adding the torrent name.

With wrong vs correct I wanted to point out that it doesn't matter what we believe is correct/accurate or not. The behavior qbit exhibited in the past is the relevant part and should be considered part of the api contract. Changing something isn't a problem, changing it in a way that breaks backward compatibility is. Care must be taken, regardless of whether it's a bug or simply an improvement.
We can adjust Sonarr to process save_path differently depending on the qbit version, but we should need to. There's also a PR in Sonarr to use the torrent individual files rather than save_path but it does have same caveats as well as some benefits, so it's likely the direction that we'll end up moving in.

To summarize: This smells like a bug in qbit or libtorrent-rasterbar. It's not caused by the Keep Top-Level folder option, but it is quite possibly related to the code involved in that option.

[ta264]

Reporting some investigation over on Radarr discord before I forget.

The issue isn't qbit 4.3, it exists with 4.2.5 also.

1337 has some shitty torrents where the torrent name they report doesn't match the torrent name baked into the .torrent file. 1337 reports the torrent as scene.name and this is the name taken by qbit on add and shown in the qbit GUI. The .torrent has the name attribute crappy name, which matches the parent folder of the torrent contents. Qbit creates the folder crappy name under save_path.

Qbit then reports the torrent name to Radarr as scene.name. Radarr looks for the files in save_path/scene.name but can't find them as they are actually in save_path/crappy name.

Yes 1337 is being dumb, but we should fix it. I think the only real solution is the work in #3346 so we get the actual file location from qbit instead of just guessing. There's no way of locating the files from the endpoint we currently query in this case.

[winklevos]

https://github.com/qbittorrent/qBittorrent/issues/13389#issuecomment-716126144

See detail for content_path being added to torrent/info api

[viggy96]

Nice to see that there's already a fix for this in #4068. Hoping that it gets merged in soon.

[rrrevin]

How long before this makes it into official v2 release? My system has been broken for over a month now :(

[bakerboy448]

@rrrevin based on prior discussions this fix will NOT be backported to v2

[ahmaddxb]

Sonarr v3.0.4.994 is adding the indexer onto the file extension, see below.

/data/qbittorrent/Tv Shows/family.guy.s19e05.1080p.web.h264-cakes[eztv.re].mkv[eztv]

[bakerboy448]

@ahmaddxb that's not at all what's happening or what the issue is.

Don't bother guessing at the problem when several folks, including devs on the softwares involved know exactly What the issue is....simply put it's due to indexers renaming torrents vs what their folder name is combined with a change QBT made

[rrrevin]

@bakerboy448
@rrrevin based on prior discussions this fix will NOT be backported to v2

Will v3 then finally make it into "official stable release" vs beta status? You mentioned here that v2 is considered EOL.. if that is the case, why is it still the official stable release? EOL as Stable does not make sense. This is a big bug that IMHO, should be backported to the Stable branch.

[redfellow]

@bakerboy448
@rrrevin based on prior discussions this fix will NOT be backported to v2

Will v3 then finally make it into "official stable release" vs beta status? You mentioned here that v2 is considered EOL.. if that is the case, why is it still the official stable release? EOL as Stable does not make sense. This is a big bug that IMHO, should be backported to the Stable branch.

It affects one download client from a plethora of clients, so it's far from a big bug. Bug none the less (and you can still click interactive import once a day to chug completed downloads without much of a hassle). That said, this is free software and the maintainers are under no obligation to patch anything, I'm glad the fix is landing in V3 and from quick testing it's in a very usable state, and takes less than five minutes to migrate to. I don't see why they should spend effort on V2 in this case.

[micahmo]

Plus it's very easy to fix the issue by rolling back qBit to 4.2.5.

If you want to be on the bleeding edge of qBit with 4.3, why not be on the bleeding edge of Sonarr v3 to get this fix? :-)

[ShadwDrgn]

@micahmo is there a build available for download with the content_path additions made so that we can be on the bleeding edge easily. I know to be on QBT's 4.3 "bleeding edge" all I ihave to do is click "downloads" and then the download button next to the words "current stable release". Is there a similar process for sonarr/radarr's bleeding edge?

[bakerboy448]

Sonarr/Radarr use v3 for bleeding edge

[splaceway]

Plus it's very easy to fix the issue by rolling back qBit to 4.2.5.

If you want to be on the bleeding edge of qBit with 4.3, why not be on the bleeding edge of Sonarr v3 to get this fix? :-)

I get what you're saying. That is why I rolled QBT back to 4.2.5. But to say QBT 4.3 is "bleeding edge" is not correct. It's the most recent stable build. Sonarr v3 is "bleeding edge" and is not a stable release. It's alpha/beta.

[micahmo]

@micahmo is there a build available for download with the content_path additions made so that we can be on the bleeding edge easily. I know to be on QBT's 4.3 "bleeding edge" all I ihave to do is click "downloads" and then the download button next to the words "current stable release". Is there a similar process for sonarr/radarr's bleeding edge?

Not sure how you're deploying, but I'm using a hotio's Docker container, so I just switch the branch to nightly (hotio/sonarr:nightly) to get the v3 builds. Of course, I don't think the PR with content_path is merged yet.

I get what you're saying. That is why I rolled QBT back to 4.2.5. But to say QBT 4.3 is "bleeding edge" is not correct. It's the most recent stable build. Sonarr v3 is "bleeding edge" and is not a stable release. It's alpha/beta.

Fair enough, but I guess that comes with the territory when there are interdependencies like this. qBit "broke" something in their "stable" release, and now Sonarr will fix it in the only release they're maintaining. Whatcha gonna do with community-maintained free software? :-)

[redfellow]

Sonarr DEVs are patching a bug, that is caused by third party developers making breaking changes in their app, thus breaking integration with Sonarr (and who knows how many other apps).

You can't expect fixes to such issues to be immediately addressed, and usually you'd be installing an alpha/beta anyway to test a fix before it's even considered mature enough to be merged into stable.

Your options, if a new version of a 3rd party app is not compatible, is to roll back the 3rd party app to a version that works, until such time that it's latest version is again compatible. Alternatively install an alpha/beta once the issue is fixed and lands there.

If you didn't want things to break as often, then you should not adopt latest "stable" builds, because stuff can always break despite best intetions.

[rrrevin]

I get where you are coming from, I do. This begs the following: when will v3 become "stable"? It's been "beta" for a long long time now. I get there is always something that would be nice to fix. I'm sure there are bugs and enhancements that would push out the v3 release for the next 2 or 3 years.. but at some point you have to bite the bullet and promote to "stable".

[thomasesr]

I am experiencing issues related to this as well. I thought at first it had something to do with my storage ACLs. I striped all ACLs and reverted back to Unix like permissions for all my dataset trying to resolve this issue. However I now realized that it is a bug in sonnar/qBittorrent where they seem to disagree on folder names.
My Sonarr Log Table:

Import failed, path does not exist or is not accessible by Sonarr: /media/videos/qtorr/The.not.a.pirated.tv.show.S02E03.Chapter.11.The.Heiress.1080p.WEBRip.DDP5.1.Atmos.x264-MZABI[rartv]

from log file:
Import failed, path does not exist or is not accessible by Sonarr: /media/videos/qtorr/The.not.a.pirated.tv.show.S02E03.Chapter.11.The.Heiress.1080p.WEBRip.DDP5.1.Atmos.x264-MZABI[rartv]

The folder created can't contain the character | _(which doesn't show on either github code ``` or the log table view)_ that is on the torrent name so it created a folder named:

/media/videos/qtorr/The.not.a.pirated.tv.show.S02E03.Chapter.11.The.Heiress.1080p.WEBRip.DDP5.1.Atmos.x264-MZAB\[rartv]

qBittorrent replaced the | with an \ on the folder name and Sonarr can't deal with it.

I don't know if it is a standard that is used by qBittorrent on folder name creation that is lacking on Sonarr or something else, but it is anoying. Hope it helps hone in on the issue.

[bakerboy448]

For posterity: this is fixed on v3 and will only be fixed on v3 at this time.