µTorrent 3.1 stable (build 26671)

[Ben91]

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...

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.

Thanks.

[GCRaistlin]

Got "disk overload 100%" again. Bad, bad...

[rafi]

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

[Ben91]

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

[nothingSoStrange]

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..

Tnx.

[rafi]

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...

[jbebad]

A work-around would be 2 active with the rest queued up. Then when 1 finished, 1 of the queued would take its place - until no more were active. Of course if both completed at the same time - well.......

[NapoTheGreat]

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

[NapoTheGreat]

also there is an annoying problem when trying to rename a torrent in utorrent

u click once rename it click elsewhere and u get a different name from a random torrent

the result is u lost the name u tried and u have 2 torrents with the same name 1 of them is wrong

[wizz]

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

http://www.megaupload.com/?d=H2HDKKTM

Incorrect torrent

http://www.megaupload.com/?d=1QLS2CLU

[hjhjhj]

How to use fl in magnet URI ?

http://.............torrent doesn't work

[DreadWingKnight]

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.

If the values are encoded properly according to the bencode specification, the bug is in tbdev, and not in uTorrent.

[masca90020]

The problem is in tbdev, because tbdev does not accept negative values inside a torrent file. File-media sometimes contain negative values, like here:

So, the trackers should fix this. Post on their forums. I did the same and they fixed the problem on the trackers I use.

[MirceaForce]

diskio.smart.hash

need to be improved when down/uploading at high speeds

[rafi]

diskio.smart.hash

need to be improved when down/uploading at high speeds

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

http://forum.utorrent.com/viewtopic.php?pid=622260#p622260

[MirceaForce]

diskio.smart.hash

need to be improved when down/uploading at high speeds

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

http://forum.utorrent.com/viewtopic.php?pid=622260#p622260

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

[rafi]

@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?...

[MirceaForce]

@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

http://answers.yahoo.com/question/index?qid=20111214195531AAiAL0h

problem is utorrent 3.1 26616 need to be improved

[rafi]

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

[MirceaForce]

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 :

1GB

2GB

500MB

1.5GB

1.1GB

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

[rafi]

diskio.smart.hash

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.

[bt_holio]

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

UPDATE: OKAY HERE IS 3.0 WORKING FINE

[rafi]

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.

http://forum.utorrent.com/viewtopic.php?pid=622260#p622260

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

[masca90020]

Is there any chance for the RSS component to be rolled back to 2.2.1 code ? I'm tired of mini-hangs when adding some feeds that used to work fine until 3.1.

[rafi]

Is there any chance ...

Unless you give specific details (example feed) - I don't think so...