3.3 Bug returned where setting files to &#34;do not download&#34; downloads them anyway #3414

Author

Owner

@cbdejavu commented on GitHub (Nov 30, 2015):

Is it possible to get the last version that worked correctly until 3.3 line is more stable?

@cbdejavu commented on GitHub (Nov 30, 2015): Is it possible to get the last version that worked correctly until 3.3 line is more stable?

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Nov 30, 2015):

Do you mean that they download fully?

@sledgehammer999 commented on GitHub (Nov 30, 2015): Do you mean that they download fully?

deekerman commented

Author

Owner

@cbdejavu commented on GitHub (Nov 30, 2015):

I don't believe they are fully downloaded just the left over remains of the boundary files. If I download only 1 file in a torrent containing 6 files. I get all of the files when It's done and some are complete, but others are corrupt so I'm guessing just the fragments.

It used to collect the "do not download" files that it had to partially download and put it in a hidden folder called .Unwanted. Then that folder was usually deleted when you deleted the torrent from qBittorrent (although not always 100% but at least all the files where in that hidden sub directory so they could be easily deleted manually when they didn't automatically delete.

@cbdejavu commented on GitHub (Nov 30, 2015): I don't believe they are fully downloaded just the left over remains of the boundary files. If I download only 1 file in a torrent containing 6 files. I get all of the files when It's done and some are complete, but others are corrupt so I'm guessing just the fragments. It used to collect the "do not download" files that it had to partially download and put it in a hidden folder called .Unwanted. Then that folder was usually deleted when you deleted the torrent from qBittorrent (although not always 100% but at least all the files where in that hidden sub directory so they could be easily deleted manually when they didn't automatically delete.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Nov 30, 2015):

So these files don't go inside ".unwanted"?

@sledgehammer999 commented on GitHub (Nov 30, 2015): So these files don't go inside ".unwanted"?

deekerman commented

Author

Owner

@cbdejavu commented on GitHub (Nov 30, 2015):

.unwanted isn't being created anymore.

@cbdejavu commented on GitHub (Nov 30, 2015): .unwanted isn't being created anymore.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Nov 30, 2015):

Does the GUI show the files as checked in the "Content" tab? (bottom of the window)

@sledgehammer999 commented on GitHub (Nov 30, 2015): Does the GUI show the files as checked in the "Content" tab? (bottom of the window)

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Nov 30, 2015):

I am almost certain that your "bug" is manifestation of the issue I describe(and try to fix) in #3687.
As it is now, this cannot be fixed now reliably(ie put them in the .unwanted folder). So as we discussed there, I am going to remove the ".unwanted" folder functionality and dump the incomplete files in the same dir.

@sledgehammer999 commented on GitHub (Nov 30, 2015): I am almost certain that your "bug" is manifestation of the issue I describe(and try to fix) in #3687. As it is now, this cannot be fixed now reliably(ie put them in the .unwanted folder). So as we discussed there, I am going to remove the ".unwanted" folder functionality and dump the incomplete files in the same dir.

deekerman commented

Author

Owner

@Bobb-E-Burns commented on GitHub (Nov 30, 2015):

Can confirm this.

Content tab shows only checked what i selected, but no .unwanted folder is created and files in the same 'piece' are created in the same folder as the selected file.
It does still show as a much lower 'size on disk' though. 2,75mb for a 420mb file in this test case.

I am going to remove the ".unwanted" folder functionality and dump the incomplete files in the same dir

As long as they still get cleaned up after a torrent is deleted from qBit i see no problem with this.
edit: Is it not possible to have the files become 'hidden'? So instead of moving them to the 'hidden' .unwanted make the files 'hidden' itself and do without the folder?

@Bobb-E-Burns commented on GitHub (Nov 30, 2015): Can confirm this. Content tab shows only checked what i selected, but no `.unwanted` folder is created and files in the same 'piece' are created in the same folder as the selected file. It does still show as a much lower 'size on disk' though. 2,75mb for a 420mb file in this test case. > I am going to remove the ".unwanted" folder functionality and dump the incomplete files in the same dir As long as they still get cleaned up after a torrent is deleted from qBit i see no problem with this. **edit:** Is it not possible to have the files become 'hidden'? So instead of moving them to the 'hidden' `.unwanted` make the files 'hidden' itself and do without the folder?

deekerman commented

Author

Owner

@cbdejavu commented on GitHub (Nov 30, 2015):

I have to agree with Nhoise. As long as when the torrent is done and the files that were marked do not download are removed or deleted from the final folder it shouldn't really matter too much were the files are stored during the actual download process. Right now this is a huge cleanup mess after downloading each torrent when you only want part of the torrent package.

@cbdejavu commented on GitHub (Nov 30, 2015): I have to agree with Nhoise. As long as when the torrent is done and the files that were marked do not download are removed or deleted from the final folder it shouldn't really matter too much were the files are stored during the actual download process. Right now this is a huge cleanup mess after downloading each torrent when you only want part of the torrent package.

deekerman commented

Author

Owner

@ghost commented on GitHub (Dec 11, 2015):

Had the same problem - started with version 3.3.0
Went back to version 3.2.4. - problem gone. Clearly a bug starting with 3.3.0
Hopefully, the programmers will fix this bug in future versions. I plan on sticking with 3.2.4 indefinitely.

@ghost commented on GitHub (Dec 11, 2015): Had the same problem - started with version 3.3.0 Went back to version 3.2.4. - problem gone. Clearly a bug starting with 3.3.0 Hopefully, the programmers will fix this bug in future versions. I plan on sticking with 3.2.4 indefinitely.

deekerman commented

Author

Owner

@cbdejavu commented on GitHub (Dec 11, 2015):

Yeah I went back to 3.2.3 since that is what I had and I can't seem to find any other versions. It works fine. I'm sure they'll get this fixed having the "do not download" files be cleaned up is basic standard functionality of every bit torrent client out there and they had it working before so I'm sure it'll be fixed in a future update. In the meantime the 3.3.x series just needs a few revs to become a stable release it really should be classified as a beta version at this point with the issues it has as the 3.2.x series is truly stable and the 3.3.0 introduced to many issues that prevent daily use.

@cbdejavu commented on GitHub (Dec 11, 2015): Yeah I went back to 3.2.3 since that is what I had and I can't seem to find any other versions. It works fine. I'm sure they'll get this fixed having the "do not download" files be cleaned up is basic standard functionality of every bit torrent client out there and they had it working before so I'm sure it'll be fixed in a future update. In the meantime the 3.3.x series just needs a few revs to become a stable release it really should be classified as a beta version at this point with the issues it has as the 3.2.x series is truly stable and the 3.3.0 introduced to many issues that prevent daily use.

deekerman commented

http://qbittorrent.en.uptodown.com/old

Author

Owner

@ghost commented on GitHub (Dec 11, 2015):

Fortunately, I kept copies of 3.2.0, 3.2.3 and 3.2.4 so I went back to
3.2.4 which I knew was working fine.
I only did the update because it was there are I assumed it had some
previous issues fixed. Obviously I was wrong.
They do have the older versions available for download on their site at:

if others need to download 3.2.0 it.
For now I'm just happy to know that what I'm using is working correctly.
I'm sure I'll stick with it for a long time now. It's still my program
of choice for bittorrent.

On 12/11/2015 3:09 PM, cbdejavu wrote:

Yeah I went back to 3.2.3 since that is what I had and I can't seem to
find any other versions. It works fine. I'm sure they'll get this
fixed having the "do not download" files be cleaned up is basic
standard functionality of every bit torrent client out there and they
had it working before so I'm sure it'll be fixed in a future update.
In the meantime the 3.3.x series just needs a few revs to become a
stable release it really should be classified as a beta version at
this point with the issues it has as the 3.2.x series is truly stable
and the 3.3.0 introduced to many issues that prevent daily use.

—
Reply to this email directly or view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/4211#issuecomment-164036601.

@ghost commented on GitHub (Dec 11, 2015): Fortunately, I kept copies of 3.2.0, 3.2.3 and 3.2.4 so I went back to 3.2.4 which I knew was working fine. I only did the update because it was there are I assumed it had some previous issues fixed. Obviously I was wrong. They do have the older versions available for download on their site at: http://qbittorrent.en.uptodown.com/old if others need to download 3.2.0 it. For now I'm just happy to know that what I'm using is working correctly. I'm sure I'll stick with it for a long time now. It's still my program of choice for bittorrent. On 12/11/2015 3:09 PM, cbdejavu wrote: > Yeah I went back to 3.2.3 since that is what I had and I can't seem to > find any other versions. It works fine. I'm sure they'll get this > fixed having the "do not download" files be cleaned up is basic > standard functionality of every bit torrent client out there and they > had it working before so I'm sure it'll be fixed in a future update. > In the meantime the 3.3.x series just needs a few revs to become a > stable release it really should be classified as a beta version at > this point with the issues it has as the 3.2.x series is truly stable > and the 3.3.0 introduced to many issues that prevent daily use. > > — > Reply to this email directly or view it on GitHub > https://github.com/qbittorrent/qBittorrent/issues/4211#issuecomment-164036601.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Dec 12, 2015):

All windows releases are on our SourceForge page: http://sourceforge.net/projects/qbittorrent/files/qbittorrent-win32/
Latest from the v3.2.x series is v3.2.5

@sledgehammer999 commented on GitHub (Dec 12, 2015): All windows releases are on our SourceForge page: http://sourceforge.net/projects/qbittorrent/files/qbittorrent-win32/ Latest from the v3.2.x series is `v3.2.5`

deekerman commented

Author

Owner

@cbdejavu commented on GitHub (Dec 12, 2015):

Thanks, I'll have to bookmark that page and grab the 3.2.5. Then just keep checking back and see when this issue gets closed.

@cbdejavu commented on GitHub (Dec 12, 2015): Thanks, I'll have to bookmark that page and grab the 3.2.5. Then just keep checking back and see when this issue gets closed.

deekerman commented

Author

Owner

@ebugusey commented on GitHub (Jan 22, 2016):

qBittorrent behavior with unwanted parts is unreliable now. There is some test cases:

I'm adding torrent through dialog, I deselect all files but one and check "Start torrent" flag. After downloading I have selected file and some other files, that contain selected file parts.
- Then I selected another file in downloaded torrent. After downloading I have two selected files and .unwanted folder with files that contain selected files parts.
I'm adding torrent through dialog, I select all files, but uncheck "Start torrent" flag. After adding I deselect all files. qBittorrent says that download is complete. Then I select only one file. After downloading I have selected file and .unwanted folder with files that contain selected file parts.

@ebugusey commented on GitHub (Jan 22, 2016): qBittorrent behavior with unwanted parts is unreliable now. There is some test cases: - I'm adding torrent through dialog, I deselect all files but one and check "Start torrent" flag. After downloading I have selected file and some other files, that contain selected file parts. - Then I selected another file in downloaded torrent. After downloading I have two selected files and .unwanted folder with files that contain selected files parts. - I'm adding torrent through dialog, I select all files, but uncheck "Start torrent" flag. After adding I deselect all files. qBittorrent says that download is complete. Then I select only one file. After downloading I have selected file and .unwanted folder with files that contain selected file parts.

deekerman commented

Author

Owner

@plasmik010 commented on GitHub (Apr 18, 2016):

I have version 3.3.4 on Debian and it creates unwanted files which are post- and pre- wanted ones.

@plasmik010 commented on GitHub (Apr 18, 2016): I have version 3.3.4 on Debian and it creates unwanted files which are post- and pre- wanted ones.

deekerman commented

Author

Owner

@mettalic commented on GitHub (Aug 28, 2016):

Still not removing unwanted files and folders after completion. Version 3.3.6

@mettalic commented on GitHub (Aug 28, 2016): Still not removing unwanted files and folders after completion. Version 3.3.6

deekerman commented

Author

Owner

@cruz878 commented on GitHub (Jan 31, 2017):

Looks like this issue still exists in 3.3.10 as well.

@cruz878 commented on GitHub (Jan 31, 2017): Looks like this issue still exists in 3.3.10 as well.

deekerman commented

Author

Owner

@cbdejavu commented on GitHub (Feb 1, 2017):

v3.2.5 is the last version that this feature worked properly so that is the version I use. I don't think the dev team cares or is even trying to fix this per the comment back in November 30, 2015. Apparently even though EVERY other BitTorrent client out there that has the feature has it working properly one of the devs said back in November that it couldn't be fixed reliably.

Really if the feature doesn't work and the devs aren't planning on making it work then the option to not download something should just be removed entirely if nobody can figure out how to code the feature properly. It essentially hasn't worked now for almost a year and half now so I wouldn't hold my breath that this is going to ever work again.

@cbdejavu commented on GitHub (Feb 1, 2017): v3.2.5 is the last version that this feature worked properly so that is the version I use. I don't think the dev team cares or is even trying to fix this per the comment back in November 30, 2015. Apparently even though EVERY other BitTorrent client out there that has the feature has it working properly one of the devs said back in November that it couldn't be fixed reliably. Really if the feature doesn't work and the devs aren't planning on making it work then the option to not download something should just be removed entirely if nobody can figure out how to code the feature properly. It essentially hasn't worked now for almost a year and half now so I wouldn't hold my breath that this is going to ever work again.

deekerman commented