UNchecked folders at the 'Add-new-torrent' window STILL download (so does SOME of their content) #2433

Closed
opened 2026-02-21 16:13:05 -05:00 by deekerman · 11 comments
Owner

Originally created by @soewhaty on GitHub (May 9, 2015).

This post is coming after in this thread https://github.com/qbittorrent/qBittorrent/issues/2907 I was advised to download the latest v3.2.0beta. All good with the beta. Issues described in the above-mentioned thread were somehow gone, but new ones seem to emerge. That's why it's called a Beta, I guess.

Here it is. I open a torrent file and at the Loading Dialogue AKA 'Add new torrent' window I see that the torrent's content is organised into 3 folders, which in turn contain lots of other folders. Of those 3 folders I unchecked 2 and left only 1 checked with the hope that only the checked folder will be downloaded. However, when the torrent was downloaded I saw that all the 3 folders were downloaded, but luckily were empty. Only the folder I had initially checked was populated with content. The other 2 folders and the folders they contained were all downloaded but just empty! That is kinda annoying. Hope it will be fixed and that is why I'm giving you this feedback.

Unfortunately, I tested again with similar torrents containing multiple folders and that time not only did all folders and subfolders download (although I had intentionally UNchecked them at the 'Add new torrent' window) but also some of their content was downloaded as well. When I say 'some' I mean that those folders contained something like 10-15 mp3 files and occasionally 1 or 2 mp3 files would be downloaded in those folders, which (as I said) I had purposefully UNchecked so as not to download. It is annoying enough that those folders even get downloaded empty, let alone to have some of their content download as well.

Love you app! Don't do what uTorrent did. Best of luck and hope you guys can resolve this one for the stable release. I am on Windows 7 x64 Pro SP1 with updates on everything, basically.

PS
The issue described in this post happened when I was downloading the above-mentioned torrent types (i.e. torrents with multiple folders) to my internal HDD, if that is of any importance to the whole context.

Originally created by @soewhaty on GitHub (May 9, 2015). This post is coming after in this thread https://github.com/qbittorrent/qBittorrent/issues/2907 I was advised to download the latest v3.2.0beta. All good with the beta. Issues described in the above-mentioned thread were somehow gone, but new ones seem to emerge. That's why it's called a Beta, I guess. Here it is. I open a torrent file and at the Loading Dialogue [AKA 'Add new torrent' window](LOL!) I see that the torrent's content is organised into 3 folders, which in turn contain lots of other folders. Of those 3 folders I unchecked 2 and left only 1 checked with the hope that only the checked folder will be downloaded. However, when the torrent was downloaded I saw that all the 3 folders were downloaded, but luckily were empty. Only the folder I had initially checked was populated with content. The other 2 folders and the folders they contained were all downloaded but just empty! That is kinda annoying. Hope it will be fixed and that is why I'm giving you this feedback. Unfortunately, I tested again with similar torrents containing multiple folders and that time not only did all folders and subfolders download (although I had intentionally UNchecked them at the 'Add new torrent' window) but also some of their content was downloaded as well. When I say 'some' I mean that those folders contained something like 10-15 mp3 files and occasionally 1 or 2 mp3 files would be downloaded in those folders, which (as I said) I had purposefully UNchecked so as not to download. It is annoying enough that those folders even get downloaded empty, let alone to have some of their content download as well. Love you app! Don't do what uTorrent did. Best of luck and hope you guys can resolve this one for the stable release. I am on Windows 7 x64 Pro SP1 with updates on everything, basically. PS The issue described in this post happened when I was downloading the above-mentioned torrent types (i.e. torrents with multiple folders) to my internal HDD, if that is of any importance to the whole context.
Author
Owner

@sledgehammer999 commented on GitHub (May 9, 2015):

The first part of creating unwanted folders will be solved hopefully after #2892 is merged. Or when the hidden ".unwanted" folder functionality is removed.
The second part is explained here: https://github.com/qbittorrent/qBittorrent/wiki/Frequently-Asked-Questions#I_configured_qBittorrent_to_not_download_some_files_in_a_torrent_but_they_still_appear_on_my_hard_disk_why_is_that

@sledgehammer999 commented on GitHub (May 9, 2015): The first part of creating unwanted folders will be solved hopefully after #2892 is merged. Or when the hidden ".unwanted" folder functionality is removed. The second part is explained here: https://github.com/qbittorrent/qBittorrent/wiki/Frequently-Asked-Questions#I_configured_qBittorrent_to_not_download_some_files_in_a_torrent_but_they_still_appear_on_my_hard_disk_why_is_that
Author
Owner

@soewhaty commented on GitHub (May 9, 2015):

Well ... I would not say that the second part is ... EXPLAINED at all there. If I were you I'd fix it, instead of explaining it. Because it clearly needs to be fixed as it is clearly not a good solution so far.

@soewhaty commented on GitHub (May 9, 2015): Well ... I would not say that the second part is ... EXPLAINED at all there. If I were you I'd fix it, instead of explaining it. Because it clearly needs to be fixed as it is clearly not a good solution so far.
Author
Owner

@sledgehammer999 commented on GitHub (May 9, 2015):

Read the explanation and you'll understand why it can't be fixed.

@sledgehammer999 commented on GitHub (May 9, 2015): Read the explanation and you'll understand why it can't be fixed.
Author
Owner

@soewhaty commented on GitHub (May 9, 2015):

I DID read the explanation and it does not look to be good enough ... other bittorrent clients I've used were not limited to pieces but rather to files ... 'operates at piece level' ... well, can't it be made to operate at file level? You see that a lot of frustration on your users' part will come from that, dont you? Can't it be built to operate on file level?

Why don't you guys grab the opportunity that uTorrent is clearly dying now and build the top bittorrent client out there? To do so you'll clearly have to address the 'operates at piece level' issue. Your app is great with some small tweaks here and there. I've been kind enough so far to point them out.

@soewhaty commented on GitHub (May 9, 2015): I DID read the explanation and it does not look to be good enough ... other bittorrent clients I've used were not limited to pieces but rather to files ... 'operates at piece level' ... well, can't it be made to operate at file level? You see that a lot of frustration on your users' part will come from that, dont you? Can't it be built to operate on file level? Why don't you guys grab the opportunity that uTorrent is clearly dying now and build the top bittorrent client out there? To do so you'll clearly have to address the 'operates at piece level' issue. Your app is great with some small tweaks here and there. I've been kind enough so far to point them out.
Author
Owner

@chrishirst commented on GitHub (May 10, 2015):

it does not look to be good enough

Well, that's a bit of hard you are having there then, because it IS definite and proven fact, and as such HAS to be good enough, so it would behove you to spend some considerable time reading the BitTorrent Protocol Specification, as that defines precisely what can and what cannot be done regardless of your opinion of the matter.

All bittorrent clients HAVE to use 'pieces' as it IS THE central and fundamental concept that the BitTorrent Protocol hinges on. The ONE and ONLY difference between clients and protocol engines such as libtorrent, is in the method that they handle unwanted pieces, some clients, uTorrent and BitTorrent in particular use a closed source protocol (uTorrent v3+) that uses a single file to put the unwanted pieces called uTorrent_random-chars.dat, this is a monolithic hidden 'file' that contains all the unwanted pieces in [hopefully] contiguous disc sectors.

Now 'unhooking' and testing the .unwanted operation from libtorrent by qBitTorrent IS going to take some considerable time, so if you would kindly refrain taking up @sledgehammer999**'s ** limited time in dealing with your teenage petulant outbursts of "But I don't like it that way", it may move along a little quicker.

Thank You.

@chrishirst commented on GitHub (May 10, 2015): > it does not look to be good enough Well, that's a bit of hard you are having there then, because it IS definite and proven fact, and as such HAS to be good enough, so it would behove you to spend some considerable time reading the [BitTorrent Protocol Specification](https://wiki.theory.org/BitTorrentSpecification), as that defines **precisely** what can and what cannot be done **regardless** of your opinion of the matter. All bittorrent clients HAVE to use 'pieces' as it IS THE central and **fundamental** concept that the BitTorrent Protocol hinges on. The **ONE** and **ONLY** difference between clients and protocol engines such as libtorrent, is in the method that they handle **unwanted** pieces, some clients, uTorrent and BitTorrent in particular use a closed source protocol (uTorrent v3+) that uses a single file to put the unwanted pieces called uTorrent_random-chars.dat, this is a monolithic hidden 'file' that contains all the unwanted pieces in [hopefully] contiguous disc sectors. Now 'unhooking' and testing the .unwanted operation from libtorrent by qBitTorrent **IS** going to take some considerable time, so if you would kindly refrain taking up @sledgehammer999**'s *\* limited time in dealing with your teenage petulant outbursts of "But **I** don't like it that way", it may move along a little quicker. Thank You.
Author
Owner

@soewhaty commented on GitHub (May 10, 2015):

Very well said, of you! :) All of it. Totally agree! Especially the teenage part! :) Couldn't have put it better myself and I am not being ironic! :) I managed to get you guys annoyed enough so as to hopefully fix the issue. By saying 'can't it be made to work on a file level' I clearly meant finding out a way to delete or not download unchecked files, even though torrent clients work on piece level. Doing it in the way uTorrent handles it or in another way, is up to you guys. Do build a better client than uTorrent, as that one became SHIT!

Best of luck, guys and keep us up to date when changes are implemented.

Do close the issue, as well! :)

@soewhaty commented on GitHub (May 10, 2015): Very well said, of you! :) All of it. Totally agree! Especially the teenage part! :) Couldn't have put it better myself and I am not being ironic! :) I managed to get you guys annoyed enough so as to hopefully fix the issue. By saying 'can't it be made to work on a file level' I clearly meant finding out a way to delete or not download unchecked files, even though torrent clients work on piece level. Doing it in the way uTorrent handles it or in another way, is up to you guys. Do build a better client than uTorrent, as that one became SHIT! Best of luck, guys and keep us up to date when changes are implemented. Do close the issue, as well! :)
Author
Owner

@sledgehammer999 commented on GitHub (May 10, 2015):

Do you know what a cross-file piece is? It is a piece occupies the end of file A and the beginning of file B. If you want to download any of those 2 files, the second one will also appear on disk as partial file. That cross-file piece is essnetial for download + saving to disk, because the hash check of the file will fail. Hash checks need whole pieces.

There is nothing I can do at this point, because this is handle by libtorrent itself. Supposedly libtorrent 1.1.x has the feature of cramming unwanted pieces into a single monolithic file, but this isn't released yet.

@sledgehammer999 commented on GitHub (May 10, 2015): Do you know what a cross-file piece is? It is a piece occupies the end of file A and the beginning of file B. If you want to download any of those 2 files, the second one will also appear on disk as partial file. That cross-file piece is essnetial for download + saving to disk, because the hash check of the file will fail. Hash checks need whole pieces. There is nothing I can do at this point, because this is handle by libtorrent itself. Supposedly libtorrent 1.1.x has the feature of cramming unwanted pieces into a single monolithic file, but this isn't released yet.
Author
Owner

@soewhaty commented on GitHub (May 10, 2015):

Alright, alright ... issue resolved! :) In the end of the day, I'd like to say that all I wanted to do is give you guys feedback and hopefully help you improve your app, which I like so much. Sorry, if it seemed too much like teenage garbage :)

@soewhaty commented on GitHub (May 10, 2015): Alright, alright ... issue resolved! :) In the end of the day, I'd like to say that all I wanted to do is give you guys feedback and hopefully help you improve your app, which I like so much. Sorry, if it seemed too much like teenage garbage :)
Author
Owner

@sledgehammer999 commented on GitHub (May 10, 2015):

We are aware of the problem. However at this point we can't something else. We are limited by libtorrent.

@sledgehammer999 commented on GitHub (May 10, 2015): We are aware of the problem. However at this point we can't something else. We are limited by libtorrent.
Author
Owner

@Shirkit commented on GitHub (Dec 14, 2015):

Maybe it's good enough to implement a on-complete pos-check on Windows only to solve this issue? As an advanced option, and only enabled if check torrents at completion is enabled? Probably not worth it.

@Shirkit commented on GitHub (Dec 14, 2015): Maybe it's good enough to implement a on-complete pos-check on Windows only to solve this issue? As an advanced option, and only enabled if check torrents at completion is enabled? Probably not worth it.
Author
Owner

@brunojt commented on GitHub (Feb 9, 2016):

qBittorrent is a great software but this bug is unacceptable, i'm uninstalling it.

@brunojt commented on GitHub (Feb 9, 2016): qBittorrent is a great software but this bug is unacceptable, i'm uninstalling it.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/qBittorrent#2433
No description provided.