µTorrent 3.1 stable (build 26671)

[osm0sis]

Where did the send file icon option disappear to in 3.1?

Will be replaced by Share in a later version I imagine; check 3.0.1 if you want to check out Share.

[rafi]

Have you tested at 10MB down/11MB upload' date=' with 128 MB override cache ???? or at this speeds you need more cache????[/quote']

Not yet... But I intend to.

I believe that if there are no bugs, the user defined cache is useful only for temporarily "smoothing" things and letting other apps work better. If you run uT alone (for testing), it should work well also with practically minimal cache (long term). It should not affect it's *average* speed. If not - it is buggy...

Well, after checking it up - my conclusion is that unfortunately there seems to be bugs, that cause downloads to effect the uploads. It CAN do 10MB both ways (128M cache) , and I've seen it. It just does not sustain it for long in many cases, due to bad interaction of the download with the upload.

1. Setting a download limit seems to sometimes decrease the upload rate t0 close to zero

2. When two torrents are active - one downloading and the other uploading - it seems that once the download starts to increase and fill up the write cache - the read cache does not maintain the preset size and is being reduced to close to 0.

Well, I guess it is back to the cache drawing board after the holidays No sense to test anything till they fix the root bugs.

http://img585.imageshack.us/img585/8871/readcachecorrupted.png

[DeathStalker]

Hi Rafi!

I changed the settings and *so far* no lock ups. I will try doing some disc-intensive moves and such.

Also, what about just setting the cache to the full 1800mb? (That's what I have it set at).

[rafi]

I think that whatever you set it to - is fine Just that less memory is left to other apps...

[MirceaForce]

Have you tested at 10MB down/11MB upload' date=' with 128 MB override cache ???? or at this speeds you need more cache????[/quote']

Not yet... But I intend to.

I believe that if there are no bugs, the user defined cache is useful only for temporarily "smoothing" things and letting other apps work better. If you run uT alone (for testing), it should work well also with practically minimal cache (long term). It should not affect it's *average* speed. If not - it is buggy...

Well, after checking it up - my conclusion is that unfortunately there seems to be bugs, that cause downloads to effect the uploads. It CAN do 10MB both ways (128M cache) , and I've seen it. It just does not sustain it for long in many cases, due to bad interaction of the download with the upload.

1. Setting a download limit seems to sometimes decrease the upload rate t0 close to zero

2. When two torrents are active - one downloading and the other uploading - it seems that once the download starts to increase and fill up the write cache - the read cache does not maintain the preset size and is being reduced to close to 0.

Well, I guess it is back to the cache drawing board after the holidays No sense to test anything till they fix the root bugs.

http://img585.imageshack.us/img585/8871/readcachecorrupted.png

They need to fix this as quick as possible.........I was right when I said it's a cache bug with utorrent 3.1 build 26616 .........hope the devs will see your post or maybe you can report to them directly

have a nice holidays

[rafi]

maybe you can report to them directly

Yeah, I'll email them. I may run it in 3.01 too, Not so sure it wasn't already there... Also the cache max size is being increased again after a while, so I'm not sure it is not just a "by design" behavior. If so - I guess they should consider changing it...

[DeathStalker]

One thing I have noted since the changes, while my upload speed is still strong & steady, my download speed is completely in the toilet

[MirceaForce]

maybe you can report to them directly

Yeah' date=' I'll email them. I may run it in 3.01 too, Not so sure it wasn't already there... Also the cache max size is being increased again after a while, so I'm not sure it is not just a GUI issue.[/quote']

Until we will have a good version of utorrent 3.1 I will go back to 3.0 last build........did you use the same cache settings in ut 3.0

diskio coalesce write size-4MB

what about disable write cache the last option ut 3.0 didn't have any problems with this ??????

[rafi]

yes, I used the exact same settings. But I ran 3.01, not 3.0. Maybe it was a mistake to do so.

[MirceaForce]

yes, I used the exact same settings. But I ran 3.01, not 3.0. Maybe it was a mistake to do so.

Did you use disable write cache in ut 3.0 ????

[DeathStalker]

Any ideas on why the DL speeds and connections suddenly tanked?

[rafi]

maybe lack of proper upload limit, that also includes your overhead?

maybe your ISP has something to do with this?

maybe bugs ? ....

how should we know ... ?

[DeathStalker]

No, as I said, the only changes I made were the ones you directed. Prior to that, my connections and speeds were fine. Nothing to do with the ISP.

[m6koit]

I hope 3.1 will resume download without starting at zero each time I restart my computer.

[DreadWingKnight]

Stop shutting it down improperly.

[MirceaForce]

I have a question what does it mean diskio.coalesce_write_size ???? and what does it do????

I have tested my self with utorrent 3.0 (diskio.coalesce_write_size-2MB default) with high speeds down/up simultaneously.....some people say that 4MB would improve speed ......I have test this also but no improvements.....maybe it would improve something but I haven't seen what ???? the admin Ultima said that bigger diskio.coalesce_write_size will cause problems (Setting the coalesced write size too high will probably result in this error. In fact, even a size of 4MB is already causing errors for many users (which is why it had to be lowered to 2MB default), so I wouldn't expect you to be able to set it too high anyhow.)..proof here:

http://forum.utorrent.com/viewtopic.php?id=48238

[Ondoy]

Version 3.1 stable (build 26616) still hang after count to 1 second, I was try on all option.

[rafi]

Did you see any mention of it being fixed in the changelog ?... So what are you complaining about it...

"standby/hibernate" are, still, doing fine...

[zdnko]

How about a native file browser?

When I click uBrowse it constantly uses 100% of one CPU core and fills my RAM (1.4GB private memory is the most until now). Plus it's really unresponsive. It froze uTorrent once so I'm not using it anymore.

Specs: Win7 x64' date=' CPU AMD 2x3600MHz, 400 torrents in list (40 active).

PS: I'm glad this is finally implemented, but if it's not usable with many torrents, what's the point?[/quote']

Still present with 3.1 build 26593 (vista32 on Q6600):

http://img33.imageshack.us/img33/4081/ubrowse.th.jpg

Use the uBrowse app. We'll have the native functionality eventually in 3.0.

Are you sure?

bye

[NapoTheGreat]

is there a response to the questions i posted some days ago?

multiple times posted the problems no answer

http://forum.utorrent.com/viewtopic.php?pid=626484#p626484 … 84#p626484

http://forum.utorrent.com/viewtopic.php?pid=626486#p626486 … 86#p626486

thanks for ur time

[jbebad]

Napo the Great - The issue was answered in another topic. I think in previous versions, depending on how you had set sorting, the focus was on the row not the content of the row, so when the row changed (in the main screen) the content in the tabs below would change. An example would be if you selected a row in the downloading cat, switched to the seeding cat, the tabs below show files, etc would clear because the row that was selected under downloading lost focus. That same thing would happen if the row you selected moved its location in the grid. So you have to make sure the order of your main grid did not change while you were/are trying to rename/relocate a file on the files tab. I do not see this problem in the latest verson, (Although there can be a problem when you are going to change/rename/relocate a bunch of files and the order of the grid on the files tab re-orders the list on each change - when the change is actually performed - and you renaming/relocating faster than uTorrent can perform the actual task. I have had to slow down and wait for uTorrent to change the name/location.... so I could then go on to the next one.)

[NapoTheGreat]

Napo the Great - The issue was answered in another topic. I think in previous versions, depending on how you had set sorting, the focus was on the row not the content of the row, so when the row changed (in the main screen) the content in the tabs below would change. An example would be if you selected a row in the downloading cat, switched to the seeding cat, the tabs below show files, etc would clear because the row that was selected under downloading lost focus. That same thing would happen if the row you selected moved its location in the grid. So you have to make sure the order of your main grid did not change while you were/are trying to rename/relocate a file on the files tab. I do not see this problem in the latest verson, (Although there can be a problem when you are going to change/rename/relocate a bunch of files and the order of the grid on the files tab re-orders the list on each change - when the change is actually performed - and you renaming/relocating faster than uTorrent can perform the actual task. I have had to slow down and wait for uTorrent to change the name/location.... so I could then go on to the next one.)

thanks for ur responce

how about the other problem with the corrupted files that utorrent creates?

[jbebad]

NapoTheGreat: I do not see any of your posts that reference a "corrupted files". I have never experienced that type of problem. Explain what your problem is again - in detail.

[NapoTheGreat]

are there any news regarding this issue described here

http://www.pleasuredome.org.uk/index.php

http://forum.pleasuredome.org.uk/index.php?showtopic=17928

firon

The files themselves all have "good" data, but they're padded with garbage (usually zeros) after where the file should end. In theory, the zip files will work anyway, but clrmamepro will definitely complain about them being wrong. A simple truncation to the correct filesize will fix the files.

A force re-check does not fix the problem, since µTorrent does not truncate files, ever (which is probably a bad thing).

We're investing to see how we can fix the problem. Unbuffered writes in Windows have a limitation where filesizes must be an exact multiple of the block size, so you need to open it in buffered mode to create it, then drop back. Unfortunately, this sporadically fails, so it ends up having to create the file in buffered mode.

thanks for ur time

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

[jbebad]

I have no idea about that. I am only a user, just like you. However, I have not had problems with the data files I have downloaded with uTorrent - even rar files; I can listen, watch, install, read, etc. any file I have downloaded. I do not do anything special. I do not know about the cirmamepro product or MAME (what ever that stands for) titles. So if that product complains or not, I really do not care. Perhaps it's a issue with that product. It also may be an issue with the product the initial seeder used to create the torrent. I just do not know.