Jump to content

µTorrent 3.1 stable (build 26671)


Firon

Recommended Posts

Always have "Disk overloaded 100 %" (on Dedicated Caviar Black 640 GB....lol)

Enough free space on your HD? Any hash fails (see in your logger tab)? Can you show the info tab and you cache settings advanced->cache/diskio.*? Can you pm your .torrent link?

Link to comment
Share on other sites

Hello.

It's really random. Yesterday, impossible to download something... Today, in the morning, all my (same) torrents finished in one shot. So I tried new couple of torrents (same sizes, same disposal...) and since 20 min, nothing happens (apart "Disk overloaded 100%" problem). My 46 GB of "empty" downloading files are written on the disk...

(WTF about Cache ???) : (Open in new tab for complete view, please) :

dalfjaadh.jpg

Always have "Disk overloaded 100 %" (on Dedicated Caviar Black 640 GB....lol)

Enough free space on your HD? Any hash fails (see in your logger tab)? Can you show the info tab and you cache settings advanced->cache/diskio.*? Can you pm your .torrent link?

Yes' date=' > 400 GB free. (Downloading tests about < 50 GB)

My example was with less than 10 torrents, each between 1.5 and 10 GB. Torrents with between 1 and 5 files, Files are single-files between 1.5 and 4 GB. So a total about of ~40 files

No hash fails errors, even no errors at all in the logger tab.

Look at info of one torrent : (Don't look total size of the torrent, only downloading a little part) :

(Open in new tab for complete view, please)

[img']http://image.bayimg.com/calfkaadh.jpg

Disk Cache settings are the default ones. Never changed :

calflaadh.jpg

Sorry for .torrent(s) but it's private :/. Maybe I'll try on public trackers but don't think that this "Disk overloaded" problem is .torrent related, do you ?

Thanks for you help.

Cheers.

Link to comment
Share on other sites

Maybe I'll try on public trackers but don't think that this "Disk overloaded" problem is .torrent related, do you ?

I can only speculate... so, it's better to try and isolate the issue. I see two things:

1. it is a file from a very "large" torrent - 3G / 78G

2. you cache settings are different then what I use... (but are the defaults)

3. you did not show your advanced->diskio.* settings

So, if you can give an example of a similar-public torrent - that generate for you this issue - it would be best.

Plus - you can try and use my settings... see if it helps: http://forum.utorrent.com/viewtopic.php?pid=622260#p622260

Edit:

OK, I've noticed this here once. As in your case, it showed just a bit above the set cache size (32M in your case). I've also noticed that when it happened, the cache status tab - actually froze, and did not refresh. Did you noticed that too? Maybe it is just a bug with a frozen GUI refresh ?

(on Dedicated Caviar Black 640 GB....lol)

External / USB ? Internal ?

Might be a bug here related to handling of torrents with very large sized content (~80G).

Link to comment
Share on other sites

@Domokun: there is no change in text, so build 26591 is still valid there (same txt for 26591, 26595, 26616).

Not for me, the 'Show\Hide Plus Information' strings are still in English because the build version hasn't been bumped to 26616 yet.

EDIT: Seems to be working now (on XP at least).

Link to comment
Share on other sites

With the latest version you can't even create a correct torrent file.
I've created two' date=' with no issues. But I'll try a third one...[/quote']

I reported the bug earlier and you confirmed it. ( not a bencoded file bug )

LE: Let me be clear about this issue. No tracker accepts the torrent file created with the latest build of utorrent 3.1. This wasn't an issue until this latest build.

Link to comment
Share on other sites

What I confirmed (at least that was what I meant ...) was not being able to skip bad torrent files with the auto-loader. Not how they became broken... :) I got my broken torrents from the Internet... :P

If I understand you correctly, you now claim, that those were created badly for you by uTorrent.

Link to comment
Share on other sites

Yes, that's what I want to say. Created the torrent file 10 times and then created another ten different torrent files and the result is the same. No tracker accepts them with this error. I compared them with the ones made with 2.2.1 for example, and they have some differences that may be to blame for this behavior. uTorrent opens them fine, but you can't use them outside uTorrent by uploading to a tracker.

Link to comment
Share on other sites

Don't know if this is right place to post this but latest version does not work on Demonoid ie cannot create torrent.

How can you not create one? It works fine on Demonoid for me.

uTorrent opens them fine, but you can't use them outside uTorrent by uploading to a tracker.

Worked for me. 3 torrents, 3 trackers.

Link to comment
Share on other sites

During 1-2 hours was blocked with disk overloaded / few kBps (not really downloading) and suddenly started to download but as always when it downloads few disk overloaded (evry 2-3 min and happens only 4-5 sec but with high CPU usage)

DiskIO settings : (default options) :

kalgmaadh.jpg

There are "Basic Cache Settings" and "Advanced Cache Settings" in Disk Cache and Super Advanced Cache Settings in Advanced / diskio.x... confusing.

Now, have 100 mbps connection so problem is more problematic.

Just saw this "disakio.low_prio_disk" going to check thus with set as false.

I tried to switch back for 2.2.1 (Stability and Minimalism) VS 3.x (New features, GUI and network optimizations)

But for me, 2.2.1 has disk overloaded problems too !

Periodic hanging and lost of network speed during "disk overloaded" (very often) was always an issue but now, this new problem that prevents me bluntly that the download starts ...Worse and worse ... arrrggh.

I bet for a Cache problem or Writing issue (bad implementation) with uT or Windows because Network works fine, HDD is in free / waiting of use.

@ rafi and masca90020 :

Going to try your settings guys. Thanks.

@masca90020 :

About "Pre-allocate all files", saw in the help file : "Pre-allocate all files tells µTorrent to create and fully allocate every file you select to download immediately after starting the torrent job. Note that this option does not have an impact on hard drive fragmentation (advantageous or otherwise), as µTorrent already allocates each file upon writing to disk even without this option."

Don't see why there is this option (disabled by default ?!?) of this option / checkbox, as it said, isn't activated by default in uT (I mean, when adding torrents, zero-filled files are automaticalyl created, isn't it ?)

Thanks guys for the help.

PS: Downloading since more than 3 hour at full speed, few hangs from few sec but it's all ! Really strange...

Link to comment
Share on other sites

Maybe I'll try on public trackers but don't think that this "Disk overloaded" problem is .torrent related' date=' do you ?[/quote']

I can only speculate... so, it's better to try and isolate the issue. I see two things:

1. it is a file from a very "large" torrent - 3G / 78G

2. you cache settings are different then what I use... (but are the defaults)

3. you did not show your advanced->diskio.* settings

So, if you can give an example of a similar-public torrent - that generate for you this issue - it would be best.

Plus - you can try and use my settings... see if it helps: http://forum.utorrent.com/viewtopic.php?pid=622260#p622260

Edit:

OK, I've noticed this here once. As in your case, it showed just a bit above the set cache size (32M in your case). I've also noticed that when it happened, the cache status tab - actually froze, and did not refresh. Did you noticed that too? Maybe it is just a bug with a frozen GUI refresh ?

(on Dedicated Caviar Black 640 GB....lol)

External / USB ? Internal ?

Might be a bug here related to handling of torrents with very large sized content (~80G).

Yeah, I think it's definitely not specificaly related to.torrents (only the size matter).

I'm pretty sure it ALWAYS happens but more data are bigger more the problem is bigger...

Try with PBay, "1080p" (like collection / set / box).... Difficult to say... not always the same facts happens... Somtime it's OK... sometime not....

About my HDD, it's a pretty "good" one. No problem here. (Internal, SATA, handle easly > 100 MB/s + good access time...for an HDD).

Link to comment
Share on other sites

I did a little test.

Added < 10 torrents (some 1080p collections) between 25GB - 200 GB), selected only few files (for a total about 50 - 100 GB), uT started to write on the disk, disk overloaded, I exited uT after 2-3 min (so nothing downloaded, less than 1 MB !). As it was writing files to the disk the process was still here writing on the disk... But even after 20 min (for now when I'm writing...)

So I looked with "Process Monitor" and "Resource Monitor "

Here you are the result (if it speaks to someone...say me what it means lol) :

Open in a new tab to see the whole picture please. Thanks.

diskioutexit2.png

So personnal question, why uT use a .dat file (partially downloaded data I think) but what's the difference between this file and the real "zero-filled" files ???

Another question is, why uT stop downloading when the disk is overloaded ? Why not continue and keep data in RAM or whatever, it sucks that every overloaded issue you loose all "the speed" and stop downloading...

As you can see there is a huge problem in the file I/O implementation in uTorrent 3.x (3.1 here).

About < 1 MB / min. I understand why some new downloads" doesnt' start"... Between cache problem ? and slow writting perf...

EDIT: Proccess has exited,about 20 min for 15 MB ! (.dat file).

EDIT 2 : Each time I see an extended "Disk overloaded 100%", I see in the write stats, Cache (example :) 35 MB of 32 MB (first number always bigger). GUI issue ?

EDIT 3 : I uploaded a DUMP file (uTorrent.DMP). 143.89 MB. When it was hanging with an extended "Disk Overloaded 100%" issue.

Here you are : http://www.multiupload.com/XC7U4ZPSD9

Cheers.

Link to comment
Share on other sites

Another question is, why ...
The answers is - there is a bug... :)

You screenshot - gave me an idea, and I think I have a hunch what the issue can be. I remembered this bug fix:

-- 2011-10-21: Version 3.1 beta (build 25835)

- Fix: Hang writing partfile for multifile torrent containing a file > 4GB

And my hunch is that they did not close all the corners with this fix... :P

TO prove that - just configure: pref->advanced->diskio.use_partfile to false, close utorrent, delete *utorrentPartfile*.dat files, start a *new* torrent, and see if the problem is gone... I should have guessed that a while ago... :(

Link to comment
Share on other sites

For me with 3.1 two issues were introduced (tested only Builds 26595 and 26616):

1.) When a torrent finishes, it's moved from one HDD to another. The status column then is stuck in status "Moving..." most of the time, in a few exceptions it switches to the correct status (mostly after at least an hour). The files are moved correctly though.

2.) After quite some runtime/ uptime (usually 2-3 days, sometime less), utorrent just plain hangs. It does exactly nothing and I have to force-close it by taskmanager.

If I have some time to spare I'll try to fetch a crash-dump next time, but for now I'm back to 3.0 to get my torrents.

OS is Win XP pro, 32bit.

Link to comment
Share on other sites

I've done 2 things:

1. Removed DC role from the server uT is on.

2. Moved to build 26616.

Now I don't get "Disk overload 100%" message (at least didn't yet).

Maybe I've run out of physical memory so "Disk overload" was related to the disk swap file is on? But v2 worked fine, though...

Added: I doubt about running out of physical memory. In fact, I almost run out of it again - it is eated by uT and Mozilla mostly. But no "Disk overload" occurs. So the issue might be related to DC role.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...