Jump to content

µTorrent 3.1 stable (build 26671)


Recommended Posts

Another question is' date=' why ...[/quote'] 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... :(

But sorry, I'm lost, is it normal when adding "big" torrents (ex 5x 20 GB = 100 GB), it takes about 30-40 min to start downloading because of Disk overloaded, then with standard Disk overloaded (often several times a minute, if it's a 100% overloaded, can last more than 10 seconds, causing a cut of the download speed) ???

With pref->advanced->diskio.use_partfile to false :

And what happens with uTorrent ? Is it normal this situation :

1) When add a new torrent, immediately create files with final size. (few seconds)

2) Add some data (what are they ? zero-filled ?) in the files (about ~3 GB / min processed so it requires about 30 min for 100 GB), normal step ?

3) Start download when all torrents have completed steps 1 and 2. Normal "Disk overloaded" issues.


Link to comment
Share on other sites

haaaaa !!! Some news !!

With pref->advanced->diskio.use_partfile to false :

As reported in post #202 http://forum.utorrent.com/viewtopic.php?pid=626338#p626338

With pref->advanced->diskio.use_partfile to true :

Same procedure as #202, reminder :

when adding "big" torrents (ex 5x 20 GB = 100 GB)

In 10-15 minutes, as Process monitor shows :

- only one 7 GB *.mkv has been created (I guess "step 1" from #202)

- Then during 10 minutes (!) : a *PartFile*.dat from another torrent has been created / filled with a size of 6 MB only !

- Now it created two other *.mkv files (few seconds)

- New .dat file, same speed as before < 3MB in ~5MB

- uT continues to write on the .dat and create the empty final files

In the uT GUI, same behaviour (true and false) :

- No download (speed near < 10 kB/s)

- "Disk overloaded 100%"

Conclusion ?

Except that to write final files the speed is about 3000 MB / min and when it comes to write in the .dat files (if PartFile is set as true) the speed is about 0.6 MB / min (5000x slower... WTF and why ?)


1) - yes if you have general->pre-allocate file - checked

2)- no idea.

3) - no, you should not have overload unless your cache is full up (due to slow disk or very fast speeds) ...

it's why I asked before...

By default it's unchecked and I have it unchecked... but it always create empty files.... it's not clear...

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 ?)

Link to comment
Share on other sites

About the Auto-Shutdown: how should it work? I mean, I have files queued to download, the option "shutdown when downloads complete" is activated and, as soon as just the only one file in download ends, the pc is shut down.. while a second file becames "downloading" :\ - shouldn't it wait for the new current file to finish the download? and so on for all the queue?

Just wondering..


Link to comment
Share on other sites

About the Auto-Shutdown: how should it work? I mean, I have files queued to download
This is a good point. It SHOULD stop as soon as there is no active download. In your case - it is when your only download is stopped. It is not waiting for the QUEUED ones. I think it should, tho...
Link to comment
Share on other sites

I think we fixed that, but it can still happen with certain combinations of settings (as an unavoidable problem). You'll need to UNCHECK the bypassing of the Windows write cache to guarantee it never happens.

and the response

Just tested uTorrent 3.1 RC11 which is marked to become the next stable release.

The problem still hasn't been solved.

I haven't been able to do the MAME Titles test without getting wrong sized (padded) files, no matter which cache setting I choose.

any news about that issue?

thanks for ur time

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.

This is partly correct. The problem is at video torrents that is not rar-ed. ( as far as i figured out )

There is 2 new statments inside the torrent file : file-duration and file-media. Torrent files that contain those 2 are not accepted by any tbdev standard bdenc script, so cannot be uploaded.

This is a major problem and must be resolved

I attached 2 example torrent files, both created with ut 3.1 :

Correct torrent


Incorrect torrent


Link to comment
Share on other sites


need to be improved when down/uploading at high speeds

How much is "high" ? Did you try the default settings + my 'adjustments' ?


90mbs down / 90 mbs upload booth at the same time

with utorrent 3.0 no problems but with this build 26616 problem appear.......please fix this

Link to comment
Share on other sites

@mirceaforce: have you at least tried what I've suggested in my link/cache settings? Or do I have to write it all over again?... :(

I will try them out...the problem appear at some torrents.......not all of them.....tested with ver 3.0 everything it's ok

look here


problem is utorrent 3.1 26616 need to be improved

Link to comment
Share on other sites

to improve it we need to focus/isolate the issue more. And the information you provide for that - is minimal :(

when you upgrade something you improved the quality of that.........maybe you can look at the older version 3.0 to see those settings.......

the information it's like this

When you are downloading a torrent like I said not all of them have that issue

the torrents that are making the problem have multiple large files

for ex :






total capacity around 5.1 GB if down high speed uploading slow down.......I have called my ISP provider and everything it's ok

tested with utorrent 3.0 last build

this problem need to be fixed

Link to comment
Share on other sites


need to be improved when down/uploading at high speeds

Look Mr., this was you problem description. It says nothing as to what the problem even it !!! Why don't you try to just start over and tell us, in a simple way - what the hack IS your problem? And please provide a screenshots (3.0 & 3.1), and your exact settings in both versions.

Link to comment
Share on other sites

disk cache not working bye bye hdd

writing way to often almost constantly at 1.3MB/s

tried default and max delay setting i have used for over two years no change

tried as admin also no change

got the RC to work when i played with some settings that didn't make it into release

back to 3.0 for awhile i guess




Link to comment
Share on other sites

got the RC to work when i played with some settings that didn't make it into release

What were those settings exactly?

Plus, I see an OK 1:15 ratio between # of writes to disk and to cache. I suggest you try my modified settings, see if it helps.


Changing the defulats is the easiest thing to do, either for or the devs...

Link to comment
Share on other sites


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

This topic is now closed to further replies.
  • Create New...