2.0.x not sending stop event to trackers on program exit

Soon after updating from 1.8.5 to 2.0.2 I noticed that after exiting the client all sessions were still active on *all* of the (private) trackers' websites for each and every torrent I was seeding. They were not receiving an end-session stop event from my client. I have never had this problem on previous versions of uTorrent.

option bt.graceful_shutdown is true

I have confirmed this bug on both 2.0.1 (18973) and 2.0.2 (19648)

I have gone back to 1.8.5 and the problem is not evident with that version, nor have I ever had this problem with any previous versions of the client. All 2,000+ torrents received the stop events when exiting 1.8.5 just a few minutes ago.

I am using Windows XP Pro 32 bit on a Core2Duo with 3GB of ram.

I see the same thing as PunkMeUp with a couple of differences.

I was on 1.8.2, was offline awhile (4 months), updated to 2.0.2 (19648) when I came back online this past week.

option bt.graceful_shutdown is true

I found that using 2.0.2 when I exited the client all my torrents were still active on the private trackers I use. Apparently the client did not send the end-session stop event. Consequently when I returned an hour later I was double seeding all the torrents. As a few of them have penalties for that I moved back to 1.8.5 immediately.

When I exit the program on 1.8.5 my torrents all receive the stop events message. I seed approximately 1276 torrents at any one time over several private trackers.

I have never had this problem on any prior versions of uTorrent, have been using it since 2006.

I am using Windows 7 Pro 64 bit on an i5 (quad core) with 8 GB of ram.

If you have a ton of torrents, it eventually gives up and will shut down anyway. But graceful shutdown is supposed to make it wait... Hmm.

As a quick fix, just raise your halfopen and bt.connect_speed to a higher number and it'll announce to the trackers a lot faster.

My net.max_halfopen is at 8 and my bt.connect_speed is at 20 currently.

How much higher would you suggest those go?

Same problem here. In 2.0.2 about 130 out of 360 torrents were not reported to the tracker before utorrent left the memory, and indeed "bt.graceful_shutdown" is set to true.

Increasing the half-open connection would IMO do more harm than good if you're using a desktop version of Windows (normally accepting only up to 10 half-open connections). Probably the only solution until the graceful_shutdown is not bypassed is to stop the torrents manually and then reload utorrent (I know, it's a real burden for some).

Vista and Windows 7 have no half-open limit. They removed it.

Assuming you aren't running XP, set halfopen to maybe 40 and connect_speed to 40.

I'll investigate what's happening with graceful shutdown in any case.

As originally stated I'm running Win 7 Pro 64 bit.

Thank you Firon

So, I'd forgotten there's an option to control the shutdown timer now.

bt.shutdown_tracker_timeout controls how long it waits. I believe you need to -disable- graceful shutdown for this to work. -1 might work as a wait forever option, otherwise you can just set it to an obscenely high number.

I don't see this documented anywhere. Is it necessary to do in all 2.0x versions including the newest?

The help says a value of 0 (zero) for bt.shutdown_tracker_timeout tells the program to wait indefinitely but there's no mention of any interrelationship with bt.graceful_shutdown. Could we please get a definitive ruling on what the value of bt.g_s needs to be for bt.s_t_t to come into play or if the value of bt.g_s even matters at all with regards to bt.s_t_t? Thanks.

Can we please get a definitive answer to the last question? Been nearly a month now since asked. Thanks.

bt.shutdown_tracker_timeout and bt.shutdown_upnp_timeout work independently of bt.graceful_shutdown. It just so happens that the former two options aren't particularly useful if bt.graceful_shutdown is disabled.

Specifically:

- If bt.graceful_shutdown is false, then bt.shutdown_tracker_timeout and bt.shutdown_upnp_timeout won't really make much of a difference unless they're set to a timeout shorter than the hard 10-second shutdown limit forced by bt.graceful_shutdown being disabled.

- If bt.graceful_shutdown is true, then those options make more of a difference. They'll limit how long µTorrent waits for the network-related stuff (at least for tracker and UPnP stuff anyway). µTorrent may or may not take its time to deal with disk IO still, but that's a different story.

(That these options are independent of each other is why there isn't any explicit mention of their interaction with one another in the manual)

Thank you Ultima