Archived

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

Firon

µTorrent 3.3 beta

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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... :P

Share this post


Link to post
Share on other sites

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!

:D

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
- 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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:- gJFCd.png

Share this post


Link to post
Share on other sites
din`t test with global

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

Edit:

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

3040a7213775686.jpg

Edit2:

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

f3faa7213779218.jpg

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


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