Jump to content
To block spammers, this forum has suspended new user registration ×
Comet Forums
To block spammers, this forum has suspended new user registration

found a reproducable major bug


Recommended Posts

when your downloading a torrent with multiple files. if one file finishes, and the one below it is banned, if you reenable the banned file the one above it at 100% loses data and starts over again at 90%. sometimes if you disable files it will erase the data they had completely and screw up other files that are already finished

Link to comment
Share on other sites

That’s not actually a bug. I'll try to make it simple. BitTorrent downloads in measurements called blocks. These blocks of data are grouped together in pieces that are adjustable in size. So you get files that span pieces. So when you un-ban that piece, you sometimes have to deal with it being in parts of previous pieces.

Link to comment
Share on other sites

well lets say i download a torrent with 26 video files... if I ban all but episode one.. and episode one finishes completely.. I could cut and paste that episode out of my default download folder. it is complete and would play fine. However if I renable those other 25 files while the episode is in my download folder it erases some of the data and makes it unplayable until it has redownloaded it. I guess I could cut and paste but it is still a BUG..

Link to comment
Share on other sites

Dark shroud is correct, this is not a bug.

I will explain.

If part number 1000 (to pick a random number) of your download has some of episode one and two in it, the parts of episode two are deleted (since you did not select to download episode two)

Your client will then need to redownload part 1000, so will have to mark it as not downloaded, which is why your episode one will then not be complete.

The only way to avoid this would be to keep all the extra unwanted data from parts that you downloaded (but then you would be asking why you are downloading data from files you didn't select).

Bit torrent protocall was not designed to pick and choose files, this is an enhancement that was added in bit comet (and a few other clients).

Unless the author of this torrent was to be sure no parts spanned episodes, then there is no way to avoid this.

I do suggest it will be best to get all episodes at once, as you will be a more valuable peer to others, and your overall download will be more efficient.

I hope I explained this clearly...


Link to comment
Share on other sites

Well, we could avoid erasing the data already downloaded.

If you only select episode 2, it will download part 1000 and ignore some data in it.

If you select both episode 1 and 2, and you already downloaded episode 1, you expect the same behaviour: downloading part 1000 and ignoring some data in it to avoid altering episode 1.

Easy to implement I think: just need a test to check if file is already completed, and in that case ignore data downloaded relative to this file.

Link to comment
Share on other sites

There is are 2 easy fixes for this.

1st) Just download everything at once.

2nd) When you decide you want to download more episodes/parts/etc stop the .torrent, select the new parts, and then run a hash check before starting it again. That should fix the problem as the data is not deleted.

Now I know you want the client to do everything for you. By version 1.00 BitComet will turn on the computer, log onto the net, and download what .torrent files you want, and even wipe your bum for you. But the current versions don't work like that. If you choice to use added features that are not part of the normal protocol you're going to have to deal with little quirks like this. -_- That's all the can be done at the moment.

Link to comment
Share on other sites

whatever it is i have noticed similar quirks if you may....?

For instance I have a torrent which in total of say 3.50 GB. I only selected 1.30GB of that torrent.

When completed to 100% and after numerous closing & restarting of Bitcomet...& rebooting windows & after continuous manual hash checks BC still reports and has 100% of that 1.30GB of selected files.

I've copied to a different partition /dir for backup & renaming. They are digital comics aka (.cbr .cbz files) which are only rar or zipped jpeg scans blah, bla, blah.

BUT my quirk is if I reload the same torrent using same dir, same everything and use say AZerues or µtorrent then do hash checks again. They both give different results always smaller by 10-30%.

Always have wondered why... also when I do these comparisons only one client is open at a time. When peeps use ratio private tracker sites it makes a difference.

For me it doesn't matter cuz I'm aware of the quirks and dont dip & dab using diff or multiple clients with the same torrent on these type of sites.

But I can feel the n00bs frustration or da pros not in the loop of the techie side or protocol of bt... :lol:

Prolly why they be screaming foul all the time when in reality there is no foul...

Not complaining just throwing in my 2 cent

Speaking of bugs I was browsing the forums and couldn't log in for squat and had to make a new account to post... been registered member for over a year but the system said there was noone named blah blah blah, yada yada yada c*** a doodle doo.

no biggie sh$t happens keep up the good work.

Link to comment
Share on other sites

just confirmed this bug does not affect utorrent

again I say, its a bug.


Here is what I have noticed when using utorrent under this condition.

It will download parts of the files not selected to download, if those parts are necessary to get all the data for the files I did select.

Bit comet is a little more involved in that it will also download those bits and pieces, but not save them to disc.

It will rather hold them in cache untill the seeding is finished and delete.

Since Utorrent has a less hi tech approach, it won't have to redownload this data that is sifted and deleted by bit comet.

Utorrent is a fine client, which is very simple and basic compared to bit comet.

I still donot believe this is a bug, just two different ways these clients handle doing something that bit torrent protocall was never designed to do.

I will of course let the developers deside who's opinion is correct concerning this.



Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in

Sign In Now
  • Create New...