Jump to content

µTorrent 3.0 (32-bit) Stable Release


Firon

Recommended Posts

There are settings to turn all of that off.

No you can't hide the left pane completely, it keeps the mini pane with the down arrow even if you untick "show category list"

The program, taskbar icon is ugly. It was better before 2.2

The documentation is out of date :(

uTorrent is not a light client like before and there are still some problems for a "stable" release.

A lot of people are complaining on many websites about this. This is not a "u" Torrent anymore.

Link to comment
Share on other sites

  • Replies 1.4k
  • Created
  • Last Reply

Top Posters In This Topic

Unfortunately i can't use 3.0 ...

The problem is disk overloaded issue.

Now, as i run version 2.2.1 (build 25302) there is not a 1% of disk overloaded.

When i install (with or without keeping the user settings from 2.2.1), the latest version ... well my problem begins.

So, can a developer point out what exactly is strictly changed in 3.0 that manages my disks (2tb, raid 0, fast disks...), to go crazy and to get overloaded ?

Thanks for your attention

PS: Again i say, 2.2.1 - no problem; 3.0 - disk overloaded with default settings and with 2.2.1 settings. same sh!t. Thanks !

Link to comment
Share on other sites

http://img840.imageshack.us/img840/527/clipboard1j.png

Upload: 337.0MB

Download: 1.6GB

But

Process Explorer

Disk I/O Read: 2.2GB (Upload X7 times!!!)

Disk I/O Write: 1.82GB

very strange.

uTorrent 3.0(alpha, beta, RC, stable) creates diskoverload.

http://forum.utorrent.com/viewtopic.php?pid=591190#p591190

You can see in the log you have banning peer?

Link to comment
Share on other sites

clipboard1j.png

Upload: 337.0MB

Download: 1.6GB

But

Process Explorer

Disk I/O Read: 2.2GB (Upload X7 times!!!)

Disk I/O Write: 1.82GB

very strange.

uTorrent 3.0(alpha, beta, RC, stable) creates diskoverload.

I see no problem with this. Let me try to clear up things for you. Total amount of bytes read from disk is sum of From File and Hashing in Read Statistics. In your case 367/1024 + 1.58 = 1.93 GB, which is comparable with what Process Explorer provides - 2.2 GB (0.27 GB is read information for other programs). Hashing happens when you force some torrent to recheck. Surely this operation intensively reads information from disk and it happens only for checking already download information with hash table inside .torrent file and you start it manually. In normal cases uT reads from disk only if it wants to get information for peer and such number is provided in From File row. It is 367 MB in your case. Everything, what is read from file is put into cache (if it is enabled, of course), and then some chunk from cache is given to peer. From cache should show how much information uT actually passed to peers. It is 345 MB in your case. You may ask why From cache amount is not the same as From File. It is because uT reads more data from file than peer requested in order to decrease number of disk I/O operations, because there is a probability, that peer will request for that part, which was read from file. In your case uT reads 128 KB for every request and sends 16 KB to peer. There is a probability, that peer will request another 16 KB from these 128 KB. In your case such probability is super great, because From File is almost the same as From cache. I assume, that you upload 1 torrent, which takes small space, because I have never seen such high probability in for my torrents. In my tests uT usually sends 27 KB to peer for every read 128 KB. In your test it is 120 from 128. Lucky you are!

If you have read this carefully, now you understand, that uT reads more information from disk, than it sends to peers and it is done only for one purpose - decrease number of I/O operations sacrificing number of read information. The more uT reads from file for every request, the more information it will read from disk in the end. There is a new advanced option in uT: diskio.cache_stripe. It is 128 by default. If you set it to 16, then uT will read exactly the same amount information from disk (or less, if peers request some chunks from cache) as it will send to peers. So you won't have any disk overload. I prefer 64 for this value. I hope this information was useful for you. If not, you can kick me, I don't mind.

Link to comment
Share on other sites

http://forum.utorrent.com/viewtopic.php?pid=591190#p591190

You can see in the log you have banning peer?

Disk overload was fixed in RC6 and you can manually control disk usage thought diskio.cache_stripe if cache is enabled.

When i stop all 8 seeding files problem gone.

Surely it is gone, because you don't seed, and uT doesn't read any data from HDD.

Link to comment
Share on other sites

Unfortunately i can't use 3.0 ...

The problem is disk overloaded issue.

Now, as i run version 2.2.1 (build 25302) there is not a 1% of disk overloaded.

When i install (with or without keeping the user settings from 2.2.1), the latest version ... well my problem begins.

So, can a developer point out what exactly is strictly changed in 3.0 that manages my disks (2tb, raid 0, fast disks...), to go crazy and to get overloaded ?

Thanks for your attention

PS: Again i say, 2.2.1 - no problem; 3.0 - disk overloaded with default settings and with 2.2.1 settings. same sh!t. Thanks !

Please, provide a screenshot of disk statistics, while uT is actively seeding (and overloading your disk) for at least 1 minute test.

Link to comment
Share on other sites

http://forum.utorrent.com/viewtopic.php?pid=591190#p591190

You can see in the log you have banning peer?

Disk overload was fixed in RC6 and you can manually control disk usage thought diskio.cache_stripe if cache is enabled.

When i stop all 8 seeding files problem gone.

Surely it is gone' date=' because you don't seed, and uT doesn't read any data from HDD.[/quote']

Confirm, problem with overload gone i update 2.2.1 to stable 3.0 with 2.2.1 settings.

Link to comment
Share on other sites

There are settings to turn all of that off.

No you can't hide the left pane completely' date=' it keeps the mini pane with the down arrow even if you untick "show category list"[/quote']

In Preferences Advanced: gui.enable_sidebar_buttons *false

bye

Link to comment
Share on other sites

Unfortunately i can't use 3.0 ...

The problem is disk overloaded issue.

Now' date=' as i run version 2.2.1 (build 25302) there is not a 1% of disk overloaded.

When i install (with or without keeping the user settings from 2.2.1), the latest version ... well my problem begins.

So, can a developer point out what exactly is strictly changed in 3.0 that manages my disks (2tb, raid 0, fast disks...), to go crazy and to get overloaded ?

Thanks for your attention

PS: Again i say, 2.2.1 - no problem; 3.0 - disk overloaded with default settings and with 2.2.1 settings. same sh!t. Thanks ![/quote']

Please, provide a screenshot of disk statistics, while uT is actively seeding (and overloading your disk) for at least 1 minute test.

Ok, here it is:

version 3.0

http://i.imgur.com/91gbf.png

version 2.2.1

http://i.imgur.com/lPEDp.png

Thanks !

Link to comment
Share on other sites

Ok, here it is:

http://i.imgur.com/91gbf.png

Thanks !

Really, you have disk overload (3.94 MB per every request instead of default 128 KB). Are you sure, that you use uT 3.0 build 25406? If yes, what value do you have in advanced options diskio.cache_stripe?

Thank, I hope they update the doc soon. Do you know how can I hide the "Drop files" ?

gui.show_dropzone=false, although gui.enable_sidebar_buttons=false will hide drop zone too.

Maybe problem with overload fix, but why program block my local and global IP in my torrent files?

http://forum.utorrent.com/viewtopic.php?pid=591190#p591190

It can be because channel between you and peer is unstable.

Link to comment
Share on other sites

I use diskio.cache_stripe = 18

uTorrent

Upload: 52.2MB

Download: 2.8GB

Process Explorer

Disk I/O Read: 2.49GB (Upload 48X times!!!)

Disk I/O Write: 2.44GB

and

I'm going back to utorrent 2.0.4

Do you recheck torrents after installing uT 3.0? I see you have 2.42 GB hashing and I think it is because of recheck.

Link to comment
Share on other sites

I have the following problems with the tray icon [25406]:

====

I have

close to tray - on

single click on tray... - on

always activate when clicked - off

====

When I first start uT' date=' it always show the program window, regardless of how it was when I closed it last time. Then if I close the window (and send it to the tray), clicking on the tray icon doesn't work. The windows doesn't show. I have to use right click > hide/show uT. After I do this once, the tray icon starts working normally. This behaviour has been there for sometime now.

Another problem is that sometimes the program window pops up in restored state instead of maximized (I always keep it maximized). It's slightly bigger than maximized when this happens. this has been going on for a few days, but it looks random, so I'm not sure how to reproduce it or even if it happens with the latest build.

Here another user is reporting the same problem:

[url']http://forum.utorrent.com/viewtopic.php?pid=592204#p592204

Windows 7 x64, SP1

I'm the one who was reporting the similar problem, but as I mentioned on my previous post, after installing the latest version the problem is gone [for me at least]. I did nothing to the settings before and after updating. Maybe try fresh install? [backup all your settings first of course].

I have the same problem on fresh installation. The program window after a long not use - does not open the tray.

Windows 7 SP1 32bit

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...