Force recheck does nothing when .!qB is enabled #146

Author

Owner

@backie commented on GitHub (Oct 18, 2012):

I can confirm this at Archlinux also in 3.0.6. This is kind of serious, because I can NOT add any torrent without downloading a whole thing.

@backie commented on GitHub (Oct 18, 2012): I can confirm this at Archlinux also in 3.0.6. This is kind of serious, because I can NOT add any torrent without downloading a whole thing.

deekerman commented

Author

Owner

@surfernsk commented on GitHub (Oct 22, 2012):

join. This problem exists, and has existed in earlier versions of qbittorrent

@surfernsk commented on GitHub (Oct 22, 2012): join. This problem exists, and has existed in earlier versions of qbittorrent

deekerman commented

Author

Owner

@slacka commented on GitHub (Oct 28, 2012):

Let me get this right. The steps are:

start torrent
pause torrent
copy contents into folder used in step 1
do a "force recheck"
resume torrent

In step 4, the torrent does not go from ~0% to 100%, correct? Are you seeding an existing torrent with seeds and peers?

I have tried to reproduce this issue under Windows, and I cannot. This may be a Linux specific bug.

@slacka commented on GitHub (Oct 28, 2012): Let me get this right. The steps are: 1) start torrent 2) pause torrent 3) copy contents into folder used in step 1 4) do a "force recheck" 5) resume torrent In step 4, the torrent does not go from ~0% to 100%, correct? Are you seeding an existing torrent with seeds and peers? I have tried to reproduce this issue under Windows, and I cannot. This may be a Linux specific bug.

deekerman commented

Author

Owner

@surfernsk commented on GitHub (Oct 28, 2012):

Check, if the option is adding a temporary extension.
After adding the torrent, moved or copied to a directory complete files, the hash does not affect new files.
Completed files are ignored, and the creates files with a temporary extension.
Also, When I change the root directory of the torrent in the tab "Content"
Tested on WinXP-qbittorrent 3.0.6 and Linux-qbittorrent 3.0.6
This not a Linux specific bug

@surfernsk commented on GitHub (Oct 28, 2012): Check, if the option is adding a temporary extension. After adding the torrent, moved or copied to a directory complete files, the hash does not affect new files. Completed files are ignored, and the creates files with a temporary extension. Also, When I change the root directory of the torrent in the tab "Content" Tested on WinXP-qbittorrent 3.0.6 and Linux-qbittorrent 3.0.6 This not a Linux specific bug

deekerman commented

Author

Owner

@slacka commented on GitHub (Oct 28, 2012):

I cannot reproduce this under Win XP or Win 7 with qBittorrent 3.0.6 with default settings following my steps listed above. If my steps are wrong, please outline the exact steps required to reproduce this bug as I have.

It sounds like you have:
Options->Downloads->"Append .!tB extension to incomplete files" checked

Uncheck this box and force recheck should behave as expected.

@slacka commented on GitHub (Oct 28, 2012): I cannot reproduce this under Win XP or Win 7 with qBittorrent 3.0.6 with default settings following my steps listed above. If my steps are wrong, please outline the exact steps required to reproduce this bug as I have. It sounds like you have: Options->Downloads->"Append .!tB extension to incomplete files" checked Uncheck this box and force recheck should behave as expected.

deekerman commented

Author

Owner

@nivensd commented on GitHub (Oct 29, 2012):

I don't have the extension appended, and it still will often take two force rechecks for qBittorrent to actually check the files. I have had to do this several times due to the other issues I've faced with qBittorrent.

@nivensd commented on GitHub (Oct 29, 2012): I don't have the extension appended, and it still will often take two force rechecks for qBittorrent to actually check the files. I have had to do this several times due to the other issues I've faced with qBittorrent.

deekerman commented

Author

Owner

@nivensd commented on GitHub (Oct 29, 2012):

I can usually tell which ones have been "skipped" because the listing number doesn't change. Perhaps this is perculiar to me, but whenever I force recheck, the torrents selected go to the end of the listing (almost 100% of the time).

@nivensd commented on GitHub (Oct 29, 2012): I can usually tell which ones have been "skipped" because the listing number doesn't change. Perhaps this is perculiar to me, but whenever I force recheck, the torrents selected go to the end of the listing (almost 100% of the time).

deekerman commented

Author

Owner

@gandalftools commented on GitHub (Nov 22, 2012):

I'm having this issue too in debian squeeze and Windows XP. In my case the torrent is private, and needs a ratio to download, but this shouldn't be an issue, to get the data to seed!
Since I cannot force recheck data shows as not completed.
I also don't have the extension appended.

@gandalftools commented on GitHub (Nov 22, 2012): I'm having this issue too in debian squeeze and Windows XP. In my case the torrent is private, and needs a ratio to download, but this shouldn't be an issue, to get the data to seed! Since I cannot force recheck data shows as not completed. I also don't have the extension appended.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Oct 1, 2013):

Hey, what is the status with 3.0.11 or git master? Does this still occur?

@sledgehammer999 commented on GitHub (Oct 1, 2013): Hey, what is the status with 3.0.11 or git master? Does this still occur?

deekerman commented

Author

Owner

@shortys-crew commented on GitHub (Nov 3, 2013):

I'm having these issues too with from 3.0.9 to 3.1.1.1 on Win 7.
Tried defining network interface, tried rechecking a million times, disabling !qT for incomplete files, etc.
Still, it'll never ever re-check the file or change from "Stalled".

I like Qbittorrent a lot, but it's being so horribly unreliable, I can't seed a single private torrent I create with it.

@shortys-crew commented on GitHub (Nov 3, 2013): I'm having these issues too with from 3.0.9 to 3.1.1.1 on Win 7. Tried defining network interface, tried rechecking a million times, disabling !qT for incomplete files, etc. Still, it'll never ever re-check the file or change from "Stalled". I like Qbittorrent a lot, but it's being so horribly unreliable, I can't seed a single private torrent I create with it.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Nov 4, 2013):

@shortys-crew Can you copy-paste the log after you have launched qbt and chose to force recheck a torrent?
(View->execution log)

@sledgehammer999 commented on GitHub (Nov 4, 2013): @shortys-crew Can you copy-paste the log after you have launched qbt and chose to force recheck a torrent? (View->execution log)

deekerman commented

Author

Owner

@shortys-crew commented on GitHub (Nov 4, 2013):

@sledgehammer999 I would but there is literally nothing to show. As in, after the line that shows my torrent as being added, nothing is added to the execution log. If I click force re-check it does nothing.

I have no other torrents in qBittorrent right now, only the one I am trying to seed from. Let me know if you need to me to do any other testing.

Still running 3.1.1.1 on Win 7.

@shortys-crew commented on GitHub (Nov 4, 2013): @sledgehammer999 I would but there is literally nothing to show. As in, after the line that shows my torrent as being added, nothing is added to the execution log. If I click force re-check it does nothing. I have no other torrents in qBittorrent right now, only the one I am trying to seed from. Let me know if you need to me to do any other testing. Still running 3.1.1.1 on Win 7.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Mar 10, 2015):

Same issue, git snapshot on arch linux x64.
I have a torrent where qB started downloading some files. Stopped it and put the completed files into the directory. Ran re-check, it only seems to see the files it started downloaded before. The progress is identical to the one before I copied files over. No messages in the execution log.

@Soukyuu commented on GitHub (Mar 10, 2015): Same issue, git snapshot on arch linux x64. I have a torrent where qB started downloading some files. Stopped it and put the completed files into the directory. Ran re-check, it only seems to see the files it started downloaded before. The progress is identical to the one before I copied files over. No messages in the execution log.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Mar 10, 2015):

Removing torrent and using the "import existing torrent" option works. Would be nice if "force recheck" used the same checking routine.

@Soukyuu commented on GitHub (Mar 10, 2015): Removing torrent and using the "import existing torrent" option works. Would be nice if "force recheck" used the same checking routine.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Mar 11, 2015):

@Soukyuu are you using the "keep incomplete torrents in:" option?

@sledgehammer999 commented on GitHub (Mar 11, 2015): @Soukyuu are you using the "keep incomplete torrents in:" option?

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Mar 11, 2015):

No, I know it's broken. The torrent in question is not saved in the default torrent directory, though.

@Soukyuu commented on GitHub (Mar 11, 2015): No, I know it's broken. The torrent in question is not saved in the default torrent directory, though.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Mar 11, 2015):

@Soukyuu does it happen only with multifile torrents? I just tested with single file torrents and it seems to work on Windows 7 (libtorrent 1.0.x).
In the meantime I'll try to find a small enough multifile torrent to test.

@sledgehammer999 commented on GitHub (Mar 11, 2015): @Soukyuu does it happen only with multifile torrents? I just tested with single file torrents and it seems to work on Windows 7 (libtorrent 1.0.x). In the meantime I'll try to find a small enough multifile torrent to test.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Mar 11, 2015):

I only noticed it with multi-file torrents so far. At least I don't remember it happening for single-file torrents.

@Soukyuu commented on GitHub (Mar 11, 2015): I only noticed it with multi-file torrents so far. At least I don't remember it happening for single-file torrents.

deekerman commented

Author

Owner

@xeddmc commented on GitHub (Mar 23, 2015):

Same problem with me now too. Just switched back to qBittorrent after I thought everything was fixed..but can't get my already downloaded torrents to seed, tried everything. This is on OSX Yosemite also. So it must be Unix based systems...

@xeddmc commented on GitHub (Mar 23, 2015): Same problem with me now too. Just switched back to qBittorrent after I thought everything was fixed..but can't get my already downloaded torrents to seed, tried everything. This is on OSX Yosemite also. So it must be Unix based systems...

deekerman commented

Author

Owner

@xeddmc commented on GitHub (Mar 23, 2015):

On my windows machine it works fine. Just my OS X...

@xeddmc commented on GitHub (Mar 23, 2015): On my windows machine it works fine. Just my OS X...

deekerman commented

Author

Owner

@chrishirst commented on GitHub (Mar 23, 2015):

Just my OS X...

Running what client version?

@chrishirst commented on GitHub (Mar 23, 2015): > Just my OS X... Running what client version?

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Apr 5, 2015):

@Soukyuu when you copy files over, are those files also "selected" in the qbt filelist before doing the recheck?
Note: You need first to select the files and then copy over them. Not the other way around.

@sledgehammer999 commented on GitHub (Apr 5, 2015): @Soukyuu when you copy files over, are those files also "selected" in the qbt filelist before doing the recheck? Note: You need first to select the files and then copy over them. Not the other way around.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 6, 2015):

This usually happens with batch torrents for me, so I load the torrent with all files selected, pause and exit qB. Then copy files over, start qB and hit "force recheck".

@Soukyuu commented on GitHub (Apr 6, 2015): This usually happens with batch torrents for me, so I load the torrent with all files selected, pause and exit qB. Then copy files over, start qB and hit "force recheck".

deekerman commented

Author

Owner

@cncDAni2 commented on GitHub (Apr 17, 2015):

The problem was at me, that qBittorrent used a "temp" folder for the files what was not completed (I did not tell it to do that...). So the best could be is to you turn it off. Otherwise, these steps worked for me:
1.) Start download torrent (1st and last first)
2.) Open destination folder
3.) Stop all torrent&exit
4.) Copy your files to location2.)
5.) Start qBittorrent&recheck files
If you uploaded your torrent, check the temp's exact location in options.

@cncDAni2 commented on GitHub (Apr 17, 2015): The problem was at me, that qBittorrent used a "temp" folder for the files what was not completed (I did not tell it to do that...). So the best could be is to you turn it off. Otherwise, these steps worked for me: 1.) Start download torrent (1st and last first) 2.) Open destination folder 3.) Stop all torrent&exit 4.) Copy your files to location2.) 5.) Start qBittorrent&recheck files If you uploaded your torrent, check the temp's exact location in options.

deekerman commented

Author

Owner

@re-l124c41plus commented on GitHub (Apr 29, 2015):

I'm having the same issue on Arch Linux 64 bit right now.
I have a torrent that was taking very long to download so I decided to download one of the files (accounting for 99% of the size) via IRC XDCC bot.
I moved the file to the correct download location and then restarted qBT, then forced a recheck.
That did not work and neither did any of the other variations I tried (deleting the torrent and readding, importing existing torrent, various combinations and orders of adding, deleting, rechecking and all that stuff).

qBT seems to do nothing when I click force recheck except for a brief flash in the status column that immediately goes back to paused (or stalled when I tried it while having the torrent running). No way that it hashes several gigabytes in half a second.

Another thing to note: up until today force recheck seemed to work. I'm not aware of any updates between the last time I tried this with a torrent and now. In fact I migrated all my torrents from Windows to Linux this way with no problem at all.

And last but not least the weirdest thing for me about this: I might be mistaking intended behaviour with a bug here but while testing this problem I also tried moving the files around and changing the set location in qBT which resulted in the hilarious and worrying observation that qBT:
a) moved the file I downloaded via IRC and had placed within the folder qBT was supposed to download ( /home/me/stuff/qBT_set_Location_to_download_here/Torrent_folder/bigFile ) to any new place I set as "qBT_set_Location_to_download_here". For example I clicked "set location" and chose /home/me/stuff/new_Place and qBT moved everything so that I had /home/me/stuff/new_Place/Torrent_folder/bigFile. Kind of strange if we assume that qBT did not acknowledge the existence of that bigFile I got via IRC. But maybe it just moves the whole Torrent folder?
b) apparently deleted the old folder I just called "qBT_set_Location_to_download_here" in a). The stuff was in /home/me/stuff/new_Place/Torrent_folder/bigFile as I said in a) but /home/me/stuff/qBT_set_Location_to_download_here was gone. I would have expected that folder to still be there although empty since neither qBT nor the torrent have any business with that folder besides being told "Download the stuff to that location".

This whole thing is really strange.

@re-l124c41plus commented on GitHub (Apr 29, 2015): I'm having the same issue on Arch Linux 64 bit right now. I have a torrent that was taking very long to download so I decided to download one of the files (accounting for 99% of the size) via IRC XDCC bot. I moved the file to the correct download location and then restarted qBT, then forced a recheck. That did not work and neither did any of the other variations I tried (deleting the torrent and readding, importing existing torrent, various combinations and orders of adding, deleting, rechecking and all that stuff). qBT seems to do nothing when I click force recheck except for a brief flash in the status column that immediately goes back to paused (or stalled when I tried it while having the torrent running). No way that it hashes several gigabytes in half a second. Another thing to note: up until today force recheck seemed to work. I'm not aware of any updates between the last time I tried this with a torrent and now. In fact I migrated all my torrents from Windows to Linux this way with no problem at all. And last but not least the weirdest thing for me about this: I might be mistaking intended behaviour with a bug here but while testing this problem I also tried moving the files around and changing the set location in qBT which resulted in the hilarious and worrying observation that qBT: a) moved the file I downloaded via IRC and had placed within the folder qBT was supposed to download ( /home/me/stuff/qBT_set_Location_to_download_here/Torrent_folder/bigFile ) to any new place I set as "qBT_set_Location_to_download_here". For example I clicked "set location" and chose /home/me/stuff/new_Place and qBT moved everything so that I had /home/me/stuff/new_Place/Torrent_folder/bigFile. Kind of strange if we assume that qBT did not acknowledge the existence of that bigFile I got via IRC. But maybe it just moves the whole Torrent folder? b) apparently deleted the old folder I just called "qBT_set_Location_to_download_here" in a). The stuff was in /home/me/stuff/new_Place/Torrent_folder/bigFile as I said in a) but /home/me/stuff/qBT_set_Location_to_download_here was gone. I would have expected that folder to still be there although empty since neither qBT nor the torrent have any business with that folder besides being told "Download the stuff to that location". This whole thing is really strange.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 29, 2015):

Just trying it again:

load torrent
uncheck "start torrent"
paste complete files into pre-made destination folder
execute "force recheck"
nothing happens

It's a batch torrent with ~30 files. The only option I have ticked is "append .!qb for incomplete downloads"

@Soukyuu commented on GitHub (Apr 29, 2015): Just trying it again: - load torrent - uncheck "start torrent" - paste complete files into pre-made destination folder - execute "force recheck" - nothing happens It's a batch torrent with ~30 files. The only option I have ticked is "append .!qb for incomplete downloads"

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 29, 2015):

Ah! Unticking "append .!qb to incomplete downloads" makes it work!
I guess when the option is active, it only checks for files ending with .!qb instead of also checking for the presence of completed files.

@Soukyuu commented on GitHub (Apr 29, 2015): Ah! Unticking "append .!qb to incomplete downloads" makes it work! I guess when the option is active, it only checks for files ending with .!qb instead of also checking for the presence of completed files.

deekerman commented

Author

Owner

@re-l124c41plus commented on GitHub (May 3, 2015):

I should mention that the ".!qb" fix does not necessarily fix this issue for everyone. It certainly doesn't fix it for me. I did not even have that enabled to begin with.

@re-l124c41plus commented on GitHub (May 3, 2015): I should mention that the ".!qb" fix does not necessarily fix this issue for everyone. It certainly doesn't fix it for me. I did not even have that enabled to begin with.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (May 3, 2015):

It's not really a fix, but it could be a hint to where things are going wrong.

@Soukyuu commented on GitHub (May 3, 2015): It's not really a fix, but it could be a hint to where things are going wrong.

deekerman commented

Author

Owner

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

I have no real solution but if you do your own compilations you could try PR #2892. It refactors the core of qbt and maybe inadvertently has fixed your problem too.

@sledgehammer999 commented on GitHub (May 6, 2015): I have no real solution but if you do your own compilations you could try PR #2892. It refactors the core of qbt and maybe inadvertently has fixed your problem too.

deekerman commented

Author

Owner

@re-l124c41plus commented on GitHub (May 7, 2015):

Okay I might test that. I don't have access to my main PC this weekend but I will try to test this on monday.

@re-l124c41plus commented on GitHub (May 7, 2015): Okay I might test that. I don't have access to my main PC this weekend but I will try to test this on monday.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (May 31, 2015):

@sledgehammer999: testing with PR #2892 does not solve the issue. I still have to uncheck the "append .!qb to incomplete files" option to make it realize the complete files are all there.

@Soukyuu commented on GitHub (May 31, 2015): @sledgehammer999: testing with PR #2892 does not solve the issue. I still have to uncheck the "append .!qb to incomplete files" option to make it realize the complete files are all there.

deekerman commented

Author

Owner

@htnmtoi commented on GitHub (Jun 26, 2015):

My personal case: unchecking the ".!qb" option did fix it for me.

@htnmtoi commented on GitHub (Jun 26, 2015): My personal case: unchecking the ".!qb" option did fix it for me.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 25, 2016):

So to sum up:

Have .!qB feature enabled.
Add a torrent and point it to the completed files.
It doesn't recheck automatically. But even you manually force recheck it doesn't find the completed torrents.

A slightly different step 2: point the torrent to empty folder, pause, copy the completed files, force recheck.

Can you guys test with v3.3.3?

@sledgehammer999 commented on GitHub (Jan 25, 2016): So to sum up: 1. Have `.!qB` feature enabled. 2. Add a torrent and point it to the completed files. 3. It doesn't recheck automatically. But even you manually force recheck it doesn't find the completed torrents. A slightly different step 2: point the torrent to empty folder, pause, copy the completed files, force recheck. Can you guys test with v3.3.3?

deekerman commented

Author

Owner

@efotinis commented on GitHub (Jan 29, 2016):

@sledgehammer999: Yes, I still observed the behavior you outlined in v3.3.3 (Win7 x64). As mentioned above, temporarily disabling ".!qt" allowed the recheck to run.

@efotinis commented on GitHub (Jan 29, 2016): @sledgehammer999: Yes, I still observed the behavior you outlined in v3.3.3 (Win7 x64). As mentioned above, temporarily disabling ".!qt" allowed the recheck to run.

deekerman commented

Author

Owner

@bigretromike commented on GitHub (Mar 1, 2016):

So basicly the solution could be: disable recheck with .!qt enabled, or when checking in recheck temporary add .!qt to filename of added file and if one with .!qt is present delete old one, and make new one from the inputed file.

@bigretromike commented on GitHub (Mar 1, 2016): So basicly the solution could be: disable recheck with .!qt enabled, or when checking in recheck temporary add .!qt to filename of added file and if one with .!qt is present delete old one, and make new one from the inputed file.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 7, 2016):

Can't seem to be able to make it re-check even with disabling .!qb - it just blinks and doesn't do anything. v3.3.3 arch linux.

@Soukyuu commented on GitHub (Apr 7, 2016): Can't seem to be able to make it re-check even with disabling .!qb - it just blinks and doesn't do anything. v3.3.3 arch linux.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 7, 2016):

Scratch that, there was a symlinking error on my side. The workaround still works.
However, having the .!qb option enabled still doesn't

@Soukyuu commented on GitHub (Apr 7, 2016): Scratch that, there was a symlinking error on my side. The workaround still works. However, having the .!qb option enabled still doesn't

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Apr 10, 2016):

I suspect we have an issue here. When adding a new torrent with custom extention enabled we might have 2 situations:

Path has the files without that extension because they were completed
Path has the files with the extension included because they were unfinished.

Question is which assumption do we make? We don't do the filechecking ourselves. We leave it to libtorrent. And it doesn't have a concept of checking for custom extensions alongside the regular ones.

@glassez sorry for tagging you, but can you bother looking into this?

@sledgehammer999 commented on GitHub (Apr 10, 2016): I suspect we have an issue here. When adding a new torrent with custom extention enabled we might have 2 situations: 1. Path has the files without that extension because they were completed 2. Path has the files with the extension included because they were unfinished. Question is which assumption do we make? We don't do the filechecking ourselves. We leave it to libtorrent. And it doesn't have a concept of checking for custom extensions alongside the regular ones. @glassez sorry for tagging you, but can you bother looking into this?

deekerman commented

Author

Owner

@shebang4 commented on GitHub (Apr 10, 2016):

Situation here on OSX with v3.3.3:

.!qB feature enabled
Completed (single) file already at target location
Adding torrent immediately renames the file with .!qB suffix
Manual force recheck successfully checks the file

@shebang4 commented on GitHub (Apr 10, 2016): Situation here on OSX with v3.3.3: 1. `.!qB` feature enabled 2. Completed (single) file already at target location 2. Adding torrent immediately renames the file with `.!qB` suffix 3. Manual force recheck successfully checks the file

deekerman commented

Author

Owner

@slacka commented on GitHub (Apr 11, 2016):

@sledgehammer999

If !qB feature enabled, how about calling 2 times? If the first time it fails to find normal files (1.), run a second time too see if the .!qb files are there (2.) It seems at least on some level for this feature to work either qbittorrent or libtorrent is going to have to be modified to handle this special case.

I checked and Deluge does not have any feature like "Append .!xx extension to incomplete files". Should you open a feature request over at libtorrent?

In the mean time, might want to put a warning in settings that it's an experimental or incomplete feature.

@slacka commented on GitHub (Apr 11, 2016): @sledgehammer999 If !qB feature enabled, how about calling 2 times? If the first time it fails to find normal files (1.), run a second time too see if the .!qb files are there (2.) It seems at least on some level for this feature to work either qbittorrent or libtorrent is going to have to be modified to handle this special case. I checked and Deluge does not have any feature like "Append .!xx extension to incomplete files". Should you open a feature request over [at libtorrent?](https://github.com/arvidn/libtorrent) In the mean time, might want to put a warning in settings that it's an experimental or incomplete feature.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 12, 2016):

@shebang4: I think the issue might only be affecting multi file torrents. Can't test right now, but so far I only tested with multi file ones.

I also don't see why you can't do two calls to libtorrent, once for .!qb and once without.

It's a similar issue with the "move complete files" feature, where you have to check both the incomplete and complete files directories, plus the .!qb and non-qb version.

On shebang4 notifications@github.com, Apr 10, 2016 9:25 PM wrote:Situation here on OSX with v3.3.3:

.!qB feature enabled
Completed (single) file already at target location
Adding torrent immediately renames the file with .!qB suffix
Manual force recheck successfully checks the file

—You are receiving this because you were mentioned.Reply to this email directly or view it on GitHub

@Soukyuu commented on GitHub (Apr 12, 2016): @shebang4: I think the issue might only be affecting multi file torrents. Can't test right now, but so far I only tested with multi file ones. I also don't see why you can't do two calls to libtorrent, once for .!qb and once without. It's a similar issue with the "move complete files" feature, where you have to check both the incomplete and complete files directories, plus the .!qb and non-qb version. On shebang4 notifications@github.com, Apr 10, 2016 9:25 PM wrote:Situation here on OSX with v3.3.3: 1. .!qB feature enabled 2. Completed (single) file already at target location 2. Adding torrent immediately renames the file with .!qB suffix 3. Manual force recheck successfully checks the file —You are receiving this because you were mentioned.Reply to this email directly or view it on GitHub

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 12, 2016):

When adding a new torrent with custom extention enabled we might have 2 situations:

Path has the files without that extension because they were completed

Path has the files with the extension included because they were unfinished.

@glassez sorry for tagging you, but can you bother looking into this?

Adding !qB extension and saving incomplete torrents in different folder are extremely ill-conceived features. You brought only two cases, but actually we have a few dozen cases here. For example, user has both completed and incompleted files, user has completed files in target folder and I incompleted in temp folder, and so on. And there's no way we handled most of the possible cases (and libtorrent doesn't do this since these features are implemented outside of it).
To fix this issue, we must decide how to classify all of these cases for some characteristics.
Besides, it would be nice to reduce the number of possible cases. For example, to enable extension and a temporary folder for incomplete torrents at the same time is really overkill.

@glassez commented on GitHub (Apr 12, 2016): > When adding a new torrent with custom extention enabled we might have 2 situations: > 1. Path has the files without that extension because they were completed > 2. Path has the files with the extension included because they were unfinished. > > @glassez sorry for tagging you, but can you bother looking into this? Adding !qB extension and saving incomplete torrents in different folder are extremely ill-conceived features. You brought only two cases, but actually we have a few dozen cases here. For example, user has both completed and incompleted files, user has completed files in target folder and I incompleted in temp folder, and so on. And there's no way we handled most of the possible cases (and libtorrent doesn't do this since these features are implemented outside of it). To fix this issue, we must decide how to classify all of these cases for some characteristics. Besides, it would be nice to reduce the number of possible cases. For example, to enable extension and a temporary folder for incomplete torrents at the same time is really overkill.

deekerman commented

Author

Owner

@zeule commented on GitHub (Apr 12, 2016):

And there's no way we handled most of the possible cases...

Could you elaborate on this, please? Because the problem seems to be straightforward to me. There are series of files (torrent contents) and a set of directories. We iterate over files, for each file check all the directories with and without the additional extension. If more than one file was found, we show a dialog to the user, where he can select which file to use (and, maybe, those to delete too).

@zeule commented on GitHub (Apr 12, 2016): > And there's no way we handled most of the possible cases... Could you elaborate on this, please? Because the problem seems to be straightforward to me. There are series of files (torrent contents) and a set of directories. We iterate over files, for each file check all the directories with and without the additional extension. If more than one file was found, we show a dialog to the user, where he can select which file to use (and, maybe, those to delete too).

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 12, 2016):

It's a very useful feature but for some reason only VUZE and µtorrent seem to have it working.
Yes, there are many cases, but they are not that many. All you really have to do (without me knowing the code) is to permute through them, detect which files are located where, then pass the correct file paths to libtorrent.

evsh was a bit faster.

@Soukyuu commented on GitHub (Apr 12, 2016): It's a very useful feature but for some reason only VUZE and µtorrent seem to have it working. Yes, there are many cases, but they are not that many. All you really have to do (without me knowing the code) is to permute through them, detect which files are located where, then pass the correct file paths to libtorrent. evsh was a bit faster.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 12, 2016):

Here's some psudo code, again, without knowledge of the internals. Should cover all the cases. Do tell if I missed something

string findExistingFile()
{
   string path = "";
   // check if file is in completed path
   path = check_compl_dir();
   if (path != "")
   {
      return path; //file found
   }
   // check if file with appended .!qb is present
   if (append_qb)
   {
      path = check_compl_dir_qb();
      if (path != "")
      {
         return path; //file found
      }
   }

   // if move completed is active, also check temp path
   if (move_completed)
   {
      // first the file with normal extension
      fileList.add(check_temp_dir());
      if (path != "")
      {
         return path; //file found
      }
      // now the one with .!qb appended, if necessary
      if (append_qb)
      {
         fileList.add(check_temp_dir_qb());
      }
   }
}

StringList collectExistingFiles()
{
   StringList files;
   for each (string file in fileList)
   {
      files.add(findExistingFile());
   }
   return files;
}

void qBittorrentCheckingFunc()
{
   someLibTorrentHashCall(collectExistingFiles());
}

@Soukyuu commented on GitHub (Apr 12, 2016): Here's some psudo code, again, without knowledge of the internals. Should cover all the cases. Do tell if I missed something ``` string findExistingFile() { string path = ""; // check if file is in completed path path = check_compl_dir(); if (path != "") { return path; //file found } // check if file with appended .!qb is present if (append_qb) { path = check_compl_dir_qb(); if (path != "") { return path; //file found } } // if move completed is active, also check temp path if (move_completed) { // first the file with normal extension fileList.add(check_temp_dir()); if (path != "") { return path; //file found } // now the one with .!qb appended, if necessary if (append_qb) { fileList.add(check_temp_dir_qb()); } } } StringList collectExistingFiles() { StringList files; for each (string file in fileList) { files.add(findExistingFile()); } return files; } void qBittorrentCheckingFunc() { someLibTorrentHashCall(collectExistingFiles()); } ```

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 12, 2016):

Ah, to clarify, collectExistingFiles() is basically what you'd use for multi-file torrent, while the findExistingFile() one is used internally, and also used for single file torrents.

@Soukyuu commented on GitHub (Apr 12, 2016): Ah, to clarify, collectExistingFiles() is basically what you'd use for multi-file torrent, while the findExistingFile() one is used internally, and also used for single file torrents.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 13, 2016):

To fix this issue, we must decide how to classify all of these cases for some characteristics.

@Soukyuu In your pseudocode you did it implicitly. I.e. you set priorities as follows:

Files in completed folder
.!qB files in completed folder
Files in incompleted (temp) folder
.!qB files in incompleted (temp) folder

I'm not sure this is entirely correct. What do others think?
Besides, it is necessary to understand in what real situations the user may need to do "forceRecheck".

@glassez commented on GitHub (Apr 13, 2016): > To fix this issue, we must decide how to classify all of these cases for some characteristics. @Soukyuu In your pseudocode you did it implicitly. I.e. you set priorities as follows: 1. Files in completed folder 2. .!qB files in completed folder 3. Files in incompleted (temp) folder 4. .!qB files in incompleted (temp) folder I'm not sure this is entirely correct. What do others think? Besides, it is necessary to understand in what real situations the user may need to do "forceRecheck".

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 13, 2016):

Why do you think it's incorrect? The files with the highest completion percentage will usually be in the completed directory.

On Vladimir Golovnev notifications@github.com, Apr 13, 2016 7:31 AM wrote:
To fix this issue, we must decide how to classify all of these cases for some characteristics.

@Soukyuu In your pseudocode you did it implicitly. I.e. you set priorities as follows:

Files in completed folder
.!qB files in completed folder
Files in incompleted (temp) folder
.!qB files in incompleted (temp) folder

I'm not sure this is entirely correct. What do others think?
Besides, it is necessary to understand in what real situations the user may need to do "forceRecheck".

—You are receiving this because you were mentioned.Reply to this email directly or view it on GitHub

@Soukyuu commented on GitHub (Apr 13, 2016): Why do you think it's incorrect? The files with the highest completion percentage will usually be in the completed directory. On Vladimir Golovnev notifications@github.com, Apr 13, 2016 7:31 AM wrote: To fix this issue, we must decide how to classify all of these cases for some characteristics. @Soukyuu In your pseudocode you did it implicitly. I.e. you set priorities as follows: 1. Files in completed folder 2. .!qB files in completed folder 3. Files in incompleted (temp) folder 4. .!qB files in incompleted (temp) folder I'm not sure this is entirely correct. What do others think? Besides, it is necessary to understand in what real situations the user may need to do "forceRecheck". —You are receiving this because you were mentioned.Reply to this email directly or view it on GitHub

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 13, 2016):

Sorry, misclicked and sent too early. Continuing: Of course you could also check both directories and pick the one with the higher completion. Another thing I did implicitly is assume the completed directory is the default directory. They could differ.

Another thing is that no matter where the files were found, you have to ensure they are moved to the directory user wants them to be in on completion

On Vladimir Golovnev notifications@github.com, Apr 13, 2016 7:31 AM wrote:
To fix this issue, we must decide how to classify all of these cases for some characteristics.

@Soukyuu In your pseudocode you did it implicitly. I.e. you set priorities as follows:

Files in completed folder
.!qB files in completed folder
Files in incompleted (temp) folder
.!qB files in incompleted (temp) folder

I'm not sure this is entirely correct. What do others think?
Besides, it is necessary to understand in what real situations the user may need to do "forceRecheck".

—You are receiving this because you were mentioned.Reply to this email directly or view it on GitHub

@Soukyuu commented on GitHub (Apr 13, 2016): Sorry, misclicked and sent too early. Continuing: Of course you could also check both directories and pick the one with the higher completion. Another thing I did implicitly is assume the completed directory is the default directory. They could differ. Another thing is that no matter where the files were found, you have to ensure they are moved to the directory user wants them to be in on completion On Vladimir Golovnev notifications@github.com, Apr 13, 2016 7:31 AM wrote: To fix this issue, we must decide how to classify all of these cases for some characteristics. @Soukyuu In your pseudocode you did it implicitly. I.e. you set priorities as follows: 1. Files in completed folder 2. .!qB files in completed folder 3. Files in incompleted (temp) folder 4. .!qB files in incompleted (temp) folder I'm not sure this is entirely correct. What do others think? Besides, it is necessary to understand in what real situations the user may need to do "forceRecheck". —You are receiving this because you were mentioned.Reply to this email directly or view it on GitHub

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 13, 2016):

Of course you could also check both directories and pick the one with the higher completion.

We can't compare files on the basis of their completion.

Another thing is that no matter where the files were found, you have to ensure they are moved to the directory user wants them to be in on completion

Even incompleted files?

Why do you think it's incorrect? The files with the highest completion percentage will usually be in the completed directory.

Under normal conditions we can have only one instance of files. If we have multiple, it means that the user intervened in the operation of the application. But in this case we can't know exactly what he ~~messed up~~ did.

@glassez commented on GitHub (Apr 13, 2016): > Of course you could also check both directories and pick the one with the higher completion. We can't compare files on the basis of their completion. > Another thing is that no matter where the files were found, you have to ensure they are moved to the directory user wants them to be in on completion Even incompleted files? > Why do you think it's incorrect? The files with the highest completion percentage will usually be in the completed directory. Under normal conditions we can have only one instance of files. If we have multiple, it means that the user intervened in the operation of the application. But in this case we can't know exactly what he <del>messed up</del> did.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 13, 2016):

We can't compare files on the basis of their completion.

In that case checking default (or user selected, if they did) -> complete -> incomplete makes the most sense to me. Even if there are multiple sets of files, we should get the ones with the highest completion rate that way

Even incompleted files?

I specifically stated on completion, so no, talking about complete files only

Under normal conditions we can have only one instance of files. If we have multiple, it means that the user intervened in the operation of the application. But in this case we can't know exactly what he messed up did.

You could always prompt the user to select which dir to use in case of multiple file sets. Better than risking picking the wrong one and delete downloaded files

@Soukyuu commented on GitHub (Apr 13, 2016): > We can't compare files on the basis of their completion. In that case checking default (or user selected, if they did) -> complete -> incomplete makes the most sense to me. Even if there are multiple sets of files, we should get the ones with the highest completion rate that way > Even incompleted files? I specifically stated _on completion_, so no, talking about complete files only > Under normal conditions we can have only one instance of files. If we have multiple, it means that the user intervened in the operation of the application. But in this case we can't know exactly what he messed up did. You could always prompt the user to select which dir to use in case of multiple file sets. Better than risking picking the wrong one and delete downloaded files

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Apr 13, 2016):

If incomplete folder is checked, you need to check the completed one first and then the incompleted. Also completed folder by definition shouldn't contain any .!qB files.

But iterating files (basically querying the filesystem) needs special care for big torrents. In the pre-3.2.x era(IIRC) we queried the filesystem in the AddNewTorrent dialog(for some other feature) and it resulted into the application taking ages to open torrents with hundreds of files.
One example file is this: http://www.nyaa.se/?page=download&tid=720034

@sledgehammer999 commented on GitHub (Apr 13, 2016): If incomplete folder is checked, you need to check the completed one first and then the incompleted. Also completed folder by definition shouldn't contain any .!qB files. But iterating files (basically querying the filesystem) needs special care for big torrents. In the pre-3.2.x era(IIRC) we queried the filesystem in the AddNewTorrent dialog(for some other feature) and it resulted into the application taking ages to open torrents with hundreds of files. One example file is this: http://www.nyaa.se/?page=download&tid=720034

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 13, 2016):

You're right about no .!qb files in completed dir, of course.

As for querying, I don't think querying for something like File.exists should take that long. If you start collecting file properties, then it might escalate, but I don't think we need that here.

@Soukyuu commented on GitHub (Apr 13, 2016): You're right about no .!qb files in completed dir, of course. As for querying, I don't think querying for something like File.exists should take that long. If you start collecting file properties, then it might escalate, but I don't think we need that here.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 13, 2016):

@sledgehammer999 I can investigate this issue. I can't promise that I'll fix it fully, but I'll try to smooth acute angles. You can assign this issue to me.

@glassez commented on GitHub (Apr 13, 2016): @sledgehammer999 I can investigate this issue. I can't promise that I'll fix it fully, but I'll try to smooth acute angles. You can assign this issue to me.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 14, 2016):

My first suggestion: when we add a new torrent, we should only deal with files in the target folder without any additional extensions. IMO, this is logical, and it's hard for me to imagine a situation when we would have to act differently.

@glassez commented on GitHub (Apr 14, 2016): My first suggestion: when we add a new torrent, we should only deal with files in the target folder without any additional extensions. IMO, this is logical, and it's hard for me to imagine a situation when we would have to act differently.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 14, 2016):

it's hard for me to imagine a situation when we would have to act differently.

I can think of ~~three~~ four situations off the top of my head:

changing PCs
changing/reinstalling OS
changing bittorrent client
changing your BT folder locations (moving to another partition, etc)

Been there in each of them, you can't expect people to only add complete torrents. Third scenario is tricky, but usually renaming from one "incomplete" extension to .!qb is all the user needs to do.

Reminder: Issues #127 and #1202 are directly related to this one, as both require the same logic.

@Soukyuu commented on GitHub (Apr 14, 2016): > it's hard for me to imagine a situation when we would have to act differently. I can think of ~~three~~ four situations off the top of my head: - changing PCs - changing/reinstalling OS - changing bittorrent client - changing your BT folder locations (moving to another partition, etc) Been there in each of them, you can't expect people to only add complete torrents. Third scenario is tricky, but usually renaming from one "incomplete" extension to .!qb is all the user needs to do. Reminder: Issues #127 and #1202 are directly related to this one, as both require the same logic.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 14, 2016):

I'm not going to try to handle all possible situations, but only those that have the sense to handle.

If user has saved qBittorrent settings there is nothing to do additionally. If not we can't handle this situation in common case.
The same as above.
We can't handle this situation in common case. But...

usually renaming from one "incomplete" extension to .!qb is all the user needs to do

Manually deleting "incomplete" extension before adding to qBittorrent is all the user needs to do.
4. Just move all torrents using qBittorrent.

@glassez commented on GitHub (Apr 14, 2016): I'm not going to try to handle all possible situations, but only those that have the sense to handle. 1. If user has saved qBittorrent settings there is nothing to do additionally. If not we can't handle this situation in common case. 2. The same as above. 3. We can't handle this situation in common case. But... > usually renaming from one "incomplete" extension to .!qb is all the user needs to do Manually deleting "incomplete" extension before adding to qBittorrent is all the user needs to do. 4. Just move all torrents using qBittorrent.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 14, 2016):

By the way, in some cases, "Import torrent" feature may be useful. But I isn't familiar with it.

@glassez commented on GitHub (Apr 14, 2016): By the way, in some cases, "Import torrent" feature may be useful. But I isn't familiar with it.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 14, 2016):

I'm not going to try to handle all possible situations, but only those that have the sense to handle.

You are making this more complicated than it has to be. You're already starting to branch out logic depending on whether you are adding a new torrent or rechecking an existent one. Why not use the same logic everywhere? Otherwise you will have to maintain all those separate "locate files and check them if necessary" logic paths and end up in the current situation, namely some paths working and some not.

By the way, in some cases, "Import torrent" feature may be useful. But I isn't familiar with it.

This is one such example. "Import torrent" works and correctly checks files in the destination directory. See what I mean about multiple logic paths and only some working?

It doesn't make much sense to have torrent import separate from adding new torrent dialog anyway. It is currently rather cumbersome, since you can only import torrents one by one.

@Soukyuu commented on GitHub (Apr 14, 2016): > I'm not going to try to handle all possible situations, but only those that have the sense to handle. You are making this more complicated than it has to be. You're already starting to branch out logic depending on whether you are adding a new torrent or rechecking an existent one. Why not use the same logic everywhere? Otherwise you will have to maintain all those separate "locate files and check them if necessary" logic paths and end up in the current situation, namely some paths working and some not. > By the way, in some cases, "Import torrent" feature may be useful. But I isn't familiar with it. This is one such example. "Import torrent" works and correctly checks files in the destination directory. See what I mean about multiple logic paths and only some working? It doesn't make much sense to have torrent import separate from adding new torrent dialog anyway. It is currently rather cumbersome, since you can only import torrents one by one.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 14, 2016):

@Soukyuu How can I discuss this with you if you are not familiar with how it really works?

@glassez commented on GitHub (Apr 14, 2016): @Soukyuu How can I discuss this with you if you are not familiar with how it really works?

deekerman commented

Author

Owner

@zeule commented on GitHub (Apr 14, 2016):

@glassez: common sense suggests that there is a simple and general solution. If there are any obstacles to it, which you see and we don't, please explain here why it is so and we will find a way to evade them. But probably you will find it yourself during writing the things down.

@zeule commented on GitHub (Apr 14, 2016): @glassez: common sense suggests that there is a simple and general solution. If there are any obstacles to it, which you see and we don't, please explain here why it is so and we will find a way to evade them. But probably you will find it yourself during writing the things down.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 14, 2016):

@evsh A "simple and general" solution is what I propose.

@glassez commented on GitHub (Apr 14, 2016): @evsh A "simple and general" solution is what I propose.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 14, 2016):

@glassez What you propose is having multiple solutions for each entry path. It's a bad idea design-wise, because as I said, you have to maintain very similar code paths separately instead of having a common one. I might not know the qbittorrent code, but I do know things about (general) software design.

So as @evsh said, if there are obstacles that stem from the design of qbittorrent, do tell us about them.

@Soukyuu commented on GitHub (Apr 14, 2016): @glassez What you propose is having multiple solutions for each entry path. It's a bad idea design-wise, because as I said, you have to maintain very similar code paths separately instead of having a common one. I might not know the qbittorrent code, but I do know things about (general) software design. So as @evsh said, if there are obstacles that stem from the design of qbittorrent, do tell us about them.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 14, 2016):

What you propose is having multiple solutions for each entry path

@Soukyuu, No need to think for me. I suggest to have one common solution, but only one that will solve common problems, rather than trying to please everyone.

I'll try to explain it differently.
When we add a new torrent, we have only its metadata, the user defined save path and file mapping. That's all we know. What can we do? We can only make the most obvious assumptions: we either have no existing data, or we have data with exactly the same mapping as the user specified when adding this torrent (moreover, we do not care, it is completed or not). This is the behavior I'm suggesting. And attempts to handle other situations do not have "simple and general" solutions, in my humble opinion.
As for rechecking the existing torrent, there is no "simple and general" way to do anything except rechecking those files which are known to BitTorrent Session. That means if we are currently saving the files to a temporary folder, we can't just go and check the files in the target folder (or any other). And so on...

@glassez commented on GitHub (Apr 14, 2016): > What you propose is having multiple solutions for each entry path @Soukyuu, No need to think for me. I suggest to have one common solution, but only one that will solve common problems, rather than trying to please everyone. I'll try to explain it differently. When we add a new torrent, we have only its metadata, the user defined save path and file mapping. That's all we know. What can we do? We can only make the most obvious assumptions: we either have no existing data, or we have data with exactly the same mapping as the user specified when adding this torrent (moreover, we do not care, it is completed or not). This is the behavior I'm suggesting. And attempts to handle other situations do not have "simple and general" solutions, in my humble opinion. As for rechecking the existing torrent, there is no "simple and general" way to do anything except rechecking those files which are known to BitTorrent Session. That means if we are currently saving the files to a temporary folder, we can't just go and check the files in the target folder (or any other). And so on...

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 15, 2016):

@Soukyuu You were really right about something. I just looked up the code for "Import torrent" feature. It turns out that it's completely useless. It doesn't do anything that would be impossible to make using common "Add new torrent" dialogue.
@sledgehammer999 I think we should completely remove "import torrent dialog" (of course after I fix rechecking issue).

@glassez commented on GitHub (Apr 15, 2016): @Soukyuu You were really right about something. I just looked up the code for "Import torrent" feature. It turns out that it's completely useless. It doesn't do anything that would be impossible to make using common "Add new torrent" dialogue. @sledgehammer999 I think we should completely remove "import torrent dialog" (of course after I fix rechecking issue).

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 15, 2016):

No need to think for me. I suggest to have one common solution, but only one that will solve common problems, rather than trying to please everyone.

That was not my intention, I'm merely offering feedback.

When we add a new torrent, we have only its metadata, the user defined save path and file mapping. That's all we know.

Don't you also know if the feature to move on completion and/or appending .!qb is enabled?

We can only make the most obvious assumptions: we either have no existing data, or we have data with exactly the same mapping as the user specified when adding this torrent (moreover, we do not care, it is completed or not).

The mapping includes user enabled options I'm mentioned, no? They should be. All I'm saying is that upon adding a torrent, it won't hurt to check the incompleted(=user selected) directory for .!qb files, and the completed directory for any complete files.

As for rechecking the existing torrent, there is no "simple and general" way to do anything except rechecking those files which are known to BitTorrent Session.

I agree with you on that. To clarify, if the user has enabled .!qb, qbittorrent will expect the files of the loaded torrent to have the extension in the current directory, right?

You were really right about something

I was? (I kid, don't hurt me please)

@Soukyuu commented on GitHub (Apr 15, 2016): > No need to think for me. I suggest to have one common solution, but only one that will solve common problems, rather than trying to please everyone. That was not my intention, I'm merely offering feedback. > When we add a new torrent, we have only its metadata, the user defined save path and file mapping. That's all we know. Don't you also know if the feature to move on completion and/or appending .!qb is enabled? > We can only make the most obvious assumptions: we either have no existing data, or we have data with exactly the same mapping as the user specified when adding this torrent (moreover, we do not care, it is completed or not). The mapping includes user enabled options I'm mentioned, no? They should be. All I'm saying is that upon adding a torrent, it won't hurt to check the incompleted(=user selected) directory for .!qb files, and the completed directory for any complete files. > As for rechecking the existing torrent, there is no "simple and general" way to do anything except rechecking those files which are known to BitTorrent Session. I agree with you on that. To clarify, if the user has enabled .!qb, qbittorrent will expect the files of the loaded torrent to have the extension in the current directory, right? > You were really right about something I was? (I kid, don't hurt me please)

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 15, 2016):

Don't you also know if the feature to move on completion and/or appending .!qb is enabled?

We know current settings but we don't know something about the past. If the previous settings (before reinstalling OS, changing PC, etc.) do not match with the current, detecting previously downloaded data is not generally possible.

The mapping includes user enabled options I'm mentioned, no?

No. I mean original-to-renamed file names mapping.

@glassez commented on GitHub (Apr 15, 2016): > Don't you also know if the feature to move on completion and/or appending .!qb is enabled? We know current settings but we don't know something about the past. If the previous settings (before reinstalling OS, changing PC, etc.) do not match with the current, detecting previously downloaded data is not generally possible. > The mapping includes user enabled options I'm mentioned, no? No. I mean original-to-renamed file names mapping.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 15, 2016):

We know current settings but we don't know something about the past. If the previous settings (before reinstalling OS, changing PC, etc.) do not match with the current, detecting previously downloaded data is not generally possible.

I think there is a misunderstanding - this is not what I'm asking for. What I am asking for is to detect files according to current settings, not guessing what the user might have set in the past.

No. I mean original-to-renamed file names mapping.

But you have to know if the user has enabled moving on completion or appending .!qb to be able to act accordingly, somehow?

@Soukyuu commented on GitHub (Apr 15, 2016): > We know current settings but we don't know something about the past. If the previous settings (before reinstalling OS, changing PC, etc.) do not match with the current, detecting previously downloaded data is not generally possible. I think there is a misunderstanding - this is not what I'm asking for. What I am asking for is to detect files according to _current settings_, not guessing what the user might have set in the past. > No. I mean original-to-renamed file names mapping. But you have to know if the user has enabled moving on completion or appending .!qb to be able to act accordingly, somehow?

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 15, 2016):

But you have to know if the user has enabled moving on completion or appending .!qb to be able to act accordingly, somehow?

Of course we know it. But I don't attribute it to torrent information, because this is a global application settings.
I think I understand what you want. Just check out some cases, depending on your current settings?

@glassez commented on GitHub (Apr 15, 2016): > But you have to know if the user has enabled moving on completion or appending .!qb to be able to act accordingly, somehow? Of course we know it. But I don't attribute it to torrent information, because this is a global application settings. I think I understand what you want. Just check out some cases, depending on your current settings?

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 15, 2016):

Exactly. If someone has "move on completion" enabled, I expect adding new torrent to check that directory as well, but only if the user used the default directory.

If the user has .!qb appending enabled, additionally check the default directory for the same files appended with .!qb (since the completed directory won't have any files with .!qb appended)

If the user changed the default directory, then they don't expect any files to be elsewhere but the selected directory. In this case, also checking for .!qb if currently is enabled is a good idea.

And when the torrent was already loaded, force recheck should only check the directory that is currently set. Again, additionally check for .!qb files if user has the feature enabled.

Checking for .!qb variants solves the current issue that the torrent can't be rechecked until you disable .!qb appending.

@Soukyuu commented on GitHub (Apr 15, 2016): Exactly. If someone has "move on completion" enabled, I expect adding new torrent to check that directory as well, but only if the user used the default directory. If the user has .!qb appending enabled, additionally check the default directory for the same files appended with .!qb (since the completed directory won't have any files with .!qb appended) If the user changed the default directory, then they don't expect any files to be elsewhere but the selected directory. In this case, also checking for .!qb if currently is enabled is a good idea. And when the torrent was already loaded, force recheck should only check the directory that is currently set. Again, additionally check for .!qb files if user has the feature enabled. Checking for .!qb variants solves the current issue that the torrent can't be rechecked until you disable .!qb appending.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 16, 2016):

You make bad decisions because you don't understand how the app works.
We haven't "move on completion" feature but we have "save incompleted to" (i.e."temporary folder").
Add .!qB extension to incompleted files is separate option so we can have one of following cases:

No options enabled - files are saved in destination folder without additional extension.
.!qB enabled - files are saved in destination folder with .!qB extension until it's completed.
Temp folder enabled - files are saved in temp folder until torrent is completed then they are moved to destination folder
Both .!qB and temp folder enabled - files are saved in temp folder (with .!qB extension until it's completed) until torrent is completed then they are moved to destination folder

@glassez commented on GitHub (Apr 16, 2016): You make bad decisions because you don't understand how the app works. We haven't "move on completion" feature but we have "save incompleted to" (i.e."temporary folder"). Add .!qB extension to incompleted files is separate option so we can have one of following cases: 1. No options enabled - files are saved in destination folder without additional extension. 2. .!qB enabled - files are saved in destination folder with .!qB extension until it's completed. 3. Temp folder enabled - files are saved in temp folder until torrent is completed then they are moved to destination folder 4. Both .!qB and temp folder enabled - files are saved in temp folder (with .!qB extension until it's completed) until torrent is completed then they are moved to destination folder

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 16, 2016):

Then I mixed it up. It doesn't really change the logic though, the only thing that changes is that the temp directory should be checked after the rest, since more complete files should be either in the default or the user selected dir

@Soukyuu commented on GitHub (Apr 16, 2016): Then I mixed it up. It doesn't really change the logic though, the only thing that changes is that the temp directory should be checked after the rest, since more complete files should be either in the default or the user selected dir

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 17, 2016):

Okay, still need to start with something.
@Soukyuu, do you use the release builds only or are you available for testing?

@glassez commented on GitHub (Apr 17, 2016): Okay, still need to start with something. @Soukyuu, do you use the release builds only or are you available for testing?

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 17, 2016):

@glassez I am available for testing, but I get home late usually, so it might take a while for me to be able to test.

@Soukyuu commented on GitHub (Apr 17, 2016): @glassez I am available for testing, but I get home late usually, so it might take a while for me to be able to test.

deekerman commented

Author

Owner

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

My last thoughts about this...

We should always give preference to the files in the target folder (i.e. to check them first). This is necessary in order for the user to be able to start to seed their own created torrent or just start to seed some other torrent if he has its data.
We can search the incompleted files regardless of the current settings (at least in the target folder), but in any case, since such a search would entail additional costs and in most cases is not required, the user must explicitly indicate their intentions to do so (by enabling the corresponding option).

The above are related to newly added torrents only.

@glassez commented on GitHub (Apr 18, 2016): My last thoughts about this... 1. We should always give preference to the files in the target folder (i.e. to check them first). This is necessary in order for the user to be able to start to seed their own created torrent or just start to seed some other torrent if he has its data. 2. We can search the incompleted files regardless of the current settings (at least in the target folder), but in any case, since such a search would entail additional costs and in most cases is not required, the user must explicitly indicate their intentions to do so (by enabling the corresponding option). The above are related to newly added torrents only.

deekerman commented

Author

Owner

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

So as long as "append .!qb" and/or "keep incomplete in" option is active, it will look there in addition to the target dir, right? Looks like a plan to me.

@Soukyuu commented on GitHub (Apr 18, 2016): So as long as "append .!qb" and/or "keep incomplete in" option is active, it will look there in addition to the target dir, right? Looks like a plan to me.

deekerman commented

Author

Owner

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

So as long as "append .!qb" and/or "keep incomplete in" option is active, it will look there in addition to the target dir, right?

Right. But it will look there if no files was found in target dir.

@glassez commented on GitHub (Apr 18, 2016): > So as long as "append .!qb" and/or "keep incomplete in" option is active, it will look there in addition to the target dir, right? Right. But it will look there if no files was found in target dir.

deekerman commented

Author

Owner

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

Right, the priority should be the target dir. Does the "keep incomplete in" feature move individual files of a multi file torrent upon completion, or only after everything is completed? If it's the former, then you'll have to do the check per file, if it's the latter, then you can just check where the files are once per torrent

@Soukyuu commented on GitHub (Apr 18, 2016): Right, the priority should be the target dir. Does the "keep incomplete in" feature move individual files of a multi file torrent upon completion, or only after everything is completed? If it's the former, then you'll have to do the check per file, if it's the latter, then you can just check where the files are once per torrent

deekerman commented

Author

Owner

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

Does the "keep incomplete in" feature move individual files of a multi file torrent upon completion, or only after everything is completed?

The second (move all files at once).

@glassez commented on GitHub (Apr 18, 2016): > Does the "keep incomplete in" feature move individual files of a multi file torrent upon completion, or only after everything is completed? The second (move all files at once).

deekerman commented

Author

Owner

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

We should always give preference to the files in the target folder (i.e. to check them first). This is necessary in order for the user to be able to start to seed their own created torrent or just start to seed some other torrent if he has its data.

Fix for this job is #5141.
Now start thinking on the second part, because it is much more difficult.

@glassez commented on GitHub (Apr 18, 2016): > We should always give preference to the files in the target folder (i.e. to check them first). This is necessary in order for the user to be able to start to seed their own created torrent or just start to seed some other torrent if he has its data. Fix for this job is #5141. Now start thinking on the second part, because it is much more difficult.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 19, 2016):

#5141 updated. Now qBittorrent tries to find incomplete files if the complete don't exist before start initial checking.

@glassez commented on GitHub (Apr 19, 2016): #5141 updated. Now qBittorrent tries to find incomplete files if the complete don't exist before start initial checking.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 19, 2016):

As for this issue (Force recheck does nothing when .!qB is enabled):

If I try and seed a torrent by starting it from the .torrent into an empty download location, pausing it, then copying the real files into where it is currently downloading then resuming and forcing a recheck it does nothing - says checking briefly then goes back to stalled.

We can't recheck the files that are not part of the torrent (from the application point of view). When it started downloading with the "Append .!qB" option enabled, it thinks the files that have the .!qB extension belonging to the torrent (but no files with original names).

@glassez commented on GitHub (Apr 19, 2016): As for this issue (Force recheck does nothing when .!qB is enabled): > If I try and seed a torrent by starting it from the .torrent into an empty download location, pausing it, then copying the real files into where it is currently downloading then resuming and forcing a recheck it does nothing - says checking briefly then goes back to stalled. We can't recheck the files that are not part of the torrent (from the application point of view). When it started downloading with the "Append .!qB" option enabled, it thinks the files that have the .!qB extension belonging to the torrent (but no files with original names).

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 19, 2016):

If the user starts a download with qb appending enabled, it should check for complete files first, then the qb ones.

Currently, qb ignores (or even zeroes out) any files with .!qb appended.

Once the torrent is started, only expecting qb/non-qb files seems fine. The important thing is to not delete/zero out files without user's consent.

@Soukyuu commented on GitHub (Apr 19, 2016): If the user starts a download with qb appending enabled, it should check for complete files first, then the qb ones. Currently, qb ignores (or even zeroes out) any files with .!qb appended. Once the torrent is started, only expecting qb/non-qb files seems fine. The important thing is to not delete/zero out files without user's consent.

deekerman commented

Author

Owner

@Soukyuu commented on GitHub (Apr 24, 2016):

Tested git snapshot with #5141 applied, it works well, many thanks.

Minor nitpick: if even one file from a torrent is missing, and "keep incomplete torrents in" is enabled, it moves the WHOLE torrent back to the incomplete torrent dir. That could be a problem if the destination and incomplete directories are on different partitions. Wouldn't it be better to only create the incomplete files in the incomplete dir and leave completed files in the target dir if they were there already?

@Soukyuu commented on GitHub (Apr 24, 2016): Tested git snapshot with #5141 applied, it works well, many thanks. Minor nitpick: if even one file from a torrent is missing, and "keep incomplete torrents in" is enabled, it moves the WHOLE torrent back to the incomplete torrent dir. That could be a problem if the destination and incomplete directories are on different partitions. Wouldn't it be better to only create the incomplete files in the incomplete dir and leave completed files in the target dir if they were there already?

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 25, 2016):

Wouldn't it be better to only create the incomplete files in the incomplete dir and leave completed files in the target dir if they were there already?

Currently it ("keep incomplete torrents in") is per-torrent option (not per-file). And I don't think mixing is good idea here. But can we disable it completely for these torrents (as we did previously in import dialog).
In any case, it should be discussed separately. You can create Issue for it.

@glassez commented on GitHub (Apr 25, 2016): > Wouldn't it be better to only create the incomplete files in the incomplete dir and leave completed files in the target dir if they were there already? Currently it ("keep incomplete torrents in") is per-torrent option (not per-file). And I don't think mixing is good idea here. But can we disable it completely for these torrents (as we did previously in import dialog). In any case, it should be discussed separately. You can create Issue for it.

deekerman commented

Author

Owner

@Misiek304 commented on GitHub (Aug 20, 2016):

I just had the same issue. I was ready to throw my computer through the window but fortunately I found this issue thread.

@Misiek304 commented on GitHub (Aug 20, 2016): I just had the same issue. I was ready to throw my computer through the window but fortunately I found this issue thread.

deekerman commented

Author

Owner

@FedgeNo commented on GitHub (Dec 20, 2016):

I think my issue is somehow related to this but it's worse. I selected "use temp folder" and ".!qb" and "recheck torrents on completion" from the advanced page of options as well. Multi file torrents that I don't download all the files from seem to be the ones that really screw up. Rechecking 2 - 3 times, usually only after I force it to start downloading again after the first check has failed. The thing is, these are the options I want. I want to be sure the download hasn't been corrupted, I don't want them in the completed folder unless they're actually completed and I don't want them hanging around my filesystem with media extensions unless they're valid media files because sometimes I use other programs that scan around for media to add to libraries. It's a valid, simple use case for all of these options and the program seems to be really sucking at this.

@FedgeNo commented on GitHub (Dec 20, 2016): I think my issue is somehow related to this but it's worse. I selected "use temp folder" and ".!qb" and "recheck torrents on completion" from the advanced page of options as well. Multi file torrents that I don't download all the files from seem to be the ones that really screw up. Rechecking 2 - 3 times, usually only after I force it to start downloading again after the first check has failed. The thing is, these are the options I want. I want to be sure the download hasn't been corrupted, I don't want them in the completed folder unless they're actually completed and I don't want them hanging around my filesystem with media extensions unless they're valid media files because sometimes I use other programs that scan around for media to add to libraries. It's a valid, simple use case for all of these options and the program seems to be really sucking at this.

deekerman commented

Author

Owner

@FedgeNo commented on GitHub (Dec 20, 2016):

Oh I forgot to mention that after a couple of rechecks it sometimes also dumps !qb files into my completed folder.

@FedgeNo commented on GitHub (Dec 20, 2016): Oh I forgot to mention that after a couple of rechecks it sometimes also dumps !qb files into my completed folder.

deekerman commented

Author

Owner

@Musaran2 commented on GitHub (Jan 13, 2017):

sledgehammer999 :

completed folder by definition shouldn't contain any .!qB files.

Bugs in qbt have done this quite a few times, for reasons unclear.
Even then, errors in OS, hardware or user could do the same.

So the solution should be generic and cover all bases by design.

Also, I second _ FedgeNo_ about incomplete files :

They should not be in the completed folder.
They should never have their final extension.

It's not just user quibbling, some utilities or the OS may react unexpectedly or even badly to them.

Hiding the files would solve some problems, but is a whole can of worms.

@Musaran2 commented on GitHub (Jan 13, 2017): _sledgehammer999_ : > completed folder by definition shouldn't contain any .!qB files. Bugs in qbt have done this quite a few times, for reasons unclear. Even then, errors in OS, hardware or user could do the same. So the solution should be generic and cover all bases by design. Also, I second _ FedgeNo_ about incomplete files : * They should not be in the completed folder. * They should never have their final extension. It's not just user quibbling, some utilities or the OS may react unexpectedly or even badly to them. Hiding the files would solve some problems, but is a whole can of worms.

deekerman commented

Author

Owner

@FedgeNo commented on GitHub (Jan 13, 2017):

The existing set of options really does pretty much cover the bases and IMO the defaults should really be something along the lines of the settings I outlined I am using above. Attempting to hide files from users or other processes is not usually a great idea. Makes it hard to clean up after uninstall or other errors. I have still been using the program and most of the time it works for me, if not quite how I would expect.

@FedgeNo commented on GitHub (Jan 13, 2017): The existing set of options really does pretty much cover the bases and IMO the defaults should really be something along the lines of the settings I outlined I am using above. Attempting to hide files from users or other processes is not usually a great idea. Makes it hard to clean up after uninstall or other errors. I have still been using the program and most of the time it works for me, if not quite how I would expect.

deekerman commented

Author

Owner

@Hobby-boy commented on GitHub (Mar 3, 2017):

I have discovered I have this issue when force rechecking for files I've downloaded externally by other means, but matches the contents and checksums of the torrent (v3.3.10). The files in question are stuff like Ubuntu Isos, and Blizzard downloader installers.

@Hobby-boy commented on GitHub (Mar 3, 2017): I have discovered I have this issue when force rechecking for files I've downloaded externally by other means, but matches the contents and checksums of the torrent (v3.3.10). The files in question are stuff like Ubuntu Isos, and Blizzard downloader installers.

deekerman commented

Author

Owner

@bathrobehero commented on GitHub (Feb 8, 2019):

After all this time force recheck still fails to detect files. The files are there, with real name without !dB, with content, not empty files, with the right name yet after a scan it's 0%. And if I disable !dB it empties the files completely. What a joke.

@bathrobehero commented on GitHub (Feb 8, 2019): After all this time force recheck still fails to detect files. The files are there, with real name without !dB, with content, not empty files, with the right name yet after a scan it's 0%. And if I disable !dB it empties the files completely. What a joke.

deekerman commented

Author

Owner

@sandblasted commented on GitHub (Oct 19, 2019):

If the user starts a download with qb appending enabled, it should check for complete files first, then the qb ones.

This functionality is still missing. Is there anything against doing this? I am surprised nobody has tried. Maybe I should try.

@sandblasted commented on GitHub (Oct 19, 2019): > If the user starts a download with qb appending enabled, it should check for complete files first, then the qb ones. This functionality is still missing. Is there anything against doing this? I am surprised nobody has tried. Maybe I should try.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Feb 18, 2020):

@glassez IIRC, wasn't this fixed recently?

@FranciscoPombal commented on GitHub (Feb 18, 2020): @glassez IIRC, wasn't this fixed recently?

deekerman commented

Author

Owner

@glassez commented on GitHub (Feb 19, 2020):

IIRC, wasn't this fixed recently?

I'm not sure...
Really I'm not clearly understand what behavior is expected. Can someone summarize the issue with examples of use cases?

@glassez commented on GitHub (Feb 19, 2020): >IIRC, wasn't this fixed recently? I'm not sure... Really I'm not clearly understand what behavior is expected. Can someone summarize the issue with examples of use cases?

deekerman commented

Author

Owner

@gravitonas commented on GitHub (Apr 11, 2020):

IIRC, wasn't this fixed recently?

I'm not sure...
Really I'm not clearly understand what behavior is expected. Can someone summarize the issue with examples of use cases?

Still happening.

I have "Append .!qB extension to incomplete files" enabled.

I start downloading a torrent containing files 1.flac, 2.flac .... 9.flac, 10.flac.

Before qBittorrent downloads all the files, I find the completed 1.flac and 2.flac files from when I previously downloaded the torrent, and move them into the downloading directory.

So now I have:
1.flac
2.flac
3.flac.!qB
4.flac.!qB
...
9.flac.!qB
10.flac.!qB.

I tell qBittorrent to force recheck, expecting it to show 100% for 1.flac and 2.flac, since they're fully downloaded, complete files, from the same torrent in fact. qBittorrent shows 0% however.

@gravitonas commented on GitHub (Apr 11, 2020): > IIRC, wasn't this fixed recently? > > I'm not sure... > Really I'm not clearly understand what behavior is expected. Can someone summarize the issue with examples of use cases? Still happening. I have "_Append .!qB extension to incomplete files_" enabled. I start downloading a torrent containing files 1.flac, 2.flac .... 9.flac, 10.flac. Before qBittorrent downloads all the files, I find the completed 1.flac and 2.flac files from when I previously downloaded the torrent, and move them into the downloading directory. So now I have: 1.flac 2.flac 3.flac.!qB 4.flac.!qB ... 9.flac.!qB 10.flac.!qB. I tell qBittorrent to force recheck, expecting it to show 100% for 1.flac and 2.flac, since they're fully downloaded, complete files, from the same torrent in fact. qBittorrent shows 0% however.

deekerman commented

Author

Owner

@fireattack commented on GitHub (Apr 11, 2020):

Can also confirm this bug still exists.

I personally think this should be relatively straightforward to fix (just check both files with .!qb and without in any cases, regardless if this option is used).

@fireattack commented on GitHub (Apr 11, 2020): Can also confirm this bug still exists. I personally think this should be relatively straightforward to fix (just check both files with `.!qb` and without in any cases, regardless if this option is used).

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 11, 2020):

qBittorrent just checks the files it currently handles. It seems that users expect something more...
Can anyone provide a clear (detailed and, if possible, formalized) suggestion on how it is supposed to work?

@glassez commented on GitHub (Apr 11, 2020): qBittorrent just checks the files it currently handles. It seems that users expect something more... Can anyone provide a clear (detailed and, if possible, formalized) suggestion on how it is supposed to work?

deekerman commented

Author

Owner

@gravitonas commented on GitHub (Apr 11, 2020):

I think we're asking for qBittorrent to be able to handle files that are manually placed into the download directory. As an example:

1.) You start a torrent downloading, but you pause it before it's downloaded anything
2.) You move A.mp3 (an already complete, downloaded file) into the folder that qBitorrent has created e.g. *c:\Download\MusicTorrent*
3.) You click "Force recheck"
4.) If qBittorrent is downloading A.mp3, B.mp3 and C.mp3, I would expect it to search the MusicTorrent directory for A.mp3, B.mp3 and C.mp3, as well as A.mp3.!qB, B.mp3.!qB and C.mp3.!qB.
5.) qBittorrent discovers that the A.mp3 file in the MusicTorrent directory, is what it was already going to download.
6.) It marks A.mp3 as 100% downloaded (if it was e.g. A.mp3.!qB, and was 90% downloaded, it would mark it was 90% downloaded and continue downloading).

@gravitonas commented on GitHub (Apr 11, 2020): I think we're asking for qBittorrent to be able to handle files that are manually placed into the download directory. As an example: 1.) You start a torrent downloading, but you pause it before it's downloaded anything 2.) You move A.mp3 (an already complete, downloaded file) into the folder that qBitorrent has created e.g. **c:\Download\MusicTorrent\** 3.) You click "_Force recheck_" 4.) If qBittorrent is downloading A.mp3, B.mp3 and C.mp3, I would expect it to search the **MusicTorrent** directory for A.mp3, B.mp3 and C.mp3, as well as A.mp3.!qB, B.mp3.!qB and C.mp3.!qB. 5.) qBittorrent discovers that the A.mp3 file in the **MusicTorrent** directory, is what it was already going to download. 6.) It marks A.mp3 as 100% downloaded (if it was e.g. A.mp3.!qB, and was 90% downloaded, it would mark it was 90% downloaded and continue downloading).

deekerman commented

Author

Owner

@fireattack commented on GitHub (Apr 11, 2020):

Pretty much what @gravitonas said.

The implication here is that users want to use "recheck" to re-incorporate the (existing) files into this current task, to:

seeding same files that they got from other way (could simply be from the old task that have now been deleted, like mentioned above).
fix broken files
resume unfinished files for an task (again, could have been deleted)

This is pretty much how most of BitTorrent software I've used works. It even kinda works fine with QBit if you don't use .!qB.

@fireattack commented on GitHub (Apr 11, 2020): Pretty much what @gravitonas said. The implication here is that users want to use "recheck" to re-incorporate the (existing) files into this current task, to: * seeding same files that they got from other way (could simply be from the old task that have now been deleted, like mentioned above). * fix broken files * resume unfinished files for an task (again, could have been deleted) This is pretty much how most of BitTorrent software I've used works. It even kinda works fine with QBit if you don't use `.!qB`.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 11, 2020):

Even without paying attention to the possible difficulties in its implementation, there is still room for conflicts.
No one can guarantee that there will not be both files simultaneously. What should I do in this case? Just blindly trust files without ".!qb" extension?

@glassez commented on GitHub (Apr 11, 2020): Even without paying attention to the possible difficulties in its implementation, there is still room for conflicts. No one can guarantee that there will not be both files simultaneously. What should I do in this case? Just blindly trust files without ".!qb" extension?

deekerman commented

Author

Owner

@fireattack commented on GitHub (Apr 11, 2020):

That's one way to do that. Or blindly use .!qb instead since it's "guaranteed" generated by qb.

Or we can hash both and compare the "completeness" first.

@fireattack commented on GitHub (Apr 11, 2020): That's one way to do that. Or blindly use .!qb instead since it's "guaranteed" generated by qb. Or we can hash both and compare the "completeness" first.

deekerman commented

Author

Owner

@gravitonas commented on GitHub (Apr 11, 2020):

In case of conflict, my view would be (in order of preference):
1.) Combine both files into one;
2.) Use the more "complete" version;
3.) Ask the user which one you'd like to use/keep, showing the respective "completeness"; or
4.) Just use whatever is currently being used by qBitorrent (either .!qb if that's selected or the normal file extension if not)

@gravitonas commented on GitHub (Apr 11, 2020): In case of conflict, my view would be (in order of preference): 1.) Combine both files into one; 2.) Use the more "complete" version; 3.) Ask the user which one you'd like to use/keep, showing the respective "completeness"; or 4.) Just use whatever is currently being used by qBitorrent (either .!qb if that's selected or the normal file extension if not)

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 11, 2020):

Wait, wait...
I don't need to list all the possible and impossible options. It doesn't make sense.

Or blindly use .!qb instead since it's "guaranteed" generated by qb.

Why do you even suggest it? qBittorrent does it currently if "Append !qb extension" is enabled.

Just use whatever is currently being used by qBitorrent

The same question as above. It's current behavior. And you dislike it. Otherwise, what are we trying to fix here?

Combine both files into one

How do you really suppose to make it?

Ask the user which one you'd like to use/keep, showing the respective "completeness"

or

Use the more "complete" version

These options are more or less meaningful. I don't think it's that easy to implement, though. It doesn't look like libtorrent (our backend) allows to check files that don't belong to the torrent. If you still don't understand, the torrent only manages one version of the file. When you manually put another one into torrent folder, the torrent doesn't know anything about it.
I'm not even sure that libtorrent allows you to check any specific files alone.

I want to know what behavior should be from the perspective of a valid use case. Trying to create protection from a fool is a thankless task. The users should still be responsible for their actions.

@glassez commented on GitHub (Apr 11, 2020): Wait, wait... I don't need to list all the possible and impossible options. It doesn't make sense. >Or blindly use .!qb instead since it's "guaranteed" generated by qb. Why do you even suggest it? qBittorrent does it currently if "Append !qb extension" is enabled. >Just use whatever is currently being used by qBitorrent The same question as above. It's current behavior. And you dislike it. Otherwise, what are we trying to fix here? >Combine both files into one How do you really suppose to make it? >Ask the user which one you'd like to use/keep, showing the respective "completeness" or >Use the more "complete" version These options are more or less meaningful. I don't think it's that easy to implement, though. It doesn't look like libtorrent (our backend) allows to check files that don't belong to the torrent. If you still don't understand, the torrent only manages one version of the file. When you manually put another one into torrent folder, the torrent doesn't know anything about it. I'm not even sure that libtorrent allows you to check any specific files alone. I want to know what behavior should be from the perspective of a valid use case. Trying to create protection from a fool is a thankless task. The users should still be responsible for their actions.

deekerman commented

Author

Owner

@fireattack commented on GitHub (Apr 11, 2020):

You're really confusing me now.

Or blindly use .!qb instead since it's "guaranteed" generated by qb.

Why do you even suggest it? qBittorrent does it currently if "Append !qb extension" is enabled.

You were asking what if "[there are] both files simultaneously", and I suggest we can blindly use the .!qb one. in this case. Yes, this is the current behavior of qBittorrent.

What this issue is about is when users replace unfinished .!qb files with completed ones (so no suffix) and click "re-check", what should qBittorrent do. There are no "both files simultaneously".

To make it clear, what we want (as I understand):

if there is ONE file that matches the filename (with or without .!qB), qB should check that file. Currently qB doesn't check file.mp3 placed by user externally if .!qB option is enabled.
If there are BOTH file.mp3 and file.mp3.!qB, like you asked, you can just stick with any of them, use the one qB was using, compare the two and make a "smart" decision, I have no preference. Again, as you said, if we "blindly use .!qB file", yes it would be the current behavior, because this is not where we have issue to begin with. "Keep the current behavior" would be the easiest to implement, though.

@fireattack commented on GitHub (Apr 11, 2020): You're really confusing me now. > > Or blindly use .!qb instead since it's "guaranteed" generated by qb. > Why do you even suggest it? qBittorrent does it currently if "Append !qb extension" is enabled. You were asking what if "[there are] both files simultaneously", and I suggest we can blindly use the .!qb one. *in this case*. Yes, this is the current behavior of qBittorrent. What this issue is about is when users _replace_ unfinished .!qb files with completed ones (so no suffix) and click "re-check", what should qBittorrent do. There are no "both files simultaneously". To make it clear, what we want (as I understand): 1. if there is ONE file that matches the filename (with or without .!qB), qB should check that file. Currently qB doesn't check `file.mp3` placed by user externally if `.!qB` option is enabled. 2. If there are BOTH `file.mp3` and `file.mp3.!qB`, like you asked, you can just stick with any of them, use the one qB was using, compare the two and make a "smart" decision, I have no preference. Again, as you said, if we "blindly use .!qB file", yes it would be the current behavior, because this is not where we have issue to begin with. "Keep the current behavior" would be the easiest to implement, though.

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 11, 2020):

What this issue is about is when users replace unfinished .!qb files with completed ones (so no suffix)

But aren't there more lazy users who won't consider it a concern to delete existing files, but will just put others next to them (so qBittorrent will keep use existing ones instead)? So we will get the same problem again: "Force recheck does nothing when .!qB is enabled".

IMO, the presence of such dubious features (like "append .!qb extension") makes the app unreliable...

@glassez commented on GitHub (Apr 11, 2020): >What this issue is about is when users replace unfinished .!qb files with completed ones (so no suffix) But aren't there more lazy users who won't consider it a concern to delete existing files, but will just put others next to them (so qBittorrent will keep use existing ones instead)? So we will get the same problem again: "Force recheck does nothing when .!qB is enabled". IMO, the presence of such dubious features (like "append .!qb extension") makes the app unreliable...

deekerman commented

Author

Owner

@gravitonas commented on GitHub (Apr 11, 2020):

Just use whatever is currently being used by qBitorrent

The same question as above. It's current behavior. And you dislike it. Otherwise, what are we trying to fix here?

I meant, in the case of a conflict, where there are two files and qB doesn't know which to "import", it should use whatever the current setting is in qB (with .qB or without). I dislike the current behaviour.

Ask the user which one you'd like to use/keep, showing the respective "completeness"

or

Use the more "complete" version

These options are more or less meaningful. I don't think it's that easy to implement, though. It doesn't look like libtorrent (our backend) allows to check files that don't belong to the torrent. If you still don't understand, the torrent only manages one version of the file. When you manually put another one into torrent folder, the torrent doesn't know anything about it.

I'm not an expert in qBittorrent/libtorrent, and this would only work for complete files, but I would do it this way; get a list of the filenames in the torrent and their expected file size, get a list of the filenames already in the directory and their actual file size. If any of them match, "tell" libtorrent that the "one version" of the file is the complete one.

I want to know what behavior should be from the perspective of a valid use case. Trying to create protection from a fool is a thankless task. The users should still be responsible for their actions.

I don't understand what you're saying. I think this is a valid use case; importing finished files into a partially-finished torrent makes sense. You can fix torrents which are incomplete, you can save downloading bandwidth, etc.. Other programmes manage to do this and it is a useful feature, otherwise there would not be this issue on GitHub.

@gravitonas commented on GitHub (Apr 11, 2020): > Just use whatever is currently being used by qBitorrent > > The same question as above. It's current behavior. And you dislike it. Otherwise, what are we trying to fix here? I meant, in the case of a conflict, where there are two files and qB doesn't know which to "import", it should use whatever the current setting is in qB (with .qB or without). I dislike the current behaviour. > Ask the user which one you'd like to use/keep, showing the respective "completeness" > > or > > Use the more "complete" version > > These options are more or less meaningful. I don't think it's that easy to implement, though. It doesn't look like libtorrent (our backend) allows to check files that don't belong to the torrent. If you still don't understand, the torrent only manages one version of the file. When you manually put another one into torrent folder, the torrent doesn't know anything about it. I'm not an expert in qBittorrent/libtorrent, and this would only work for complete files, but I would do it this way; get a list of the filenames in the torrent and their expected file size, get a list of the filenames already in the directory and their actual file size. If any of them match, "tell" libtorrent that the "one version" of the file is the complete one. > I want to know what behavior should be from the perspective of a valid use case. Trying to create protection from a fool is a thankless task. The users should still be responsible for their actions. I don't understand what you're saying. I think this is a valid use case; importing finished files into a partially-finished torrent makes sense. You can fix torrents which are incomplete, you can save downloading bandwidth, etc.. Other programmes manage to do this and it is a useful feature, otherwise there would not be this issue on GitHub.

deekerman commented

Author

Owner

@gravitonas commented on GitHub (Apr 11, 2020):

What this issue is about is when users replace unfinished .!qb files with completed ones (so no suffix)

But aren't there more lazy users who won't consider it a concern to delete existing files, but will just put others next to them (so qBittorrent will keep use existing ones instead)? So we will get the same problem again: "Force recheck does nothing when .!qB is enabled".

I don't understand. If somebody puts finished files, next to unfinished files, they would click "Force recheck" to force qB to see the finished files, and qB wouldn't download the unfinished files. If you're going to the trouble of putting finished files in a torrent, you're doing it for a reason, and you will click "Force recheck".

@gravitonas commented on GitHub (Apr 11, 2020): > What this issue is about is when users replace unfinished .!qb files with completed ones (so no suffix) > > But aren't there more lazy users who won't consider it a concern to delete existing files, but will just put others next to them (so qBittorrent will keep use existing ones instead)? So we will get the same problem again: "Force recheck does nothing when .!qB is enabled". I don't understand. If somebody puts finished files, next to unfinished files, they would click "_Force recheck_" to force qB to see the finished files, and qB wouldn't download the unfinished files. If you're going to the trouble of putting finished files in a torrent, you're doing it for a reason, and you will click "_Force recheck_".

deekerman commented

Author

Owner

@glassez commented on GitHub (Apr 11, 2020):

get a list of the filenames in the torrent and their expected file size, get a list of the filenames already in the directory and their actual file size. If any of them match, "tell" libtorrent that the "one version" of the file is the complete one.

It won't work generally. Since bittorrent transfers pieces in non sequential order the file may be the correct size, but it may be incomplete in the same time.

I think this is a valid use case; importing finished files into a partially-finished torrent makes sense.

Yes. And I am inclined to conclude that we should consider other cases as invalid and not take them into account (I mean the case when user provided files are incomplete).
Given the above, it should behave as follows (as I suggested before):

Just blindly trust files without ".!qb" extension

I.e. when "force recheck" is invocked qBittorent should consider the file version without ".!qb" extension to be preferable and use it even if it has processed another one before. And even if it turns out later that it is incomplete.

@glassez commented on GitHub (Apr 11, 2020): >get a list of the filenames in the torrent and their expected file size, get a list of the filenames already in the directory and their actual file size. If any of them match, "tell" libtorrent that the "one version" of the file is the complete one. It won't work generally. Since bittorrent transfers pieces in non sequential order the file may be the correct size, but it may be incomplete in the same time. >I think this is a valid use case; importing finished files into a partially-finished torrent makes sense. Yes. And I am inclined to conclude that we should consider other cases as invalid and not take them into account (I mean the case when user provided files are incomplete). Given the above, it should behave as follows (as I suggested before): >Just blindly trust files without ".!qb" extension I.e. when "force recheck" is invocked qBittorent should consider the file version without ".!qb" extension to be preferable and use it even if it has processed another one before. And even if it turns out later that it is incomplete.

deekerman commented

Author

Owner

@gravitonas commented on GitHub (Apr 11, 2020):

It won't work generally. Since bittorrent transfers pieces in non sequential order the file may be the correct size, but it may be incomplete in the same time.

Ah good point. And I'm guessing for some reason a hash of the file "found" by qB can't be compared to the one that's expected from the torrent.

Yes. And I am inclined to conclude that we should consider other cases as invalid and not take them into account (I mean the case when user provided files are incomplete).

OK well even accepting completed files would be very helpful.

I.e. when "force recheck" is invocked qBittorent should consider the file version without ".!qb" extension to be preferable and use it even if it has processed another one before. And even if it turns out later that it is incomplete.

Sounds right; the user is telling qB that the file is complete, qB should trust that (since there doesn't seem to be a simple way of checking).

Thanks for your efforts!

@gravitonas commented on GitHub (Apr 11, 2020): > It won't work generally. Since bittorrent transfers pieces in non sequential order the file may be the correct size, but it may be incomplete in the same time. Ah good point. And I'm guessing for some reason a hash of the file "found" by qB can't be compared to the one that's expected from the torrent. > Yes. And I am inclined to conclude that we should consider other cases as invalid and not take them into account (I mean the case when user provided files are incomplete). OK well even accepting completed files would be very helpful. > I.e. when "force recheck" is invocked qBittorent should consider the file version without ".!qb" extension to be preferable and use it even if it has processed another one before. And even if it turns out later that it is incomplete. Sounds right; the user is telling qB that the file is complete, qB should trust that (since there doesn't seem to be a simple way of checking). Thanks for your efforts!

deekerman commented

Author

Owner

@fireattack commented on GitHub (Apr 11, 2020):

What this issue is about is when users replace unfinished .!qb files with completed ones (so no suffix)

But aren't there more lazy users who won't consider it a concern to delete existing files, but will just put others next to them (so qBittorrent will keep use existing ones instead)? So we will get the same problem again: "Force recheck does nothing when .!qB is enabled".

IMO, the presence of such dubious features (like "append .!qb extension") makes the app unreliable...

Fair enough. I agree we can choose the files without suffix in such case (like i said, I don't really have a preference in these cases). Thanks for your insight.

@fireattack commented on GitHub (Apr 11, 2020): > > What this issue is about is when users replace unfinished .!qb files with completed ones (so no suffix) > > But aren't there more lazy users who won't consider it a concern to delete existing files, but will just put others next to them (so qBittorrent will keep use existing ones instead)? So we will get the same problem again: "Force recheck does nothing when .!qB is enabled". > > IMO, the presence of such dubious features (like "append .!qb extension") makes the app unreliable... Fair enough. I agree we can choose the files without suffix in such case (like i said, I don't really have a preference in these cases). Thanks for your insight.

deekerman commented

Author

Owner

@xavier2k6 commented on GitHub (Mar 2, 2021):

@glassez Is this still relevant for you, can I close/lock?

@xavier2k6 commented on GitHub (Mar 2, 2021): @glassez Is this still relevant for you, can I close/lock?

deekerman commented

Author

Owner

@glassez commented on GitHub (Mar 2, 2021):

@glassez Is this still relevant for you, can I close/lock?

This issue should be fixed now unless there are some drawbacks unnoticed. So it would be better to close it.

@glassez commented on GitHub (Mar 2, 2021): > @glassez Is this still relevant for you, can I close/lock? This issue should be fixed now unless there are some drawbacks unnoticed. So it would be better to close it.

deekerman commented