Again 99.9% task completion issue (yes, I have read FAQ)

[twDDERSS]

Dear Sirs/Madames,

I have BitComet 1.32 64-big, and I have read http://wiki.bitcomet.com/known_client_issues_and_incompatibilities#why_do_some_bt_tasks_progress_revert_to_999_from_100_when_their_download_is_finished

Manual hash-check only gets file to 99.9%. File integrity is proven, CRC is fine, yet nothing what I am doing corrects this. Multiple restarts of the software, the task, manual hash checks -- nothing.

I absolutely can not believe that BC software is actually incapable of understanding that two plus two will make four. The software just have to check how many bytes there in the downloaded file, and compare the file size with what is said in the torrent file.

If those sizes match, then is 100% and not a bit less than that. Yes, even with metadata being lost. Hash check should not care about it at all, and yet it wierdly thinks that the metadata all of sudden has to be part of the downloaded file and hence even if it is actually fully loaded it can only count 99.9% if the metadata was somehow lost.

Can I ask developers to correct this behaviour? The software itself is great, and this is basically the only thing that I can complain of. Thank you in advance.

[kluelos]

The most usual cause of this is that the torrent-maker included a transitory file. These are, for Windows, files that are constantly changing, files such as desktop.ini or thumbnails.db from most directories. Because they are constantly changing, the hashes never match. If you are making a torrent, never include these files. Most clients will let you exclude files from a directory, so if these are present, exclude them.

You don't need these files. Nobody does. Look at the files contained in the torrent. If they're all complete except for one or both of these files, you can simply ignore the omission and use the other files in the torrent. Of course, this does mean your seeding will not complete in the orthodox manner, but there's nothing you can do about that. A note to the uploader would be in order, though.

Many, many systems have been developed and used over the years to verify accurate file transmission. Filesize was discarded long ago, because it's too easy to insert a virus yet still make the size come out correctly. Checksums and CRC's are better, but still not perfect. Bittorrent's hash-check is very close. It's not going to change. Any client that attempts to do so will find itself isolated, unable to exchange with any of the other clients out there. Since there is no central organization, no control, and since the protocol has been given to the public domain, it's not likely that everyone will agree on even the simplest of changes -- as, indeed, they have not.

[The UnUsual Suspect]

Another popular cause is your antivirus. If you're downloading a torrent that contains something the anti virus considers a threat, be it a virus, a hack tool, keygen, activator or whatever, as soon as that file completes, your anti virus recognizes it and quarentees it, then it fails hash check because it's not there so bitcomet has to redownload the piece, and again the anti virus disables it.

There are also some problems related to routers with gaming mode enabled when a piece of data just happens to have a string of bits that match your WAN IP address, the router changes it to match your internal IP address, then the piece is rejected because it has changed, and an endless cycle of repeat downloading. In this case you can turn off gaming mode, get a better router, or bypass the router until the download is finished.

Also, your complaint is about bittorrent protocol, not bitcomet, so you're making it in the wrong forum. The fault in these cases is either yours, or the person who made the torrent. BitComet is only doing what you tell it to using the protocols it must follow. It's not a bug.

[twDDERSS]

In my case it is not "db" or "ini" files. The file that I have is usual "mkv", and it is fully downloaded. However, since "bc!" file for it was lost and can not be recovered (not because of anti-virus software), the hash check somehow always returns 99.9%. The second file in the task was "sfv", but it was never checked for download, so it can not be included in hash check calculation.

Thus is problem indeed seems to with the fact that BC for hash check suppose that the file has metadata that is usually kept in "bc!" file, so when it unexpectedly (for itself) sees pure file with no metadata, it just can not count more than 99.9%.

The question is, what can be done specifically to get this issue go away, if I do not want to kill the downloaded file and start over (the torrent is old, it may never really finish downloading again, if I would start over)?

Is there magical command "think this file is 100% loaded, because it is!" or some less magical equivalent of it?

Edited July 13, 2012 by twDDERSS (see edit history)

[The UnUsual Suspect]

If you had the .sfv file you could use it to confirm if the file was 100% or not. Disabling the download of the .sfv is an amateur mistake. You can uncheck it, but it will still be downloaded, and MUST be downloaded in order to get you the complete mkv file. By unchecking it, you're forcing bitcomet to download it and hide it in a system file to be used for construction the bittorrent piece it came in. This file is extremely small and won't waste any disc space, so there is no valid reason to disable it.

For example, a 100mb torrent that contains movie.avi 99.99mb and move.sfv 0.01mb contains about 400 bittorrent pieces of 256kb each. In order to get the complete movie.avi you'll need to download all 400 pieces, the last of the pieces will contain part of movie.avi and the complete movie.sfv, then if you had the sfv file disabled, bitcomet would have to hold on to it for seeding until you delete the task, otherwise the file would only hash check to 99% complete because the last piece would be incomplete.

The solution to your problem is just to restart the download and let the last piece of data finish downloading, but before you do this change the settings so it will save the .sfv file.

[kluelos]

If you simply cannot get the .sfv file, and you're sure this is all that is missing, then you can simply rename the .mkv.bc! file back to .mkv and proceed to use it, watch it, retorrent it or whatever. This is taking a lot for granted. If you can rebuild the .mkv file, that would be better. (If it were, say, an .avi file I would rebuild it with VirtualDub, just for example. Maybe there's a similar tool for matroska.)

If you want to recover/recreate the original torrent, for whatever reason, I'm afraid you're out of luck. You will have to have all of the original files. In this case I have to agree with TUUS, this is a rookie mistake and not a problem for BitComet to fix.

[twDDERSS]

That is strange, because I have a number of tasks where I have only some files from them checked, and those tasks always report 100% on completion. Other files in the task never a hindrance for BitComet to calculate 100% hash for the checked and downloaded files.

Anyway, I checked ".sfv" files, but the torrent is old, and I am not sure that they will load.

[The UnUsual Suspect]

If there are peers with 100% of the pieces, it will finish, if there are not, then it will finish if bitcomet can find the data elsewhere. This could be what happened in your case. Take this example...

You and your friend start the same "dead" torrent for movie.mkv and movie.sfv. Your friend is using a different client. His sits at 0.0%, but yours starts to download because bitcomet was able to find the movie.mkv file elsewhere, but was unable to find movie.sfv. Pretty soon your movie is complete because of an ability that only bitcomet has, but since you can't get .sfv file, regardless of the fact that you diddn't select it, the torrent cannot be hashed out to 100% so you can only seed 99.9% of it.

In this case just rename the file to remove the bitcomet extension and you're done, while your friend will never get the complete file.

ps. Bitcomet has the ability to source the file from http/ftp, emule, or even different torrents with some or all of the same content.

[greywizard]

If the mkv file was downloaded from BitTorrent sources and not from elsewhere (as in the the case TUUS describes above) and you unchecked the SFV file then you should have a taskname.piece_part.bc! file in the download folder, which holds the last piece which is shared by both the mkv file and the sfv file (as TUUS explained in a previous post). That's the only way it can finish the hash-check since it needs the whole piece in order to perform the hash-check on the downloaded data and you disabled downloading the last file. So it has to create this temporary file which holds pieces that overlap on two files, in order to be able to perform hash-check on the downloaded data.

But if taskname.piece_part.bc! is missing then hash-check won't be able to finish. Your confusion arises from not understanding how the hash-checking process works.

It has nothing to do with files size (and that's a good thing) but with a complex mathematical function which performs a hashing operation (SHA1 to be more precise) on each downloaded piece and compares the value it obtains with the one written in the .torrent file. That's a very reliable way of verifying that the data was not altered or corrupted since even if a single bit is changed in a piece the hash value for that piece would become entirely different.

I'm not sure if BC should re-create this taskname.piece_part.bc! file upon torrent/client restart if it's missing, and it's not doing it because of a bug or if that's the way the creators intended it to work (i.e. once you delete that file it won't be re-created automatically).

Anyway, you should be able to see in the Piece Map tab which pieces are missing from your torrent. If it's just the last piece, then you would be able to watch it without problems.