PUSH

Thanks. I've been using BitComet from 0.5x till now, downloaded more than 700+GB. I can tell what's normal and what's not. All you said is BT's Law, that's right, But I still think there're something wrong. Because same situation happened - Peers are hard to get data from the seeder, this time, I am the seeder. It's a 52MB job with around 60 peers (still increasing), every peer (including me) stopped at 99.7% while there's at least 1 seeder, after 3 days, I reached 100%, so I try to seeding, and set it to upload at >5 kB/s speed. 24 hours passed, peers are still at 99.7%, almost nothing uploaded. meanwhile, my other downloading jobs worked ok, Isn't this unnormal? By the way, since last time I've post, The 4.10GB job is 95.9% now... (still 170MB left to be download) <_< <_< <_<

To whom may concern: since Sep 9 2006, 01:34 AM till now (Sep 21 2006, 00:33) The progress grows from 90.7% to 93.9% (total size 4.10GB) It took almost 12 days (287 hours) but just 3.2% downloaded! So, as Dark_Shroud said here, ( UDP connection bug in .70/.71 ) maybe "not really a bug more of a settings issue and a problem with your router", but what if the amount is too large to affect from peers to ISPs, Is it possible to reduce the speed? Or cause the connections between peers slow or stop? Since the problem in 0.71 / 0.72 was not solved, maybe the stuff should try think from this point of view. Also, I can't image why a seeder prefer to upload with such a extreme slow speed. maybe there's something wrong with 0.70 was not noticed yet?

To IronicRhetoric: "The UnUsual Suspect" told you where to get BitComet 0.70 . You can also download installable from here or green package from here. The rest he replied is answering to "Tomonori" (tomonori-k), the member who started this topic. Read again, you'll notice that. That's it.

As I know,there're some ".xml" files in the BitComet directory they are BitComet.xml 　　　　　BitComet_256RAM.xml 　　　　　BitComet_512RAM.xml 　　　　　Downloads.xml 　　　　　Favourite.xml In my case, I first install early version (0.60), and when newer version released, I download green version (non-install version) , unzip the newer BitComet.exe into c:\Program Files\BitComet\ and rename it to BitComet_070.exe / BitComet_071.exe / BitComet_072.exe... So I can keep all my settings and download tasks from being overwritten, and when bug found, I can test the same download tasks with different versions. That works fine through 0.60 / 0.67 / 0.68 / 0.70, but when BitComet 0.71 comes, after I did this and decide to downgrade back to 0.70, 0.70 did'nt read the download tasks (the task colume is empty). then I tried 0.60, it came back and still works fine, thus I can switch between 0.6x to 0.70. Now 0.72 released, I find 0.72 still empty in the download tasks column. *seems 0.71 & 0.72 made some changes to the .xml files(?) And when I downgrade to 0.6x again, some settings (saving position) was bypassed and went to the torrent files' defult ( ex.　　my setting: D:\download\something\File.rar 　　　 　torrent defult: D:\download\File.rar) So, here's my guestion: Anybody doing the same? (if not, don't fill the poll, however, suggestion still welcome) How's in your case for different versions sharing the .xml files, did the tasks disappear? Is this a bug? Thanks.

Progress report~ (Compare with my post#2&3) ====================================== Time passed:　　　　20+hours　　　　　25+hours BitComet:　　90.7%　　->　　　90.9%　　　->　　91.5% BitLord:　　　91.8%　　->　　　92.1%　　　->　　92.4% ------------------------------------------------------------------ BitComet:　　　　　　　0.2%　　　　　 0.6% BitLord:　　　　　　　　0.3%　　　　　0.3% ====================================== so during these time, BitComet wins :) But note this: peers are not grow up with the BitLord peer, So,The BitLord (BitComet 0.58 core) peer never upload? And the seed (BitComet 0.6) still uploads very few. Does that means 0.7x communicates bad with lower version (when there is only 1 seed)?

Yes, I experence that too, but sometimes maybe it's because the priority being low. What's your priority?

Say, when 0.7x peer appears, 1)If there're only 1 seed, it's hardly for each peer to recieve datas from the seed directly, so they just exchange what they already have, untill nothing to offer. That makes the situation like example #1 (many 99.7 peers while the seed is still there). 2)And only if there're more then 1 seed (and lucky enough), then this download is more easily to complete. Although this is normal with BT, but since 0.7x appear, it became more significant, especially when the seed is not using 0.7x. This maybe related with BC 0.71 wont accept peers and "The program thinks it is done and starts uploading". Any idea?

when you find this, how much is the percentage?

Thanks a lot. So what would be help? I've try to tell peers (via chat function) to use lower version of BitComet in order to finish this job, But due to the chat was "partially disabled"(?) in 0.7x, it seems no peer got my message. And even I downgrade to 0.60 (same version as seed), still I can't get reasonable download speed. seems 0.7x produced some interference between peers?

After 20 hours, just 0.1%~0.2% progress see this Really poor condition.... :angry: (The BitLord peer got 0.3%, even better then BitComet...) Why?

And this, it's another downloading job differs to above note this: 1) There's a seed at least, and is still alive ( the status shows "D_d5_0" ) 2) No upload/download from other peers, as the pink area shows (while my other job works fine). 3) Even if it's due to the seed uploads very slow, at least there should be transmition between others, but no... 4) The 91.8% peer seems not uploading/downloading anything, that's why I think the whole connection between these peers are dead (or almost dead). Why?? Any opinion?

Hello there: 0.70(and above) caused the connections between peers to stop. not lose connection, just stop. Every peer seems to download and share the same blocks of the files, that caused many 99.7% (for example) peers and only few 100% owner. And, the 100% owner stopped to upload anything, while still connected and still trying to upload. (no matter the 100% owner are using 0.7x or 0.6x) That's what we're suffering. Thank you. p.s. After I downgrade to 0.6x, I did get more blocks of the file, but still incomplete , so I guess it's due to there're still lots of 0.7x peers. :huh: like this..