No report when i close bitcomet

[Mihai]

Everytime i closed bitcomet without stoping all the tasks, bitcomet didn't reported to the tracker :( So i get at many torrents that are completed only 70-80% donne and seeding even if i downloaded them completely :( Any chance this might be fixed?

[Vasy]

Your statement makes no sense..

Do you mean that the task list is not saved when you exit, and when you open bitcomet the task list shows an earlier state? Enable system_use_app_data in BitComet's advanced settings, in Options (set to true).

[Mihai]

Mmm no sorry.I meant, when i close bitcomet with the tasks running, it doesnt report to the tracker that the tasks are stopped.That is why sometime it doesn't report a couple of MBs i download and so the tracker only sees me downloading 70-80% of that torrent.It got me in some trouble until now.

[Vasy]

Confirmed.

Lucy/Gavin, please test and report this to the team.

[greywizard]

Can you elaborate a little bit on how did you come to the conclusion that it doesn't report back to the tracker?

I mean, how exactly did you test or what made you come to believe that?

Do the torrents appear in your Task List with 70-80% or the tracker owner/staff has drawn your attention to that? (I'm assuming that you're speaking of some private tracker here).

Just trying to clear out the details of your problem and to make sure that we understand it right.

[Lucy26]

Hi Mihai, which version of BitComet are you using now? The older versions used to have this problem but the latest version should be fine.

Sometimes the file has finished downloading, but the progress shows less than 100%, please right-click the task and select "manual hash check" and it may tells you that the downloading is complete.

[Mihai]

# Greywizard

It's the tracker which i am having problems with.And not just one, most of them.If i just click exit without stoping it seems it doesn't report to the tracker what i've downloaded/uploaded from the last update until the exit.

# Lucy26

Last version, and no, it's not the problem in bitcomet.

[greywizard]

Please give a full description of your system: OS version, firewall, antivirus so that the dev team may test this maybe on a system of their own.

I'm not sure how familiar you are with networking, but if you can it would really help if you could make a capture in Wireshark, starting from the moment before you click on Exit and until after the BitComet process is being killed (so that the dev team could actually see what messages your instance of the client sends to the tracker) and upload the capture file here.

[kluelos]

I think he's saying that when you shut down BitComet without stopping the task(s) first, it does not send a metafile with the STOPPED event. Further that as a consequence of that, the upload and download counts since the previous successful scrape, are lost. This would assume that they are just discarded rather than having the task restart with those counts, when it is restarted in the future

I don't know that any of that is true, and none of it may be. Certainly there's been no evidence presented that any of it is so.

It's also not clear to me that you'd see definite evidence of this from the tracker. After all, shutdowns like this are commonplace and happen every time any client crashes, or the machine it's running on crashes. Certainly a tracker must be able to handle that event, for if it cannot, this is a serious flaw in the tracker.

Now, how this relates to the torrent being made incomplete, I don't understand at all.

[Mihai]

I think he's saying that when you shut down BitComet without stopping the task(s) first, it does not send a metafile with the STOPPED event. Further that as a consequence of that, the upload and download counts since the previous successful scrape, are lost. This would assume that they are just discarded rather than having the task restart with those counts, when it is restarted in the future

This is exactly what happens.I will test it a little more on other trackers just to be 100% sure but until now this happened on more than 5 trackers.So it might be a problem from the trackers? Because i tested the same thing with utorrent and it worked, it reported to the tracker :(

#Greywizard

If this is actually a tracker problem then there is no more need for this.If i see this not working anywhere i will try your method and will give all the detailes.

[kluelos]

I don't know that any of that is true, and none of it may be. Certainly there's been no evidence presented that any of it is so.

Now, how this relates to the torrent being made incomplete, I don't understand at all.

[Mihai]

So i tested it esterday on 5 different trackers and it happened the same thing on all.I closed bitcomet and waited 10 minutes and still the no update to the tracker which showed me still seeding so clearlly bitcomet didn't reported to the tracker before the close.

I don't know that any of that is true, and none of it may be. Certainly there's been no evidence presented that any of it is so.

Now, how this relates to the torrent being made incomplete, I don't understand at all.

Because my download speed sucks sometimes i don't get to download a full torrent in one day and because i didn't knew about this bug i always closed it when i had 40-50 % or other values.This way Bitcomet didn't reported what i leeched since the last update interval until the close. This way on most torrents i didn't leeched in one day i have a problem with the tracker which only shows 80-90% downloaded even if i leeched it all.

[kluelos]

So i tested it esterday on 5 different trackers and it happened the same thing on all.I closed bitcomet and waited 10 minutes and still the no update to the tracker which showed me still seeding so clearlly bitcomet didn't reported to the tracker before the close.

No, sorry, but you're completely wrong about what that means, and you don't understand how it works.

When you send a STOPPED event the tracker takes you out of the swarm. It does *not* confirm to you. It does *not* reply. It does *not* send you an updated peer list with you no longer in it. (You just told it, 'I'm outta here!", presumably that means you're not there to reply TO anymore, no?)

Every other peer in the swarm does not instantly learn that you are no longer a peer. Each one of them individually learns that, by successfully re-scraping the tracker, which can take a very long time indeed - hours.

Each peer is given a value, part of the metafile from the tracker, telling it how long it should wait before scraping the tracker again. This is normally in the neighborhood of 20 minutes. This is one way in which trackers try to control their own loads.

After that interval, whatever it is, each peer tries to rescrape and get an updated peers list reflecting who has joined and who has left this swarm (This is also when that peer reports how many bytes it has downloaded and uploaded for that torrent).

That scrape might not succeed (timeout, network error, who knows?) so that client continues using the old peers list that it's already got, waits a while, and then tries to contact the tracker again. Once again, this attempt may succeed or it may fail, so the client rescrapes at gradually longer intervals, until it succeeds.

It may be an hour, or even several hours before this client gets an updated peers list, depending on how badly overloaded the tracker is, how congested the network is, and how long it takes to get through.

During that time when your client hasn't been able to update, it keeps using the old list, showing all of the old peers, even though one of them dropped, went off to lunch, an hour or more ago. HE left and stopped seeding, but YOUR client is still showing him there. That doesn't mean he actually is still there, just that your information is out of date. See?

Because my download speed sucks sometimes i don't get to download a full torrent in one day and because i didn't knew about this bug i always closed it when i had 40-50 % or other values.This way Bitcomet didn't reported what i leeched since the last update interval until the close. This way on most torrents i didn't leeched in one day i have a problem with the tracker which only shows 80-90% downloaded even if i leeched it all.

Let's say that you've finished downloading, your client says you've got 100% of the torrent, and you have seeded to an UD ratio that satisfies you. We're in the same network conditions as above. You're basically finished with this torrent, so you stop it, remove the task, and go happily on your way. You've got what you wanted, and you've shared back, so everything's good.

What happens to your final message, with the COMPLETED event? It hits the same wall of congestion and slowdown that all your previous traffic to the tracker did.

So what happens? Think about this.

Has it suddenly become your responsibility to hang around and make sure the tracker GOT your completed message with your final count? Would you even know how to do that? Would most people? Does your client tell you, "wait,don't stop the task yet, I haven't got through to the tracker yet?" when you end the task?

It does not.

Your message just gets lost and the tracker never learns your final count or that you've finished and seeded awhile. This happens. It isn't your failing and it isn't the client's.

Every client is vulnerable, every tracker is vulnerable, to this. This is an event statistically certain to happen. That it did happen isn't proof, or even evidence. The tracker not receiving the message isn't proof that a client never sent it, especially not when the tracker doesn't receive MOST of the messages sent to it -- (all those tracker timeouts while you were downloading).