µTorrent sending STOP plus START events instead of COMPLETED event

[nightshifted]

Some µTorrent users are having a problem on the tracker where I'm a moderator. Apparently in some cases, or with some releases, when a leecher completes a torrent and becomes a seeder, µTorrent is sending a STOP event followed by a START event instead sending a COMPLETED event.

This is a problem because the tracker has just instituted limits on the number of peers a user may have on the tracker at once (we had a lot of difficulty with users' spreading their bandwidth too thin; if you want to talk about that, please don't digress into it, but let's focus this on when or whether µTorrent sends STOP+START instead of COMPLETED). Our rules are that a user may have a max of ten peers seeding and ten peers leeching, but no more than fifteen total, at any given time. When you try to announce a newly starting peer to the tracker, and it would exceed the fifteen total or the ten total for that type, the tracker rejects the announce.

However, these rules are not supposed to kick a peer off the tracker. If you have ten peers seeding and one leeching, and the leeching peer completes, it's supposed to be allowed to stay as an eleventh seeder. (However, if you try to start another seeding peer, the one that began as a leecher will count as a seeder now, and you'll need to stop two of those eleven.)

Unfortunately, some µTorrent users are finding that such a peer is rejected when it completes; the tracker admin confirmed that they are sending STOP and then START instead of COMPLETED. The STOP removes the peer from the tracker, and the user still has ten seeds going, so the START, now as a seeder, is rejected.

So, my question is, under what circumstances does µTorrent send STOP+START instead of COMPLETED, so that we can tell users how to avoid that? Certain releases of µTorrent? Certain settings in Preferences?

I tried asking users whether, when they leech a torrent with µTorrent and remain connected after completing, their connected time per the tracker's displays includes all their time since joining or only their time since completing (if they didn't already have ten other seeds going and didn't have any trouble rejoining as a seeder). I figured that in the former case, µTorrent must have sent COMPLETED, but in the latter it must have sent STOP and then START. Then someone pointed out that people who say it shows all of their total time since joining the torrent might be looking at the Time Elapsed shown locally in µTorrent, so the data I was gathering were worthless. Ah well.

Thanks for any assistance.

(As for my old problem about changing my address in my profile here, it was the fault of the target provider. I had no trouble changing it to yet a third address, but when I try that second one, the confirm never comes.)

[Switeck]

I think it may be the result of lazy bitfield being turned on by default to avoid disconnects by ISPs that block seeding.

[nightshifted]

That would be an unexpected connection.

One user there suggested -- and it had crossed my mind but slipped it -- that if a leeching peer is given a forced start, it will send COMPLETED rather than STOP+START. If so, that would cure the problem.

[Lord Alderaan]

If a torrent finnishes but there are allready a maximum number of torrents seeding (according to internal µtorrent settings) it will be set to queued seed. Which I think would result in a STOP. Then when one of the seeding torrent reaches a ratio of 1.0 (I think) it is stopped and the queued seed torrent will start seeding instead, which will resulting in a START I think. However there obviously would be some time between the STOP and the START then.

You never made clear how much time passes between the STOP and START but (depending on the size and speeds of the torrents) a short interval between the STOP and START would rule this out as the problem.

[nightshifted]

You never made clear how much time passes between the STOP and START but (depending on the size and speeds of the torrents) a short interval between the STOP and START would rule this out as the problem.

Thank you. You're quite right; I overlooked the possibility of an interval between STOP and START because I was trusting these users that their rejections from the tracker upon announcing as a seeder were coming as soon as their downloads completed. They could be wrong. Perhaps the delay is too short to catch their notice. One user claims to have experienced it despite doing all stopping and starting all torrents manually; but he'd still have a figure set for maximum number of active torrents, wouldn't he? That was the problem with asking users: many of them gave honest but uninformed replies.

On the other hand, do µTorrent's local settings have a separate maximum for active seeds from the one for active peers? All I see are a limit for total active peers and a limit for active downloads. Surely an attempt to set the former lower than the latter is rejected with an error message; it must be greater or equal. So if there was room in µTorrent's local quotas for an active leeching peer, its graduation to an active seeding peer shouldn't violate anything local in µTorrent.