Qbittorrent: Force recheck does nothing when .!qB is enabled

[azcohen]

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.

I would expect it to verify the files and then start seeding..

(attempting this method as importing existing torrent also fails)

Tested with 3.0.6 and the current source from the depository (2012/10/16) on Ubuntu 11.04

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[backie]

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.

[surfernsk]

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

[slacka]

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.

[surfernsk]

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

[slacka]

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.

[nivensd]

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]

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).

[gandalftools]

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.

[sledgehammer999]

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

[shortys-crew]

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.

[sledgehammer999]

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

[shortys-crew]

@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.

[Soukyuu]

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]

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

[sledgehammer999]

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

[Soukyuu]

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

[sledgehammer999]

@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.

[Soukyuu]

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

[xeddmc]

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]

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

[chrishirst]

Just my OS X...

Running what client version?

[sledgehammer999]

@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.

[Soukyuu]

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".

[cncDAni2]

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.

[re-l124c41plus]

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.

[Soukyuu]

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]

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.

[re-l124c41plus]

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.

[Soukyuu]

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

[sledgehammer999]

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.

[re-l124c41plus]

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.

[Soukyuu]

@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.

[htnmtoi]

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

[sledgehammer999]

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?

[efotinis]

@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.

[bigretromike]

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.

[Soukyuu]

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]

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

[sledgehammer999]

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?

[shebang4]

Situation here on OSX with v3.3.3:

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

[slacka]

@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.

[Soukyuu]

@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 [email protected], 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
3. Adding torrent immediately renames the file with .!qB suffix
4. 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

[glassez]

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.

[zeule]

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).

[Soukyuu]

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]

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]

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.

[glassez]

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".

[Soukyuu]

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

On Vladimir Golovnev [email protected], 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

[Soukyuu]

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 [email protected], 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

[glassez]

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.

[Soukyuu]

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

[sledgehammer999]

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

[Soukyuu]

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.

[glassez]

@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]

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.

[Soukyuu]

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.

[glassez]

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.

1. Just move all torrents using qBittorrent.

[glassez]

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

[Soukyuu]

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.

[glassez]

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

[zeule]

@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.

[glassez]

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

[Soukyuu]

@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.

[glassez]

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]

@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).

[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.

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)

[glassez]

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.

[Soukyuu]

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?

[glassez]

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?

[Soukyuu]

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.

[glassez]

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

[Soukyuu]

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

[glassez]

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

[Soukyuu]

@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.

[glassez]

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.

[Soukyuu]

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.

[glassez]

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.

[Soukyuu]

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

[glassez]

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]

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]

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

[glassez]

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).

[Soukyuu]

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]

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?

[glassez]

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.

[Misiek304]

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

[FedgeNo]

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]

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

[Musaran2]

_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.

[FedgeNo]

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.

[Hobby-boy]

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.

[bathrobehero]

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.

[sandblasted]

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.

[FranciscoPombal]

@glassez IIRC, wasn't this fixed recently?

[glassez]

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?

[gravitonas]

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.

[fireattack]

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).

[glassez]

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?

[gravitonas]

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).

[fireattack]

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.

[glassez]

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?

[fireattack]

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.

[gravitonas]

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)

[glassez]

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.

[fireattack]

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.

[glassez]

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...

[gravitonas]

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]

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_".

[glassez]

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.

[gravitonas]

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!

[fireattack]

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.