Jump to content

Trackers go offline after 7-8 hours @ ut1.8


snowdecoy

Recommended Posts

Hi.

I recently updated to 1.8.

After a period of 7-10 hours since utorrent starts, all four different trackers of my seeding torrents go offline and never come back unless I close and restart utorrent.

After restarting the program everything works just fine and trackers keep updating normally for the next 7 hours or so, until at some point all go offline again.

I never had any problems with the previous version (I can't remember which one exactly, but it was the latest).

I'm using kerio software firewall and avast pro antivirus.

I have forwarded the port for incoming connections (port:53322) in my rooter even though the rooter firewall is disabled.

I haven't changed anything in my configuration except for the update in 1.8 so I can't think of anything to try since everything was working properly before.

Any help would be appreciated ...

Thanks in advance.

Link to comment
Share on other sites

ok thanks for the info.

I'll give it a try even though a downgrade to the previous 1.7.7 (finally found it in my hard drive) sounds more appealing.

Do you know if the setting has been changed in 1.8 different than in previous versions?

As I first wrote what troubles me is that I didn't have this problem before the update, so I'm looking for that detail that changed and is causing this ...

Link to comment
Share on other sites

WinXP Pro SP3

uTorrent 1.8, fresh install (all default settings)

I can verify that I have encountered the same issue when upgrading to 1.8 with default Advanced uTorrent settings. I also noticed though that all network related functions of the PC seemed sluggish when the uTorrent timeout condition was occurring. For example, a local web and eMail server taking much longer to perform functions. Restarting uTorrent did not always fix the problem, although restarting the PC always would. I concluded it to be a deeper networking problem, and noticed I was getting more of the System Events:

(Log ID 4226:TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts.)

than I would have expected, for the number of torrents I was working with, and they seemed to correspond roughly with the beginning of a timeout condition.

First, upgrading the nic driver had no impact. I didn't really expect it would, but it was out of date and needed to be addressed anyway, and was relatively low risk.

Second, addressed the underlying issue in the tcpip.sys driver and the half-open limit (targeting the error event), using the well-known patch from lvllord.de, accepting the default new limit of 50.

I have additionally increased the uTorrent advanced setting net.max_halfopen to 20 (from 8), based on the assumption that if all 8 were being used before, more where probably needed anyway for efficient BT operations.

I've been running for 2 days now with no further occurrence of any network related issues.

Link to comment
Share on other sites

I have additionally increased the uTorrent advanced setting net.max_halfopen to 20 (from 8), based on the assumption that if all 8 were being used before, more where probably needed anyway for efficient BT operations.

This is an incorrect assumption.

BitTorrent applications do NOT need an increased limit. An increase halfopen limit is COMPLETELY useless after the first minute of a torrent's activity.

Link to comment
Share on other sites

More than enough, really. If other applications create more than 2 half-open connections while µTorrent is using the full 8 (assuming TCPIP.sys is unpatched), overloading will ensue. BitTorrent clients are probably more connection-creation heavy than many of the usual/casual Internet-enabled applications too, so allowing it such a large portion of the already small half-open connection limit is really overkill.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...