µTorrent 3.3 beta

[ziunim]

3.3 Alpha b28038 - do not stop at requested upload speed limit (bandwidth settings or global upload rate limit), its going for the maximum upload speed (of the modem) and clogging the network

[rafi]

Do you have limit local peers + limit uTP - enabled?

[ziunim]

Do you have limit local peers + limit uTP - enabled?

yes both are

[kovnsk]

This is an alpha (expect bugs!) of µTorrent 3.3, where we've rewritten some pretty major, problematic sections of code. The biggest of these rewrites was disk i/o, to improve overall performance at both low and high speeds, whether writing to local disk, a RAID or a network drive.

The I/O subsystem rewrite fixed a VERY annoying longstanding bug with uTorrent that made using it impossible :3

Please try it out and report any issues. As I mentioned before, this is an alpha, so there could be hangs, crashes or other problems.

labels and folders:

there are several bugs, but I'll explain them separately

1. "default" labels cannot be renamed, or deleted from the column on the left, once the feature "labels and folders" was triggered - on/off. Even after you disable it - labels stay.

also, now I have corrupted name in label, i don't know how, but it appeared only after I played with this new feature.

see screenshot

http://dl.dropbox.com/u/61108/Untitled.png

2. if you happen to delete the default labels first with [-] - then you won't be able to delete defaults paths afterwards.

You need to re-create the labels again to match the path below to delete the path...

Mostly the fact that I can't remove those labels (see screenshot) bugs me the most.

These bugs were reported almost 5 months ago and the situation is still the same... The labels/folders control panel is completely broken.

[rafi]

Do you have limit local peers + limit uTP - enabled?

yes both are

Confirmed The upload limiter seems to be totally broken now! and it is also slower in seeding (or keeping them connected)

[COOLBOND]

same problem here "ziunim"

[BMW-X7]

yess you are right guys upload limit does not work :/ :/

[Presence]

3.3 Alpha b28038 - do not stop at requested upload speed limit (bandwidth settings or global upload rate limit), its going for the maximum upload speed (of the modem) and clogging the network

Confirmed.

http://forum.utorrent.com/viewtopic.php?id=124850

I am surprised few have picked up on this.

[martix]

Um... quick question.

Since I trust you guys with the labeling and for me an "alpha" build is a wee bit too early to adopt, with the nearing of the 3.2.1 release(being at RC2 already), do you feel this is worthy of being upgraded to beta?

[rafi]

do you feel this is worthy of being upgraded to beta?

No, I don't think so, cause it is not that stable , and with major issues.

But... I guess they'll do it anyways...

[mistaknly]

This is just feedback to confirm that 3.3 Alpha (build 28038) has issues with upload speed limits. I upgraded from (build 27994) were the limits worked fine.

When I first upgraded it worked for a while, but I was screwing around a lot changing everything and I thought maybe just overdid it. So there "could" be a data corruption issue with upload limits but I'm not sure.

I reinstalled (build 27994) over the top of (build 28038) and limits are functioning correctly. So I didn't in fact have to delete my settings.dat file to get limits to work again.

Also, I can confirm that on a single core (P4) processor, that the cpu is indeed running right around 30% for 3.3, without any additional apps running.

Other than that, it's looking good for me. Keep up the great work!

[osm0sis]

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?

[mistaknly]

More allegorical feedback, well worth the 2 cents you paid.....:/

I have no specific firm data, but after a couple of heavy weeks of testing I've found that the 3.3 family is better optimized to take advantage of speed and it seems better at shaping traffic when you select bandwidth (high, normal, medium) for particular downloads although all versions could do better at this (without hand setting limits that is).

I have a connection that will allow on the order of 80kBs with bursts up to 104kBs with nothing else happening on the local network. The built in F5 test shows I should be using 70kBs as a "set" speed. 3.3 has been optimizing the openings and "pinning" the upload to all available bandwidth and readily adjusting downward if there is any other traffic on the lan or any use on the computer.

This is in comparison to 2.2.1 which is extremely low cpu, and very efficient but it does not use both the upload and download possibilities anywhere near as well. It acts as though I hand selected an upper limit (below my peak) and it just sits there running happily along at a somewhat reduced rate in comparison.

That behavior is fine unless you're on a private tracker and your doing everything in your power to seed to get your ratio.

So, somewhere after 2.2.1 things are looking better for network efficiencies?

Data (somewhat non-scientific). 2.2.1 runs a little less than 50kBs with sometimes approaching 60kBs. 3.3 (the 2 new builds) runs well over 60kBs and mostly at least 70kBs with bursts rates sometimes reaching 104kBs (rare) and ofter above 80kBs for short stretches and readily accounts for other computers on the lan and then readjusting up pretty fast when they get done.

(PS, sorry I can't test the other earlier "3"s because of my old machine not tolerating the "disk" issue.)

(PSS, all settings concerning DHT, PEX, etc., etc. are the same. I mostly have all that turned off except in special cases.)

(PSSS, is this type of feedback useful?)

Thx

[Lord Leks Darkmind]

at last!! torrent name search. just to put a switch to replace web search gui with torrent name search... thank you!

ps: there`s some speed optimisations as well, aren`t there?

and i have a Q: how utorrent tolerates large number of connections? (max allowed 3000?) (reason of the Q - i have a lot FORCED seeding torrents... as i understand they`re supposed to be active all the time, so all of them should have at least 1 connection... or i`m missing something?

[rafi]

- Feature: Added a ctrl-f torrent filter, hit escape to close it

Can you make the hotkey closing for control-f user-definable ? I use ESC globally in my system... so, it cannot be closed now ...

Or, maybe just hitting control-f a second time ?

just to put a switch to replace web search gui with torrent name search...

+1. You might want to make it a bit larger, relocate it to the left (a the right end of the toolbar) and add searches history to it.

Either adding a checkbox to enable/disable internal search OR adding a fixed "Internal search" line in the drop-down list can do the search switchover trick...

[rafi]

Constant 10035 errors in the log (upnp is enabled) ... :

[2012-10-06 07:42:46] 218.186.26.207:29991 xxx: Disconnect: Peer error: offline (timed out)

[2012-10-06 07:42:48] recvfrom ERROR: 10035

[2012-10-06 07:42:48] 220.233.39.72:42809(xxx): Disconnect: Peer error: offline (timed out)

[2012-10-06 07:42:48] 221.146.171.240:11657(xxx): Disconnect: Peer error: offline (timed out)

[2012-10-06 07:42:55] recvfrom ERROR: 10035

[2012-10-06 07:42:55] recvfrom ERROR: 10035

[2012-10-06 07:42:55] recvfrom ERROR: 10035

[2012-10-06 07:42:56] recvfrom ERROR: 10035

http://forum.utorrent.com/viewtopic.php?pid=659852#p659852

UPload limiter - still seems to be broken. Changes in the limits do not take affect.

[DevOps]

The latest build of Utorrent i.e. 3.3 alpha is crashing on Windows XP SP3.... when running on portable mode i.e. Settings.dat file in same directory.... Utorrent beta 3.2 is working fine.... IS this because you are using Visaul Studio 2010 compiler for compiling utorrent????

Please help

See:-

[DevOps]

[Lord Leks Darkmind]

and speed limiter (per torrent) still broken. (didn`t set global, din`t test with global)

[rafi]

din`t test with global

I did. The upload limiter is still broken. Back to latest stable...

Edit:

After further testing - it seems that most of the times - the "limit overhead" option does not work.

Edit2:

I take it back... The limiter totally breaks after a while...

[rafi]

- Feature: Added flags for optimizing disk IO

Which ones? and in what way?

[bitbyte]

3.3 Alpha b28120

Force Re-Check does not appear to read the actual file on the disk when rehashing.

I've not done extensive testing, but I had a 100% completed torrent with an ISO image that I believed was corrupted/incomplete. This completed torrent resides on an NAS.

I did a Force Re-Check and uTorrent found no errors. The recheck sped thru too quickly for it to be read off the NAS so I decided to rename/removed the ISO file in question and did another Force Re-Check. uTorrent re-allocated the file and returned the torrent as 99.9% complete with 1x 4Mb piece missing. I start the torrent and it downloads the "missing" piece, reports 100% complete and starts seeding. Doing another Force Re-Check returns no errors and 100% complete. I open the raw file and it's an empty file filled with nulls.

I replaced the original file back and decided to try using 3.2.1 RC2. Force Re-Check was slow as it actually did read the file off the disk. It eventually did find and logged "No longer have piece: xxxx", which I had suspected in the beginning.

[rafi]

Force Re-Check

confirmed to not work properly... (Win7/x86)

[Lord Leks Darkmind]

lots of torrents are now frozen in tracker->updating status, seems like never changing to offline or running timers... (forced seeding) is it just me?

[osm0sis]

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.