Many users have experienced the data loss problem, their downloading progress has dropped to 0%, and the downloaded file became unavailable.
The development team is working on this problem and hoping to find out the solution ASAP. We are sorry for any inconvenience caused. If you are also experiencing this issue, please provide the following information to help us solving the problem.
Your operating system
BitComet version
When did it happen
Did data loss happen to all the tasks in tasklist or some of them?
How did the problem happen? Whatās the size of the task? And the progress before data loss?
Were there more than 50 files contained in the task?
If you donāt mind, please show the log and magnet link of the torrent.
Since most error occurred after hash-check, please DO NOT hash-check your other tasks, just in case the data will be dropped. If you are using version 1.23, 1.24, or 1.25, we also suggest you to switch to version 1.26 or 1.22, in order to prevent auto hash-check when starting BitComet. If youd like to upgrade to v1.26, please go to options ā Advanced, change the value of bittorrent.hash_check_if_file_changed to false.
Lossed data between 16th feb and 19th of feb completed 4th avi file an avi on 16th of feb played good completed 5th avi on 19th feb would not load said 100% did a hash check dumped from 82.6 complete on all files yo 11.5% with first 5 avi files which were complete reading 0%
Data loss happened to all files 13 jpg and 13 avi incoplete files will not load preview using mpc star appear to be corrupted
manage to restore 4 completed avi files by restoring previous version from win 7 can probably do the same with jpgās incomplete files with bc extension appear corrupted but have a % beside them
Iām beginning to see a pattern here. It seems most (if not all) of these reports are from people who are previewing/viewing video through bitcomet interface. I personally never do this. I wait until all my video downloads are complete and then open the files in the player I want to use, or let windows open them in my default.
Could there be something in the attempt to play the files that causing damage?
I think the user from this post reports a little more specific data, which may help narrow this down, namely that in his case the issue seems to appear only when he actually disabled some of the files in the task.
Data loss between 18th Feb to 20th Febā11 after 1 completed bluray rip file. I tried to open the completed file but thereās nothing & also same thing happened when i try to check the preview of all my uncompleted bluray rip &
mp3 files. My size task is around 1.20gb - 2.50gb per file & when data loss happened, thereās 6 files downloading & all were affected.
There were 25 files contained in the task but only 6 files were active during the incident.
I have deleted all the unfinished tasks, re-install bitcomet 1.26 & try to re-download the files which Iāve deleted from the previous tasks.
Is it advisable for me to carry on with my downloading or wait until the problem solve before i can use bitcomet again??!!
p/s. how to show the log and magnet link of the torrent ?!!
2- BitComet v1.25 and v1.26 (I upgraded and it happened again)
3- I believe the first time was 15 February (I had it happen three times)
4- Every file in two tasks (the first time, and in three the second and third time) went to about 1% (it seems as though the bit that consists of the very beginning and the very end of each file is all that remains), however every other smaller task I was running continued to work fine.
5- It happened when I had a crash of BitComet. When I restarted two of my files reported at 100%. I knew this to be an error because there were at about 60% of 17.65GB and 80% of 59.90GB an hour earlier. So I ran a manual hashcheck and it said all the files were at about 1%. The third file corrupted the second day (no hashcheck was run during of after this corruption) that file is reporting at 54.3% of 37.40GB but I cannot view completed files or preview partial files.
6- The first task has 26 files, the second has 175 files in 7 folders, the third 111 files in 5 folders.
I had another large download that I was running that did not corrupt. It was either a lucky task or it has something to do with disabling files, as the first three had files disabled and this one did not.
I believe, until somebody tells me otherwise, that this is the crucial point. Size alone shouldnāt do this unless itās walking into an OS boundary or something. But itās best to ask, and see if anybody was NOT doing this when it happened. (Taking user reports with a grain of salt, of course.)
I have been testing my theory on disabling files. When I disabled all but one season of a show on one task and downloaded for a while I was able to preview some episodes. After turning off my computer for the night and restarting it, I found I could no longer preview those episodes I could before. Running a hash check confirmed that those files had gone back down to about 1% each. I then tried downloading the same task with nothing disabled. After several days I was still able to preview the partial files. I ran a hash check anyways and nothing changed and nothing corrupted. All the files were at the same percentage before and after the hash check.
I have no idea about the programming so this is just a random thought: Iāve noticed that in past versions of Bit-Comet when file āAā was disabled, you downloaded the one next to it, file āBā, then enabled file āAā, and completed it. If you ran a hash check once both files were complete, the ābitā that is shared as the end of file āAā and the beginning of file āBā would occasionally be found missing with in the hash check. In more recent versions of Bit-Comet, this no longer happens. Since in this current problem, the files seem to revert to just that shared ābitā in question, I thought of this change. Again, this is just a shot in the dark, but maybe whatever was changed in the ādisabling filesā code concerning the beginning and end of files may be responsible for our current problem.
maybe whatever was changed in the ādisabling filesā code concerning the beginning and end of files may be responsible for our current problem.
Thats one theory I was thinking too. Most users donāt realize that bittorrent protocol doesnāt download the files and they exist, it breaks the files into equal size pieces then after being downloaded they are reassembled into the initial file structure. Some users have decided its more efficient to download one file at a time, which is the most inefficient way to download a torrent. It makes you a very unattractive trading partner, because you will reject most pieces offered to you, and only request very specific pieces that may be extremely rare at the time you wanted them. Since users were misusing this feature, it caused bitcomet to change the way it handles disabled files. Older version ācorrectlyā (in my opinion) would delete a disabled file, but after getting reports from users that didnāt understand why a file that was disabled was also deleted, so bitcomet was changed and now leaves the previously downloaded but deselected pieces there. I think a better solution would have been to put a warning that disabling a file will delete it would have been far better. For one thing, if a file is disabled, it will no longer be shared, so doing this will make you a less attractive peer, and harm the entire swarm.
I canāt say if this is related to the dataloss problem or not, but I think I would look for a more simplified way to handle selection of files, perhaps making it impossible to deselect a file that has completed download. What would really be the best solution would be if users would simply just download torrents as they were meant to be downloaded, and not try to change things because it usually only harms themselves and any peers they are trading with.
Lucy, perhaps we should ask for someone who can reproduce this problem to test either a new alpha or beta version that development can make, or an older version, perhaps 1.22, to see if the problem exists.
Well, merlin97501, thanks for sharing that. This is quite an important piece of info as it confirms the suspicions some of us had. I hope the team may be able to reproduce this now, perhaps.
Since youāve been able to reproduce the issue, would you care (if you find the time, of course) to downgrade to v.1.22 and check if you encounter any similar issues with it or not?
(You actually neednāt really uninstall your current version if you donāt feel like it, you can simply download the ZIP version, de-archivate it in a folder of your choice and start the executable. Just make sure that the other copy of BitComet that you have currently installed isnāt running.)
This would help narrow this down even more, as we could report back to the team that itās a change in the code which happened since v.1.22 which triggers the bug.
The suggestion sounds good, TuuS, however the team still does not have any clue of the cause. Since we cannot develop an Alpha or Beta version, I guess switch to 1.22, as Wiz suggested to user, will be the only available option currently.
I was trying to recreate the corruption so I disabled a bunch of files in a task, downloaded for twelve hours, turned off my computer for a night, restarted and checked. Nothing had been corrupted. I ran a hash check and still nothing corrupted. Everything worked normally and I was unable to confirm my theory.
I downloaded Bit-Comet v1.22 and Iām running a couple tests using that. However, since I was unable to recreate the problem using v1.26 I canāt really prove anything.
It is odd that this problem hit several people during one week and then just went away. Were this truly a problem with the code, it would have appeared soon after the change to the code and continued. What else could have caused it?
