Jump to content

µTorrent 3.3 Stable


cmeisel

Recommended Posts

  • Replies 619
  • Created
  • Last Reply

Top Posters In This Topic

The program's developers have the right to recoup expenses by partnering with an advertising agent and bundling it with the software. Likewise, you have the right to use other software if you disagree with this.

Link to comment
Share on other sites

As I've stated before 3.2.3 is the last version that doesn't crash for me. So I deleted settings.dat and settings.dat.old installed 3.3.29625 and after an hour or so crashed. Trying the latest 3.3.1 beta, going to see if that crashes aswell or no. Using W7 x64, 16GB RAM, i5, don't know what else to list or do that could cause the crashing.

Link to comment
Share on other sites

*sigh* 3.3.1.29638 crashes too, I'll restate specs again: W7 x64, 16GB RAM, i5-3570k, Avast 8.0.1489 antivirus (crashes happened with v7 and other v8's), Comodo Firewall 5.10. 3.2.3.28705 is the last version that doesn't crash for me, seems anything in the 3.3 and 3.3.1 branch crashes. 3.2.3 I can leave running for days, 3.3 and 3.3.1 crash after an hour or two. I tried your settings a few versions ago, crash. Haven't run as admin, but I don't see how admin will fix it. ATM I'm not going to do admin and 3.3 or 3.3.1 b/c I'm going to leave this unattended so I'll be running 3.2.3. Let me know if you need any other specs/software.

Link to comment
Share on other sites

*sigh* 3.3.1.29638 crashes too, I'll restate specs again: W7 x64, 16GB RAM, i5-3570k, Avast 8.0.1489 antivirus (crashes happened with v7 and other v8's), Comodo Firewall 5.10. 3.2.3.28705 is the last version that doesn't crash for me, seems anything in the 3.3 and 3.3.1 branch crashes. 3.2.3 I can leave running for days, 3.3 and 3.3.1 crash after an hour or two. I tried your settings a few versions ago, crash. Haven't run as admin, but I don't see how admin will fix it. ATM I'm not going to do admin and 3.3 or 3.3.1 b/c I'm going to leave this unattended so I'll be running 3.2.3. Let me know if you need any other specs/software.

I never had good luck with Comodo and torrenting. I don't know if the newer versions are better, but I found they couldn't handle the load. Try disabling the firewall for a few hours.

Link to comment
Share on other sites

I only use µTorrent (3.3) for one particular private tracker, that's the only reason I still use µTorrent at all, it's over 1000 torrents I'm sharing and I would have to migrate them all by hand. I did the mistake to upgrade to 3.x and thought that people who were sticking to 2.0.4 or 2.2.1 weren't quite right in their head and overracting. Now I regret this...

Anyway I just tried build 29625 today with a big torrent (~42 GiB), had high hopes, but only after a few minutes or so the µTorrent process was gone. The new disk I/O is still buggy. And I still have this weird bug were any torrent >400MiB cannot be finished, blocks stay greyed out and µTorrent will stop writing out any blocks to the disk. Exiting µTorrent then leaves a ghost process running which needs to be killed with a process manager.

Link to comment
Share on other sites

...tried build 29625 today with a big torrent (~42 GiB)... µTorrent process was gone. ...I still have this weird bug were any torrent >400MiB cannot be finished

I guess you are aware that many others (including myself) do not see those issues... So, the only logical thing for you to do is see what is special in your setup/system. Such things as:

- Try with a clean settings.dat (or with mine vv ...)

- Disable/Uninstall AV/FW software

- Run-as admin

Can all help you out. Did you try any of those?

Link to comment
Share on other sites

- Try with a clean settings.dat

I did.

(or with mine vv ...)

I will try. (I hope you have all that eye cancer disabled.)

edit: Something's not right with your settings.dat. I only got 1.0 MiB/s out of it, a third of my download rate limit. At first it goes to full speed and drops down immediately again, looks like a bell curve in the graph... with Deluge the same torrent stays at ~3MiB/s...

- Disable/Uninstall AV/FW software

Don't worry, I don't have such snakeoil running anyway.

- Run-as admin

:rolleyes: Oh, why? Do Admins get better disk access or what? :lol:

BTW, now after another test with the same torrent which I delete and readded, 29625 just tells me "Disk overloaded 100 %(sic)", no disk I/O happening and no network I/O either. :lol: When I exit it, the process lingers around with no UI and ~5% CPU load, it has to be shot down. Same old story.

Link to comment
Share on other sites

µTorrent Stable (3.3 build 29625)

Connecting To Peers in Red. Seeding all slowly turning to Red. Exit, watch Task Manager to make sure µTorrent has completely quite. Restart µTorrent and everything works fine for about 24 to 48 hours (it varies some). Windoze XP SP3 Intel System. It appears to work better on Windoze Se7en.

IMHO

isepiq

Link to comment
Share on other sites

Oh, why? Do Admins get better disk access or what?
Yes

[Edited to add]

By the way;

It is not "Admins" as in the Administrator group members, but THE Administrator account. But if you know your way around Windows you can 'elevate' your user account priviliges by editing the local security policies.

Link to comment
Share on other sites

I only got 1.0 MiB/s out of it,

You need to adjust the upload limit according to your speed of cause...

Do Admins get better disk access or what? lol

Some settings - if you use them - might requires it... such as sparse_files

Link to comment
Share on other sites

Oh' date=' why? Do Admins get better disk access or what?[/quote']Yes

That's bullshit. Disk I/O is the same for every user. If anything then the process priority changes a thing although it's not directly related to disk access and even with process priorization there's no extra bonus for the Admin account. Now if µTorrent was a service and my Windows installation was set as a server and prioritize services then it would make a difference, but it's set as a workstation and thus applications like µTorrent should already get high CPU and I/O priorization.

I only got 1.0 MiB/s out of it' date='[/quote']

You need to adjust the upload limit according to your speed of cause...

Which I did, of course, along with the download rate limit.

Do Admins get better disk access or what? lol

Some settings - if you use them - might requires it... such as sparse_files

Creating sparse files is not limited to the Administrator account!:mad:

Anyway' date=' with your settings.dat I had a worse stand than before, at least no torrents froze, I assume it was because the network traffic was cut down to a third by your settings. I'm wondering anyway how a single set of rules should work wonders compared to the default settings for the whole diversity of the different internet access methods µTorrent users have. If there is any set of default settings that would work well for most users then I assume it's those default settings which the µTorrent team has built into the client. Unless you want to present some proof that their network settings are generally inferior to yours.

Anyway, I'll have to just wait until the private trackers accept a µTorrent version that finally handles disk I/O as reliable as the 2.x and early 3.x versions...

[b']Or wait... one last question: Did the resume.dat file format change from 2.0.4??? That's the only file I really need to downgrade back to 2.2.1 without loosing all my torrents. PS: OMG, yes. The resume.dat file of 3.3 works with 2.2.1! If I had only known this before!

Link to comment
Share on other sites

I assume it was because the network traffic was cut down to a third by your settings.

I assume this was because you didn't follow the guideline to adjust it per your connection rate, and test it with my "gold standard" torrent: http://releases.ubuntu.com/13.04/ubuntu-13.04-desktop-i386.iso.torrent

I'm wondering anyway how a single set of rules should work wonders...

There is no magic... This is *my* best practice. You/they can think otherwise, and do whatever they like, including selling you some offers... Plus it is not all network oriented. Read the tips... Has to do with offers removal, GUI preferences and such too...

@Rafi....

Can you let people know what edits are made in your settings.dat file especially the the advanced settings.

No, no need to, so I'm not going to bother... Anyone that likes to, can compare to the defaults for himself (all advanced changes are marked clearly with "*"), plus the settings follow what is explained in my tips/guide. Just read it.

Link to comment
Share on other sites

That's bullshit. Disk I/O is the same for every user.

Logon with a normal user account and try deleting something in the Users folder, try changing permissions in the root of the %systemdrive%

Try making an application save a file in the root of the %systemdrive% you will soon find out that YOU are WRONG!!!!

The 'mechanics' of disc I/O may be the same for all users, but the permissions and allowable scope of actions CERTAINLY is NOT!

Link to comment
Share on other sites

The 'mechanics' of disc I/O may be the same for all users, but the permissions and allowable scope of actions CERTAINLY is NOT!

I guess, than, the uTorrent is issuing the proper warnings/notifications if a user is trying to use a setting that is not allowed per his exe/account permission? or when the user installs uTorrent?

Or that uTorrent is setting the exe to the proper compatibility->privilege - level when installing it from a user account?

No? Time for a change...

Link to comment
Share on other sites

No, no need to, so I'm not going to bother...

Pre-made settings_331_1M.dat edits in the Advanced settings:

bt.allow_same_ip= *true

bt.ban_ratio= *20

bt.ban_threshold= *10

bt.connect_speed= *5

bt.no_connect_to_services= *false

bt.prio_first_last_piece= *true

bt.randomize_peer_id= *false

bt.tcp_rate_control= *false

diskio_coalesce_write_size= *4194304

diskio.minimize_kernel_caching= *true

gui.graph_tcp_rate_control= *true

gui.overhead_in_statusbar= *true

gui.show_notorrents_node= *false

gui.show_plus_upsell= *false

gui.show_status_icon_in_dl-list= *true

gui.tall_category_list= *false

gui.toolbars_labels= *true

gui.update_rate= *2000

gui.use_fuzzy_dates= *false

net.discoverable= *false

net.low_cpu= *true

net.max_halfopen= *16

net.utp_dynamic_packet_size= *false

net.utp_initial_packet_size= *8

offers.left_rail_offer_enabled= *false

offers.sponsored_torrent_offer_enabled= *false

peer.resolve_country= *true

remove.torrent_files_with_private_data= *false

rss.update_interval= *60

Explanation of each Advanced setting explained here:

http://www.netcheif.com/Articles/uTorrent/html/AppendixA_02_12.html

Super Advanced (hidden) settings:

To access the hidden settings:

-Press shift-F2 and Preferences

- Press shift-F2 and advanced

choker.interval= *232

choker.interval_auto= *false

choker.interval_optim= *255

gui.show_plus_av_upsell= *false

gui.show_plus_conv_upsell= *false

initial.install_version= *105082233

offers.lifetime_impressions_ft= *1

offers.lifetime_impressions_lrec= *2

sid1= *2

smode= *7

ssampler= *1000

ul_rate_download_thres= *5

Link to comment
Share on other sites

You see ? It wasn't too difficult, right ?...

LOL!...You are assuming I haven't compaired them before!

Being that many users haven't even ventured into the help files that it would be alittle more convenient to post 'em here.

Link to comment
Share on other sites

I downgraded to µTorrent 2.2.1 and I had no trouble downloading very big torrents. I created high disk I/O with another program so that µTorrent had a lot of "disk overloaded 100%" whenever allocating one of the big files in the torrent, but µTorrent always recovered and continued downloading. This is the part where 3.3 just stalled making any downloading impossible. Until after exiting and then killing the process and deleting or not resuming the torrent that caused it after a restart.

I may upgrade to the last good 3.x version, but honestly apart from the quicker and asynchronous program startup which is quite usefull when you have a lot of torrents shared, I don't see any real benefit of 3.2 over 2.2.1.

Creating sparse files is not limited to the Administrator account!:mad:

Citation needed.

Sparse files will only fail to be created if the user has a quota and that is not the case by default. My user account has no quota, enabling this option should work without running µTorrent as an Administrator. Besides while enabling sparse file creation may help with my problem, I actually can't be bothered dealing with 3.3 anymore, it has stolen me enough of my time already.

I assume it was because the network traffic was cut down to a third by your settings.

I assume this was because you didn't follow the guideline to adjust it per your connection rate' date=' and test it with my "gold standard" torrent: [url']http://releases.ubuntu.com/13.04/ubuntu-13.04-desktop-i386.iso.torrent

You recommended me your settings.dat and never mentioned any guideline. I have tried to adjust some settings after I noticed the 1/3 download speed, but curiously none helped, not even resetting all of the network and cache related ones back to the default. And yes, I did a restarts for the changes to take effect.

Also I've tested two very popular torrents, one having over 6000 seeders (150 in my swarm) with both µTorrent 3.3 and your settings.dat and with Deluge 1.3.6. In contrast to µTorrent the later gave me the maximum download rate I was used to.

It may be some hidden setting eventually? Apparently your settings.dat file has some non-default settings which are not accessible without special tools.

That's bullshit. Disk I/O is the same for every user.

Logon with a normal user account and try deleting something in the Users folder, try changing permissions in the root of the %systemdrive%

Try making an application save a file in the root of the %systemdrive% you will soon find out that YOU are WRONG!!!!

All of which has nothing to do with disk I/O. Apart from the fact that none of your examples matter for µTorrent, since it doesn't rely on write accessing those folders. Only during installation are higher privileges are required to copy itself into "Program Files" or "Program Files (x86)".

The 'mechanics' of disc I/O may be the same for all users, but the permissions and allowable scope of actions CERTAINLY is NOT!
Woohoo, correct but non sequitur. Since my problem is most likely cache related.
Explanation of each Advanced setting explained here:

http://www.netcheif.com/Articles/uTorrent/html/AppendixA_02_12.html

Thank you very much for the link! Many of the settings are self explainatory based from their short names even, but this "manual" helps clear things up a bit more.

Sure, I have looked at the Advanced settings of his myself. I found some of them to be quite odd, unnecessary and even harmful to performance, for example net.low_cpu and net.max_halfopen (unless you are running an outdated version of Windows and a very slow CPU), bt.no_connect_to_services (set to false... why would I want to connect to default internet services when µTorrent offers me the default option to not connect to them?!? actually that list of ports should be augmented with many more ports) or net.utp_dynamic_packet_size (so their auto adjustment code is broken, or why disable it?).

Super Advanced (hidden) settings:

Unfortunately the link you provided has no information about these settings... I can't even find much with Google.

choker.interval= *232

choker.interval_auto= *false

choker.interval_optim= *255

I have a hunch this may throttle net throughput with a big swarms.

Anyway, those settings aren't my problem, it was a mere distraction from my real problem. If this problem even persists in the next stable release of µTorrent I might look into µTorrent's advanced cache and file system settings a bit and see if any of them have any influence.

I'm aware that this is triggered by something on my system. My temporary and finished downloads are stored on a Truecrypt encrypted HDD. While straight throughput is acceptable, I doubt with many I/O requests this drive performing adequately, although my high I/O test didn't raise the CPU load caused by the truecrypt.sys threads to exceed 1%, maybe that it isn't very high, should be cause for concern? Although random seek performance of HDDs is so bad, that Truecrypt probably is able to cope.

So here's the thing I do know: until the disk I/O code rewrite of 3.3, this was never a problem for µTorrent. Having said that I also remain sceptical whether Truecrypt is one factor, I doubt it for the observations stated above but I just don't know, it could be locking up disk writes in some rare cases, but I don't know, it's all assumptions without much substance to back them up, so it's not suitable for dismissing or proving anything.

What I do have seen is that µTorrent wrote incoming blocks into memory but not flushing them to disk until it either ran out of memory and crashed. Or when the torrent was was small enough, it fully downloaded not crashing µTorrent, but only to freeze up, not getting flushed, with µTorrent hogging that extra physical memory indefinitely. Very nicely observable with Process Explorer, a linear increase in physical memory allocation by the µTorrent 3.3 process right up to the moment the download finished. The overall increase being the delta of the size of the completed torrent and the size of the parts that actually have been written to disk until the cache fuckup initiated, which usually occured around the ~400-500MB mark. So I assume it's µTorrent's fault, but I cannot say that for certain. Why could it be that µTorrent 3.3 is the only application on my system that is being denied cache flushing by a supposed bug in a system driver? Or could it be the disk cache code of µTorrent itself? Which happens to undergone a major rewrite with just the version I seem to have so much trouble with...

See, that's the part where a professional computer science major who's able to actually debug (for real!) such an issue should have a look. I don't see that happening unless I self train myself some serious debugging skills. But why should I do that when BitTorrent Inc. isn't paying me for doing their work? So I'll resort to the remaing options I have left: use an older, working version of their software or not use their software at all but software instead that does work for me, like Deluge for example.

Goodbye for now, problem solved by workaround: µTorrent < 3.3.

Thanks, Beasly for providing information!

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...