Archived

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

cmeisel

µTorrent 3.3 Stable

Recommended Posts

The same problem as Flep had at the same situation: Windows 7 x64 was installed two weeks ago, Task Manager says that uTorrent takes 30-50 MB, but the total amount of memory in use is 3.6 GB (with 4 GB total in system). When uTorrent process ends, the amount of used memory is reduced to 1.7 GB (so system usually have in use after reboot). I don't know what it is, but it is obviously related to uTorrent. (Of course, the problem has appeared recently — with one of the last betas of 3.3.)

Share this post


Link to post
Share on other sites
The same problem as Flep had at the same situation: Windows 7 x64 was installed two weeks ago, Task Manager says that uTorrent takes 30-50 MB, but the total amount of memory in use is 3.6 GB (with 4 GB total in system). When uTorrent process ends, the amount of used memory is reduced to 1.7 GB (so system usually have in use after reboot). I don't know what it is, but it is obviously related to uTorrent. (Of course, the problem has appeared recently — with one of the last betas of 3.3.)

Windows uses memory for caching. Just stop fretting.

Share this post


Link to post
Share on other sites

not the utorrent.exe process in task menager' date=' but after i quit utorrent then a lot of ram is free.

Today i noticed 99% RAM usage, when i quitted utorrent it was ~20%, so i dont know :o[/quote']

utorrent is 32bit app......1.8gb is maximum use

So i dont know what's wrong, windows is clean, becouse i reinstalled ~1 week ago

I do, windows' disk cache is being stupid. It's not uTorrent.

Share this post


Link to post
Share on other sites

µTorrent Stable (3.3 build 29038)

Ok, I tried installing it again & this time it worked. Installed over the top of 3.2 & kept all my settings, torrents & proxy. Went to my 2nd computer to install it there exprecting to have to install, uninstall, install 3.2 againg, then 3.3, but the very first install of 3.3 worked just like usual, no problems or lost settings etc. Have no idea what happened the first time???

By the way, µTorrent Stable (3.3 build 29038) uses hardly any memory or CPU time on my 32bit XP or 64bit Windoze Se7ven. My experience in the past has been that when you do something to screw up your Windoze OS, that can cause the CPU &/or memory hog problem. Only way I have found to fix that in the past is to do a Clean Install of the OS, ugh.

IMHO

isepiq:cool:

Share this post


Link to post
Share on other sites
3.3 and 3.4 install into %appdata%/uTorrent/ to bypass the UAC (User Access Control) and allow "silent updates" to the client.
silent updates is evil.

and I can't see bypass of UAC when start setup — anyway installer asks admin rights.

When we introduce silent updates, you will *DEFINITELY* have an option to not use them.

Unfortunately, we need to throw the UAC dialog to add the windows firewall rule.

Share this post


Link to post
Share on other sites
The "Label" directing the torrent to download in the Specified directory feature isn't there?

Yes - don't worry, this is just temporary. We're excited about this feature, but it is not usable enough yet (mostly UI changes)

Share this post


Link to post
Share on other sites
and what about DHT, I see about 2K nodes. I never saw so many nodes. At 3.2.3 the value was about ~350 nodes.

and at 3.3 it's updating continuously. never stops.

Hi,

We did increase the DHT routing table size - one of many small changes to make dht lookups faster.

We'll look into the ui update frequency issue - thanks!

Share this post


Link to post
Share on other sites
still something unknown with DHT: current number of nodes is 666 (wow) but ten minutes ago it was 2076.

wtf?

Nodes go offline all the time, but that does sound odd.

Share this post


Link to post
Share on other sites
Great release! Even better, I'm getting twice the previous speed! Without using any tweaks or custom settings other than "preallocate files" :D If only more software was as stable, lightweight and feature-rich as µTorrent... Thank you for this great piece of software. I couldn't believe it could get better in terms of features, until you introduced video preview in version 3 (along with the rating/commenting system and the new documentation if I remember correctly). That's a rare thing, to exceed users' expectations. And to think there are so many commercial applications that pour new versions every year without bringing significant additions... I've voted for µTorrent on every software website / poll I encountered. It deserves to be in the top as an example.

Thank you. We try to keep users in mind, and it's great to hear from a satisfied user!

The quality is helped immensely by our forum testers, so we're very happy to have them.

Even the cranky ones.

And Rafi.

;)

Share this post


Link to post
Share on other sites

I'm also having the same problem where the torrent list UI sometimes isn't updating until you click the list entry. Other than that, everything seems to be working fine. No RAM issues or anything else.

Share this post


Link to post
Share on other sites
I maintained a huge list of bugs for a few versions too. Largely ignored' date=' of course, so I've given up.[/quote']

Don't give up... yet... Or, send me your list... :)

Haha here you go, sir. Follow the "year ago" link. Plus, here are the last few times I posted updates about them/new bugs:

Yeah, "Apply limit to transport overhead" is very broken. It still allows the disk write cache to balloon up, well over the maximum, like I reported, oh probably a year ago?

And the rest of those bugs still all apply.

Still makes it kaboom, but the disk cache is actually able to catch up in this version where it would just get stuck before, so... half way fixed?

http://i.imgur.com/vFIG2.jpg

You can see the gap in the graph before the disk writes start occurring. In that time the cache had exceeded its bounds (32mb) for a total of 140mb or so. It only does this with that overhead option enabled, as I've been saying since... oh.. 3.0. ;)

"Apply rate limit to transport overhead" still breaks EEEVVERYTHING to do with the disk cache. This is a longstanding bug, if you don't plan on fixing it then just remove the option. It would be the responsible developer thing to do rather than leave broken settings in for versions and versions. ;)

Also please make "Create subfo(lder)" remember its state. Every time the window pops up I have to uncheck it again since that's usually the way I want it. Thanks. :)

Just noticed the alpha doesn't seem to be respecting gui.default_del_action anymore. I have it set to 1 (Remove and delete .torrent) but my %AppData%\uTorrent folder is still filling up with files.

Edit: Seems to be because some of them are/stay locked?

Keep up the fiery spirit. :P We need someone externally tracking the bugs and holding these guys accountable considering their internal tracker clearly doesn't. :rolleyes:

Share this post


Link to post
Share on other sites

Is that all you have to "offer"?... plus 75% of it is ""Apply rate limit to transport overhead" related ... which is fixed now, IMHO... :P

Edit: not counting last year's list... yeah, they still have some serious issues, regardless... mostly cache/IO related

Share this post


Link to post
Share on other sites

Obviously last year's list is what I was referring to rafi. :/

The other quotes are updates/me demonstrating that I've repeatedly brought it up from 3.0 to 3.3 and it's been ignored.

Share this post


Link to post
Share on other sites
Download the new version here

µTorrent 3.3: Performance and streamlining headline list of improvements

...

Finally, we made a few bug fixes including a fix that noticeably speeds up the rendering of magnet links.

One question:

"speed up the rendering of magnet links" means that the torrent information is now retrieved faster?

Share this post


Link to post
Share on other sites
One question:

"speed up the rendering of magnet links" means that the torrent information is now retrieved faster?

Yes!

...

I was just came here to ask about this... The first magnet -if no other torrents are active- is being rendered fast, but if I have even one torrent active, the second magnet would be painfully slow... I mean, Turtle... It's like it goes with 0.5KB/s for long time, until I see the content... If I have 2-3 active torrents, I better not try another magnet.

Share this post


Link to post
Share on other sites

29082: Sometimes, when exiting with a newly added active download (like from RSS)- it is not being auto-resumed, when starting uTorrent again- it returns with "illegal state" . Starting the torrent - will not auto-re-check first, and will loose all torrent data. I guess resume.dat is not being stored in a timely manner occasionally ? ... Indexing issues with new torrents?

the second magnet would be painfully slow...

Did you try also with this new build?

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.