Upload Not Stopping

[Anubiarack]

Hi

When i have uploaded som time after downloding and i look at the top on bit comet it just continues to upload and nonot frozen and cheked all t torrent files but all where green so i need some help. i tryed to delete all torrent files but diddent help

Yes we uses Router Can't remember the name. uses 2 anti virus programs norton and avg

[kluelos]

Is there someone you could get some language help from? I don't understand your question at all and I dislike guessing.

I *think* you are asking about uploads, but your screen shot shows only your download task screen, so it's not helpful.

[sophia0316]

I think he is asking why there is still uploading data when he stopped all tasks.

If I am right, this FAQ in our wiki may be helpful.

[greywizard]

How soon after deleting the tasks have you taken the screenshot? (immediately, 1 minute, a few minutes, half an hour?)

[kluelos]

Look at the screenshot more carefully. It's showing the DOWNLOADING tasks only. We have no idea what upstream tasks he's running, but with that much going, I can easily see it generating a small amount of downstream traffic from ACK's and whatnot without any download tasks at all.

[Anubiarack]

if you know the program well enogh then all the torrent files will be marked in () in the end of the name but i deletet all of them

[Anubiarack]

and schreenshoot was taken 20 mins after

[kluelos]

I would call that unresponsive, so, we have the same questions we had before.

[sophia0316]

OK, let me check with the team about this.

[Mihai]

I know this problem.I had it too.Disable Long time seeding and everything will be ok. :D

when i had the problem all my torrents were stoped but bitcomet was seeding with 100KBps when my max bandwich is 50KBps :P

I think it's a bug or something.

[kluelos]

Since we're getting zero cooperation and no answers to our questions, it is likely to remain so.

[Mihai]

Well i can give out detailes about this problem if the team wants to fix it :P

[cassie]

Well i can give out detailes about this problem if the team wants to fix it :P

How magnanimous of you!! That is something that you could have included within your first post, no? But still, you think nothing of wasting others' time and effort... It must be nice to have time to squander. <_<

[sophia0316]

Hello all, this is a long-time seeding bug(It will last for some more time after you delete a task but not delete the file) which will be fixed in next version. Exit your BitComet and restart may help.

And our beta version is expected released tonight. please have a try when it's released.

[kluelos]

I don't understand how you can possibly know that, Sophia -- for all we know, he has a dozen different upload tasks running, and is seeing exactly what he ought to see. But since he isn't responding to any questions or posting a screenshot of his uploads, there's no way to know. How do you know that there's a defect involved?

[greywizard]

There is no number in parenthesis following any of the All downloads, Downloading and Uploading categories in the Favorites pane. Therefore they are all empty.

He seems to have tried to point that out earlier but he has a hard time being articulate in English, as it seems, or being articulate, period.

[sophia0316]

@kluelos, I forwarded this post to the team. And as this is somewhat similar to Wiz's post. And he also deleted all tasks but still uploading. So our team think that's the same problem and caused by the same bug. But anyway, we need his confirmation, exiting Bitcomet or trying new beta solves that problem.

[jgf]

I'm having a similar problem, except from emule. To shut down I disconnect emule, close its window, right click on the bitcomet status window (small window in upper right of desktop showing upload and download speeds), select exit and OK the prompt. Ten minutes later I notice activity on my firewall icon in the system tray; check the firewall and find emule is uploading and downloading at a 4k-8k rate. Open bitcomet, open emule, and its window says both emule and KAD are disconnected, yet it also shows the 4k-8k activity in both directions. I'm certainly no expert here, but logic says if the device is disconnected it can't be transferring data in either direction, much less both directions.

[greywizard]

Forgive my asking but how do you see traffic for eMule in your firewall if it's closed?

An application has to have a running process in order for you to see traffic in any application which monitors the network (firewall, packet analyzer, etc.).

Did you actually check the process list to see if eMule's process is really closed or just hidden?

And where in your firewall did you see traffic for eMule?

[kluelos]

That's not really the same issue, jgt. Peer to peer traffic can't normally be just shut down in a moment. Whatever system you are using, it takes time for the word that you're gone, to propagate. Those who were in contact with you before the shutdown will keep trying to contact you after the shutdown, until they either get the word that you are gone, or give up trying to get a response from you.

In BitComet, for example, a proper shutdown sends a metafile to the tracker with a request to remove you from the list of peers. But then every other client in the swarm needs to update from the tracker, to get the revised peer list you aren't on anymore. Until that happens, each of the is operating from the old list which you're still on and they'll keep trying. It may take an hour or more for all of the traffic to finally die down. That's nothing to worry about, though.

I'm less familiar with eMule (don't use it much anymore), but IMSMR there are two ways to do a shutdown, and the recommended, friendly and default way is to let transactions already in progress complete but not accept any new ones, while the other way is to just kill them all immediately and let God sort them out. Even if you do it the second way you're still going to be getting queries from other peers for a good long while until everyone finally times out on you.

[jgf]

Forgive my asking but how do you see traffic for eMule in your firewall if it's closed?

An application has to have a running process in order for you to see traffic in any application which monitors the network (firewall, packet analyzer, etc.).

Did you actually check the process list to see if eMule's process is really closed or just hidden?

And where in your firewall did you see traffic for eMule?

I look under the "history" tab, which shows all incoming and outgoing signals, giving date, time, type, port, etc. For example, I just checked this data - the four most recent items show a destination port of 60000, which is Bitcomet's listening port; the next three items are for port 55000, which is emule's listen port. The next most recent is outgoing from port 60000, then another incoming to that port, and another outgoing from that port. Those are all timestamped 9:53PM (it is now 10:09PM local); I shut down Bitcomet and emule around 8PM. In Task Manager I do not see either program under applications, processes, or services.

I could understand incoming traffic to either of those ports for a few minutes after shutting down those programs; but it's odd there is still incoming traffic two hours later, and even stranger that there is an outgoing signal from a listen port (or maybe I don't understand the terminology).

Just double checked the firewall history, the ten most recent items are to or from port 60000.

[greywizard]

Well, as kluelos clearly explained to you, connection attempts on the listen port are bound to be seen for a quite long time, after you shut down your client. That's normal. Your firewall should block/drop them automatically.

What you're seeing is not a monitoring window of "live" active connection. You're looking at the firewall log which records failed connection attempts (and even successful ones, if told to).

You failed to mention what does the log specify, about those connection attempts; were they successful (allowed) or were they blocked?

If they were blocked (as they should be by default) then your firewall it's doing its job and there's nothing to worry about.

If they were successful then you have a problem.

OTOH you shouldn't see outgoing connection attempts on the listen port of BitComet, unless you have another application which uses that port to communicate, as well. In your firewall log you should have also the application which initiated a connection on that port.

Maybe it's best that you post a screenshot of that window here, so that we cant take a look at it.

If you don't know how to do that, there is a guide in the Guides section of that forum.

[jgf]

It has been several hours since Bitcomet was last running, and Vista has been restarted during that time. I just took this shot of the firewall history, port 60000 is the Bitcomet listening port.

[greywizard]

What happens if you select an entry and hit the "Details" button?

The way the screenshot looks right now, it pretty much useless for our purpose, because we're trying to determine which application communicates through that port, and the main log window fails to provide that info.

Besides, if you look more closely to your log you can see that all the outgoing connections on port 60000 are towards the IP: 111.255.79.111 which is located somewhere in Taiwan. But then again you can see connections (both outgoing and incoming) with that IP made on other ports as well. That's not typical BitComet behavior.

Therefore, this can be another application in your system, using that port for communicating. But unless your firewall can show you for which application those log entries are, you're blind about this.

Try looking in the list of active connections and see which application uses port 60000.

[jgf]

A quick check just now got this, details are for the third entry in the history window. I've tried to find specific programs associated with this problem, but usually just see "system" or "svchost".

Edited February 10, 2010 by jgf (see edit history)