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

[PunkMeUp]

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.

[Fiamma]

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.

[Firon]

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.

[Fiamma]

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

How much higher would you suggest those go?

[wferrari]

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).

[Firon]

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.

[Fiamma]

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

Thank you Firon

[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.

[Fiamma]

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

[WavSlave]

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.

[Fiamma]

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

[Ultima]

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)

[Fiamma]

Thank you Ultima