4.2 /info endpoint and save_path inconsistent.

[ShadwDrgn]

qBittorrent version and Operating System

4.2 linux

If on linux, libtorrent-rasterbar and Qt version

irrelevant (as this is a functionality issue and not a crash)

What is the problem

save_path in the /info endpoint returns the download root folder and NOT the torrent's saved files path. If a subdirectory is created (as 4.2 QBT does i'm told), the path becomes wrong because the contents are actually in that subfolder, but save_path isn't updated. That folder's path can't be reliably determined when torrent name has illegal characters in it.

What is the expected behavior

save_path should be the path to the top level of the torrent's contents, and NOT to a root folder where a subfolder has been created.

Steps to reproduce

curl /api/v2/torrents/files?hash=

Extra info(if any)

This causes Radarr/Radarr#5032 in 4.3 because 4.3 no longer seems to save to subfolders AT ALL. Radarr had to workaround the issue by appending torrent.name to the save_path, and this workaround is now broken in QBT 4.3

[bakerboy448]

For posterity, Sonarr as well Sonarr/Sonarr#3968

[ThatNerdyPikachu]

because 4.3 no longer seems to save to subfolders AT ALL.

@FranciscoPombal Do you happen to know if this was an intentional change?

[FranciscoPombal]

@ThatNerdyPikachu IIRC, qBittorrent (> 4.2.5) no longer has the option to create subfolders for single-file torrents. It led to some bigger problems. That said, this API issue needs to be fixed to account for that.

[ThatNerdyPikachu]

no longer has the option to create subfolders for single-file torrents.

@FranciscoPombal I'm honestly not sure if the option ever worked at all - it's the default on 4.2.5 (where create subfolder is enabled by default), and I've never had a subfolder be created for a single file torrent. I've only ever used the WebUI though, maybe that's the issue? /shrug

[FranciscoPombal]

@ThatNerdyPikachu OK, I think I remember the change now: the option was renamed to "Keep top-level folder", because that's what it really did, and it was greyed-out for single-file torrents, since it doesn't make sense for those.

[ThatNerdyPikachu]

@FranciscoPombal in 4.2.5: it's not greyed out for single file torrents in web ui (I can see why, would be a tad annoying to implement) (I assume it doesn't do anything for single file torrents even if it's enabled in 4.2.5?)

So just the name was changed in master, and not the behavior at all? If just the name was changed: why is it affecting the API?

[ShadwDrgn]

@FranciscoPombal QBT 4.3 can't create subfolders for ANY TORRENT of any kind ever. Whether I check the keep-top-level option checked or not no subfolder is EVER created for single file torrents OR multifile torrents. Whether the existing torrent has folders, or doesn't... it NEVER creates a subfolder of any kind.
@ThatNerdyPikachu The behavior changed. QBT 4.2 creates subfolders, and 4.3 does not under any circumstance create a folder.
Note that in 4.3 the save_path IS correct because no subfolder is created but in 4.2 it's wrong because a subfolder is created.

[ThatNerdyPikachu]

@ShadwDrgn As far as I can tell, for single file torrents it is intentional that no subfolder is created. But for multi file torrents... that definitely sounds like a bug.

Open another issue for the latter?

[ShadwDrgn]

@ThatNerdyPikachu it may sound like a bug but nothing in the program in any way indicates a subfolder SHOULD be made. it doesn't seem like a bug at all to me. I have a folder set to put my torrents in and it puts them in that folder. It doesn't put them in some mystical subfolder not indicated by any setting anywhere.

If I'm going to create another issue for that, I'd need some context about what the issue even is, as the current behavior seems intuitive based on the options available.
I assume the only bug is the one in this issue where 4.2 apparently DOES create subfolders but does NOT report them in save_path.

[ThatNerdyPikachu]

@ShadwDrgn For example, in 4.2.5, when I add a multi file torrent (let's call it test), and save it to /torrents, it downloads as so:

/torrents/
    test/
        a
        b
        c

As you're describing it, does 4.3 download as so:

/torrents/
    a
    b
    c

Or am I misunderstanding your explanation?

[ShadwDrgn]

@ThatNerdyPikachu That's correct. You're understanding it. It's worth noting, though, there's no indication anywhere in any options or torrent add dialog that would indicate that a subfolder named "test" should be created. That leads me to believe the behavior is NOT a bug in 4.3 but that the bug is that in 4.2 save_path says "/torrents/" and not "/torrents/test" which is where the files in fact are in 4.2.

[FranciscoPombal]

The behavior described in #13389 (comment) is the correct one. In 4.3.0, the first case is the default. If you uncheck "keep top level folder", you get the second result.

there's no indication anywhere in any options or torrent add dialog that would indicate that a subfolder named "test" should be created.

Yes there is, in 4.3.0 it's the "keep top-level folder" option, and it's ON by default.

That leads me to believe the behavior is NOT a bug in 4.3 but that the bug is that in 4.2 save_path says "/torrents/" and not "/torrents/test" which is where the files in fact are in 4.2.

The save_path should in fact point to /torrents. Imagine you've got 3 multi-file torrents, test1, test2 and test3, and save them all to /torrents. What's the name of the root folder that contains all the torrents? /torrents. Thus, torrents/ is the save path.

[ShadwDrgn]

The behavior described in #13389 (comment) is the correct one. In 4.3.0, the first case is the default. If you uncheck "keep top level folder", you get the second result.

I never get the behvior in the first case. No folder named "test" is ever made unless the contents of the torrent happens to have a folder named "test"

there's no indication anywhere in any options or torrent add dialog that would indicate that a subfolder named "test" should be created.

Yes there is, in 4.3.0 it's the "keep top-level folder" option, and it's ON by default.

It's interesting you say there is because that's NOT what that option does. In fact what the option DOES seem to do is when unchecked it DELETES the folder inside the contents of a torrent if one exists. QBT 4.3 does NOT create a subfolder whether that option is checked or not regardless of single/multi-file torrent.

The save_path should in fact point to /torrents. Imagine you've got 3 multi-file torrents, test1, test2 and test3, and save them all to /torrents. What's the name of the root folder that contains all the torrents? /torrents. Thus, torrents/ is the save path.

Assuming save_path is supposed to point to the contents of the torrent in 4.3 given the current behavior it should work as follows:
unchecked "keep":
save_path=/torrents
checked:
save_path=/torrents

This ^ is in fact the current behavior and i'm fine with it. HOWEVER in 4.2 subfolders are actually CREATED that don't exist in the torrent eg:
torrent contents:
Torrent name: "MY STUFF"
/videos/1.avi
/videos/2.avi

Actual contents of the torrent are in /torrents/MT STUFF/, so the "root" folder for the contents of "MY STUFF" is not /torrents/ it is in fact /torrents/MY STUFF as mentioned. However in 4.2 you get this:
save_path=/torrents
That results in there being no automatic method for finding the specific torrent unless you just guess that there's a subfolder with the torrents name. That's not always reliable/possible because some torrents have illegal chars in the name, but subfolders still get made with some name QBT determines but never reports in the API, and this is what this issue is for.
EDIT: After a slew of 90 edits to make the above make sense i believe it does now. sorry if you all got notified on the billions of edits.

[ThatNerdyPikachu]

I never get the behvior in the first case. No folder named "test" is ever made unless the contents of the torrent happens to have a folder named "test"

So I'm pretty sure that another issue about this behavior specifically should be opened, so it can be fixed, if what you mean is that no matter the value of Keep top level folder (again, that naming is absurd), a subfolder is never created for multi-file torrents, which is what 4.2 does now.

[ShadwDrgn]

@ThatNerdyPikachu I don't think that option is SUPPOSED to create a subfolder whether checked or not. It's meant to delete a subfolder in the contents if one exists when unchecked, which is what it does. I'm not sure though. If it IS supposed to create a subfolder, it should be renamed "Never create subfolder" and when checked a subfolder won't be made for ANY torrent, but when unchecked a subfolder is made for multi-file torrents. ALSO the current behavior the removes the subfolder in the contents of torrents that have a subfolder in them would need to be removed.
EITHER WAY save_path should reflect the path to the contents of the torrent be that a subfolder or not.

[ThatNerdyPikachu]

The behavior described in #13389 (comment) is the correct one. In 4.3.0, the first case is the default. If you uncheck "keep top level folder", you get the second result.

Sorry, I'm confused. So is that (the behavior linked in my linked comment) not what's happening in 4.3? So did they just... remove the option for it? (But apparently Keep top level folder is just a renamed Create subfolder????)

[ShadwDrgn]

Sorry, I'm confused. So is that (the behavior linked in my linked comment) not what's happening in 4.3? So did they just... remove the option for it? (But apparently Keep top level folder is just a renamed Create subfolder????)

In 4.3 subfolders are no longer created. keep top level folder doesn't create subfolders, it does the following:

torrent named "stuff" contents:
/videos/1.avi
/videos/2.avi

If "keep" checked results in:
/torrents/videos/1.avi
/torrents/videos/2.avi

If "keep" unchecked:
/torrents/1.avi
/torrents/2.avi

no folder named "stuff" is made under any circumstance.

[ThatNerdyPikachu]

So then, according to @FranciscoPombal (#13389 (comment)), it should create subfolders, and this is a bug.

[ShadwDrgn]

@ThatNerdyPikachu If it should create a subfolder there is no indication anywhere that it should be doing that and if it should... then there are multiple bugs. One of which is that it's deleting folders and doing what you would expect an option named "keep top level folder" would do. I believe @FranciscoPombal is simply mistaken about what the option's behavior is and there is no bug. I did address that in my reply to him saying that that option does not in fact do that. If you would like to create an issue for that, then feel free. I would suggest you make sure they remove all current functionality of that option when they "fix" it too.

Frankly all I care about is save_path being accurate, which is what THIS issue is for.

[ThatNerdyPikachu]

Ah, got it. Thanks. (Yeah, afaik it (along with every other torrent client) has always made subfolders for multi-file torrents, if it isn't in 4.3, then.... yikes.)

[thalieht]

IIRC, qBittorrent (> 4.2.5) no longer has the option to create subfolders for single-file torrents.

It never did actually.

This option was just renamed to "Keep top-level folder", nothing else, because people kept thinking it creates a subfolder even if there is none (or it should: there are already issues requesting it). So as @ShadwDrgn said:

It's meant to delete a subfolder in the contents if one exists when unchecked, which is what it does.

Having said that, i have no idea if save_path was changed in the API since 4.2.5 but it wasn't from this change.

[ShadwDrgn]

After days of people arguing back and forth about this keep top level folder option, I just want to make sure everyone is clear that save_path has never been pointing to the torrent contents because of subfolders that get automatically created based on the torrent's name. I don't know if QBT was doing this or libtorrent, but it WAS happening which is why sonarr/radarr use save_path + torrent name. In 4.3 this isn't happening anymore and save_path seems inadvertently fixed, which breaks the sonarr/radarr workaround to save_path having been wrong all the time before. so now in 4.3 nothing ever gets imported.

[bakerboy448]

Clarifying point to a comment I saw:
The ARR folks don’t have a client whatsoever. ARRs link to a user’s torrent client.

Dragon it sounds like you hit the nail on the head with that most recent comment.

To quote one of the Sonarr Devs on the sonarr git issue:

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.

[ShadwDrgn]

The problem with considering the torrent name subfolders a part of the "api contract" is that it doesn't work. It's completely arbitrary, and the subfolder created is not always the name of the torrent because sometimes the name of the torrent has illegal characters in it. I'm fine with not changing save_path as long as a NEW key is made available like content_path or something that DOES point to the correct path. Whatever is done, all I care about is that *arr is able to do imports again in 4.3. Right now all automation by *arr software does not work with the latest QBT.

[jobrien2001]

Does anyone know what commit started this? I want to revert back :D

[ShadwDrgn]

I assume if you want to revert you'll have to go back to 4.2.5
I definitely wouldn't hold my breath on a fix either, as there are thousands of open issues and this thread is full of lots of confusion. The sonarr/radarr folks seem to want to call it a qbt bug too so basically your whole media automation stack will not work on qbt 4.3 for the foreseeable future as far as i can tell.

[glassez]

This option was just renamed to "Keep top-level folder", nothing else, because people kept thinking it creates a subfolder even if there is none

Yes.

[Taloth]

@miniliQuid Team Sonarr & Radarr are working to get the new attribute integrated.

[HnyBear]

So is this a fix that needs to be implemented on Qbit or Sonarr/Radarr?

[rrrevin]

Any update on this? There are loads of Sonarr/Radarr installs that no longer function due to this change. It's been almost 2 months.. If this is fixed in 4.3.1, can that build PLEASE be pushed out. Or an interim release 4.3.0.2? Please???

[HnyBear]

Where is that option in Sonarr? I don't see it.

[rrrevin]

Where is that option in Sonarr? I don't see it.

As I understand it, it's not an "option". Sonarr depends on specific Qbit API routes being called and values returned. Qbit changed those values in their API, and now both Sonarr and Radarr break. So either Qbit provides a fixed/interim release, or Sonarr/Radarr change their code to handle the API change done by Qbit, or both??

[glassez]

Sonarr depends on specific Qbit API routes being called and values returned.

Sonarr had a dependency based on a false assumption about the real meaning of a certain field. So I don't think there will be any fix. We just added another field that has the value you expect.

[HnyBear]

And do we need to change a setting or will it be automatic? I am running a program currently that renames folders but would like to uninstall it if it's no longer needed.

[glassez]

After you get a new release, it will be up to Sonarr to make use the new field.

[miniliQuid]

You can simply install Qbit 4.1.9 to make sure sonarr and radarr work correctly. I believe they are already working on implementing this, but till then installing the older Qbit will solve the issue. Specially since Radarr might take a bit with them being busy with 3.0 version of radarr.

[bakerboy448]

QBT of 4.2.5 or lower does not have the issue.

Once the fix is implemented into sonarr (v3 only; v2 will not have the fix backported) it will quickly be pulled downstream (likely expediently) into Radarr (v3 only; v0.2 is effectively EOL), Lidarr, and Readarr

[Taloth]

We've integrated the fix in Sonarr v3.0.4.995, it was tested against various qbit versions including nightly. For older api versions we fetch the filelist to determine the content_path value at the expense of additional api calls, for the upcoming api we use the provided content_path.

Thank you for adding that field, it will improve performance in the future and require less magic on our side.

[Taloth]

I was testing an edgecase and while doing that i noticed that api/v2/torrents/properties doesn't have content_path, only /info does.
Sonarr doesn't need it on properties, but I wanted to mention it in case it was left out unintentionally.

PS: The edgecase I was checking is if the user disabled Keep Top-level folder when adding the torrent then content_path == save_path, something we have to protect against in Sonarr to prevent importing the entire download folder.

[glassez]

PS: The edgecase I was checking is if the user disabled Keep Top-level folder when adding the torrent then content_path == save_path, something we have to protect against in Sonarr to prevent importing the entire download folder.

Didn't the previous approach (save_path+name) require a protection in the same case?

Sonarr doesn't need it on properties, but I wanted to mention it in case it was left out unintentionally.

We only added it where it is really in demand.

[Taloth]

Didn't the previous approach (save_path+name) require a protection in the same case?

No because it would always result in a subdirectory/file, just a non-existing one. Regardless, we added some protection in our code. It's also a rather unlikely edgecase, but low probability + high impact is still a medium risk so I wanted to cover it.

We only added it where it is really in demand.

That makes sense, I wanted to mention it just in case.

Thanks for your reply, it is appreciated.

[FranciscoPombal]

#13856 (comment)