µTorrent 3.1 stable (build 26671)

GUI bug?

32bit 26595 on 64bit Windows 7 seems to have a massive memory leak. when I started it before going to work, it was fine. when I checked it a few minutes ago (11½ hours later) it was eating 596MB and 50% CPU time, and acting uselessly unresponsive. I had 13 torrents going.

UPDATE: between 1:30am and now (4:50am), it's now eaten up 118MB and 70%CPU time. This is really not good, guys.

This client just continues it's trend of becoming an awful torrent client. Really disappointing.

High CPU usage.

Hangs when exiting.

Tons of data being uploaded and downloaded, despite no active torrents.

My internet becoming much slower for browsing when uTorrent is running.

These are just a few things since 3.0.

I really hope things will change and go back to being an excellent client.

I also hate that any time I try to get help with issues on this forum, I get some moderator with an attitude. Really not helping my impressions either.

khristopher,

I am by far NOT a uTorrent expert. I can understand to a certain degree your fustration. I would like to see more system and integration testing prior to a version becoming a RC.

But you cannot expect uTorrent to pull/roleback enhancements. If you like the older version, go back to it.

As far as "High CPU" usage, I have never seen it that high. Sometimes it would 11-12%, but I have 60+ torrents downloading and seeding. And I do a lot of Force-rechecks because I am recovering a lot of torrents I have lost in the past.

"Hangs when Exiting" issue has been posted before. uTorrent notifys trackers of current ratios. It also has to finish writing out the cache. Depending on the number of Torrents loaded/active, that can take some time. If you kill the process or shutdown your computer without waiting for uTorrent to finish what it needs to do, you are going to slow your startup because of rechecks on all files you were downloading and still open at the time. Since uTorrent processes rechecks serially, that can take a lot of time to get backup to speed.

"Tons of data ....", I do not know what you mean by "Tons". But it has been posted that if you have DHT enabled, there will be activity going back and forth between uTorrent and the DHT net(?) even if you do not have any torrents active. If you do not want that activity - disable DHT.

I do not know the speed of your internet connection. But if you are trying to max out uTorrent, then of course it should/could effect your browser performance. But it may also be just the sites you are interacting with. Why don't you try to limit your download and upload speeds to reduce the impact to your browser activity. I am downloading approx 400kB's and I do not notice any significate loss in browser performance.

Sarraq:

I am also running Windows 7 64bit, with uTorrent 26595. Although I have seen an increase in memory usage to 256mB where in the past it was about 150mB, I have not seen a significate increase in CPU utilization. It usually remains around 10%. This version seems the most stable of the bunch.

Firon , AdamK , DreadWingKnight , Ultima , Greg Hazel , arvid

Our community not understanding your policy to forbid automatic isp.peer_policy_url updates from default value. This option is allowing to achieve better speed and availability for local peers.

By using this option nobody can restrict download/upload operation, and we are not interested in such actions. Our target is to gain highest possible speeds in different network layouts.

if the client cant read piratebay RSS feeds its completely useless to me as well as many others. anything that can be done to fix this?

Hi all !

uT3.0 has the "osmosis 25-30% CPU problem" problem.

What about 3.1 stable (this release) ?!

Is this version also has that "bug" ?

-------

Edit :

Thank you Rafi !

Hi all !

uT3.0 has the "osmosis 25-30% CPU problem" problem.

What about 3.1 stable (this release) ?!

Is this version also has that "bug" ?

Nope ... . .. . . . . . .. ... . . . . .

Now it's downloading directly into the cache and never writing to disk. Had a torrent ramp up and exceed the write cache by 300/32 (26000 writes To Cache) with still 0 writes To File... really weird stuff going on.

Hi osmosis, was that version 26595?

Wasn't at the time, Adam, but I can definitely still reproduce on 26595. Anything I can do to help track it down?

There are two issues at play there in case it got a little convoluted in my string of posts: the disk writes take forever to start during ramp up, and also the exceeded cache. There seems to be a correlation to exceeding the cache and having "Apply rate limit to transport overhead" enabled, though I'm not sure how those two things could be connected.

With it disabled I get a throttling effect when the write cache gets maxed on a fast torrent even though I have Download Limit at "Unlimited" (Is this the normal, expected behavior to avoid exceeding cache?). Enabling it, for some reason, allows it to massively exceed the cache since I guess there's nothing to stop it (no throttling?) and there aren't any disk writes occurring so it just blows up. Fresh torrent Delete and re-Add of the slackware x86 "everything" torrent to test it with each setting change, no program restart required.

The disk write lag occurs regardless of "transport overhead" setting.

though I'm not sure how those two things could be connected

A broken settings.dat ? re-"install" ?

Use "my" two magic cache settings and stop wining ? ... -> http://forum.utorrent.com/viewtopic.php?pid=624456#p624456

I already tried that, remember? Ahh and now I understand the reason it didn't exceed there; the default "Apply rate limit to transport overhead" setting of disabled! Still clearly had the disk write lag though.

Edit: Haha and yes, I might end up using your settings, but default behavior like this is likely a bug, so report it I shall.

Wasn't at the time, Adam, but I can definitely still reproduce on 26595. Anything I can do to help track it down?

There are two issues at play there in case it got a little convoluted in my string of posts: the disk writes take forever to start during ramp up, and also the exceeded cache. There seems to be a correlation to exceeding the cache and having "Apply rate limit to transport overhead" enabled, though I'm not sure how those two things could be connected.

With it disabled I get a throttling effect when the write cache gets maxed on a fast torrent even though I have Download Limit at "Unlimited" (Is this the normal, expected effect to avoid exceeding cache?). Enabling it, for some reason, allows it to massively exceed the cache since I guess there's nothing to stop it (no throttling?) and there aren't any disk writes occurring so it just blows up. Fresh torrent Add of the slackware x86 "everything" torrent to test it with each setting, no program restart required.

The disk write lag occurs regardless of "transport overhead" setting.

Okay, thanks. We are still doing a lot of triage after the release - we got the crash rate back down to normal after 26591 & 26593, but we still have a lot of things to do to make sure everyone's use cases are ok. Rafi just delivered a long list, and we're sorting through it.

I'll let you know as soon as we have a good idea for tests for the write cache problem.

I'll also post a list of the problems we intend to tackle in the next two weeks, once we have it.

Fantastic news! Yeah it's coming along nicely. Now that I've turned off that transport overhead setting it's quite usable again. Thanks so much, and please consider some of the "leftover" issues/bugs from previous versions in my buglist post as well!

[2011-12-12 10:55:40] 87.101.140.39:44296 [uTP](Frozen.Planet.S01E07.720p.HDTV.x264.AAC-SSN.mkv): [µTorrent 3.1 (77.1)]: Banning peer: too many pex messages. 5 since Mon Dec 12 10:55:40 2011

i think that utorrent is funny piece of software (i'm with utorrent 2.2.1)

Hmm I have this odd compulsion to watch boxing now for some reason..

Just updated to 3.1. Why do I have this weird foreign text in the toolbar?

We fixed the problem, but existing settings.dat are corrupted. Just wait a while and it'll eventually go away. Or delete your settings.

1. Completed Date is consistently ~45 days ahead. Files completed today are listed as 2012-01-31.

2. The "Bandwidth Allocation" submenu is off-by-one. I reported this on previous builds, but it hasn't been addressed. Selecting High shows Normal selected. Selecting Normal shows Low selected. Selecting Low shows Low selected.

are there any news regarding this issue described here

http://www.pleasuredome.org.uk/index.php

http://forum.pleasuredome.org.uk/index.php?showtopic=17928

firon

The files themselves all have "good" data, but they're padded with garbage (usually zeros) after where the file should end. In theory, the zip files will work anyway, but clrmamepro will definitely complain about them being wrong. A simple truncation to the correct filesize will fix the files.

A force re-check does not fix the problem, since µTorrent does not truncate files, ever (which is probably a bad thing).

We're investing to see how we can fix the problem. Unbuffered writes in Windows have a limitation where filesizes must be an exact multiple of the block size, so you need to open it in buffered mode to create it, then drop back. Unfortunately, this sporadically fails, so it ends up having to create the file in buffered mode.

thanks for ur time

I think we fixed that, but it can still happen with certain combinations of settings (as an unavoidable problem). You'll need to UNCHECK the bypassing of the Windows write cache to guarantee it never happens.

khristopher,

I am by far NOT a uTorrent expert. I can understand to a certain degree your fustration. I would like to see more system and integration testing prior to a version becoming a RC.

But you cannot expect uTorrent to pull/roleback enhancements. If you like the older version, go back to it.

As far as "High CPU" usage, I have never seen it that high. Sometimes it would 11-12%, but I have 60+ torrents downloading and seeding. And I do a lot of Force-rechecks because I am recovering a lot of torrents I have lost in the past.

"Hangs when Exiting" issue has been posted before. uTorrent notifys trackers of current ratios. It also has to finish writing out the cache. Depending on the number of Torrents loaded/active, that can take some time. If you kill the process or shutdown your computer without waiting for uTorrent to finish what it needs to do, you are going to slow your startup because of rechecks on all files you were downloading and still open at the time. Since uTorrent processes rechecks serially, that can take a lot of time to get backup to speed.

"Tons of data ....", I do not know what you mean by "Tons". But it has been posted that if you have DHT enabled, there will be activity going back and forth between uTorrent and the DHT net(?) even if you do not have any torrents active. If you do not want that activity - disable DHT.

I do not know the speed of your internet connection. But if you are trying to max out uTorrent, then of course it should/could effect your browser performance. But it may also be just the sites you are interacting with. Why don't you try to limit your download and upload speeds to reduce the impact to your browser activity. I am downloading approx 400kB's and I do not notice any significate loss in browser performance.

My CPU usage is in the 20's.

Hanging when exiting is not a HUGE deal. That one I can deal with.

I do not have DHT enabled.

My internet is 20 mbps down. 1 up. I do not allow uTorrent to use the full amount. I have it set to 1500K.

I think we fixed that, but it can still happen with certain combinations of settings (as an unavoidable problem). You'll need to UNCHECK the bypassing of the Windows write cache to guarantee it never happens.

and the response

Just tested uTorrent 3.1 RC11 which is marked to become the next stable release.

The problem still hasn't been solved.

I haven't been able to do the MAME Titles test without getting wrong sized (padded) files, no matter which cache setting I choose.

With 3.1.26595, I continuously get "Disk overloaded 100%" warning when downloading at relatively slow speed - 1-1,5 MBytes per sec. I have played with settings (coalesce_write_size, low_prio_disk - as Rafi described) and checkboxes on "Disk Cache" tab - no effect.

I reverted back to 2.2.0.21738 and of course there's no such issue with that version - even 6-7 Mbytes per sec download speed doesn't cause disk overload.

What to do?..

Your OS / HD? Did you remember that changing low_prio_disk requires restart ?

So does changing low_prio_disk actually change something?

Its at *false on my settings currently.

So does changing low_prio_disk actually change something?

Firon,

This feature will help in situations of forbidding torrent downloads via fake DHT table (there is real working situation, visit http://piratepay.ru/en - the page one of such program vendors)

In this situations default "http://peerpolicy.local/announce.xml" will help to gain necessary speed.