µTorrent 3.0 (32-bit) Stable Release

[bigfalls]

bigfalls, thank you for your feedback from another side (uTorrent team)

I (and I think that all other users/testers as well) glad to use this product and to help you to make it better.

We really appreciate your work and your product - uTorrent.

Thank you.

Thanks! I and everyone who contributes to this product, especially the dev team, appreciate that.

[articuno1au]

@ Bigfalls - Thanks for the info. A vast majority of us understand what you said. You are obviously going to get hit up by some of the trolls. I think so long as you keep us (the people testing your pre-release features) informed (which is something the uTorrent team aren't great at) and consider (not necessarily follow) our responses and feed back you will have a strong core user base.

Just please don't get tunnel vision with the features your adding. I think there are some good things coming, but I think you shouldn't be afraid to drop features (in the short term) that aren't sitting well with the users. Other then that, awesome

--

I have something to add relating to the interface, I'm not sure what to call this..

I currently have my uTorrent set up to seed for 60 seconds after finishing the torrent (due to having a shared connection, I re-upload during off-peak). I noted that when the seeding started, the download stayed up at a high rate for an extended period. In the case of my screenshot 12 seconds, but 30 seconds later it was still sitting 40KBps above the rate it should have been.

http://i227.photobucket.com/albums/dd108/articuno1au/uTorrent2.png

It's a bit odd, like I said, not sure what to call it. Hopefully you can read your own speed graphs to spot what I am talking about

[jesuscheung]

Same problem. 3.0 is too slow for the same setting as 2.2.1. I had enough of 1kB/s for the entire day for every torrent of the same tracker. As soon as I switch back into 2.2.1, every torrent is downloading normally again at 30-40kB/s.

As for private tracker, 3.0 speed is same as 2.2.1.

Also, 3.0 randomly freezes for no reason. All I have to do is starting a 'stopped' torrent.

[Alpha-Toxic]

I have a serious problem with uT's read cache. It seems to be reading a lot more than it actually needs. It just keeps on reading. It must have been going for some time (all 3.X versions I think) but I hadn't noticed until now.

Exhibit A:

Exhibit B:

At this point it was only running for 30 minutes or so and had uploaded < 300MB.

The cache setting are all the same as they were on 2.X. I tried different configurations, but nothing seems to make a difference (short of turning the read cache off).

build 25277 x86 on Windows 7 x64 SP1

I have Microsoft Security Essentials installed, if this make any difference.

[articuno1au]

What Alpha-toxic is showing there is what I was seeing on my server.

I noted insanely high read usage and just wrote it off as irrelevant because I had time constraints on my uploads. I rolled over to Bitcomet due to slow up speeds.

Server 08 R1 SP 2 x64 no anti-virus installed running Windows Firewall.

[AdamK]

I have a serious problem with uT's read cache. It seems to be reading a lot more than it actually needs. It just keeps on reading. It must have been going for some time (all 3.X versions I think) but I hadn't noticed until now.

Exhibit A: http://store.picbg.net/pubpic/EC/3F/00e8338f8027ec3f.png

Exhibit B: http://store.picbg.net/pubpic/92/10/3d207bb1628c9210.png

At this point it was only running for 30 minutes or so and had uploaded < 300MB.

The cache setting are all the same as they were on 2.X. I tried different configurations, but nothing seems to make a difference (short of turning the read cache off).

http://store.picbg.net/pubpic/42/40/6aa744237a794240.png

build 25277 x86 on Windows 7 x64 SP1

I have Microsoft Security Essentials installed, if this make any difference.

Hi,

A few of us have been discussing this, and would like you to try a few things:

1. Try enabling: "Turn off read caching if the upload speed is slow"

2. Try incresing advanced option: diskio.cache_reduce_minutes

We're wondering if the rate at which we expire the cache in your circumstances is slightly greater than the rate that some of your peers are getting the data from you.

[Firon]

New build up with several bugs fixed. This should fix Windows consuming a great deal of memory while doing re-checks.

[Firon]

Well I haven't faced this error from last couple of days so I dunno if the problem exists anymore (in the new builds). v v

For everyone with "Error: The Data is Invalid"' date=' open the download folder of the particular torrent. Notice anything different? It seemed that somehow, ".1" (dot one) extension was getting added to one of files in the torrent. And then I used to get "Error: The Data is Invalid". I removed the .1 extension and started the torrent, it had gone on fine , until unless, same happened again. Had happened to 2 different torrents for total 3 times. Hope this helps anyone. [/quote']

I installed 25234 and immediatly the "Error: The Data is Invalid" came up on a torrent that I am only seeding. So, it isnt just torrents that are being downloaded. I do not have the ".1" extension on any of the torrents that have this error. Going to revert back to 2.2 until some one can figure out wtf is going on.

This should be fixed in today's release (25303).

[Firon]

I have my columns sorted so the # column is the primary sort and the Added column is the secondary sort. After updating to the newest build, the secondary sort is all out of order and there's no way to fix it. I noticed that the times are sorted for each date but not the dates themselves. It used to be sorted by date, then time.

I hope this is not just me because my settings.dat is messed up. I think I might have to redo my settings soon if that's the case.

EDIT: OK I just tried it with fresh settings.dat and still having the same problem.

Streaming is broken once again in last two builds at least (streaming button not clickable and invisible when torrent is selected). Also torrents sorting is broken is latest build (you can only sort by one column).

Secondary sorting should be fixed in 25303.

[Firon]

Removing the ability to double-click on an unfinished torrent to play it was uncool; I used that heavily.

I totally agree... as I said in my previous comment' date=' please bring back the ability to play unfinished torrent by double-clicking. Please please please.....[/quote']

This feature is back in 25303.

[ResonantEcho]

Well I haven't faced this error from last couple of days so I dunno if the problem exists anymore (in the new builds). v v

For everyone with "Error: The Data is Invalid"' date=' open the download folder of the particular torrent. Notice anything different? It seemed that somehow, ".1" (dot one) extension was getting added to one of files in the torrent. And then I used to get "Error: The Data is Invalid". I removed the .1 extension and started the torrent, it had gone on fine , until unless, same happened again. Had happened to 2 different torrents for total 3 times. Hope this helps anyone. [/quote']

I installed 25234 and immediatly the "Error: The Data is Invalid" came up on a torrent that I am only seeding. So, it isnt just torrents that are being downloaded. I do not have the ".1" extension on any of the torrents that have this error. Going to revert back to 2.2 until some one can figure out wtf is going on.

This should be fixed in today's release (25303).

I had this happen again with the 25303 release as well. I did a "Force Re-Check" and it downloaded for several minutes and then gave the "Error: The Data is Invalid" message.

[Firon]

Are you skipping any files?

[ResonantEcho]

Are you skipping any files?

Yes. It's a torrent that contains a band's discography. I skipped several years (folders are grouped by year).

[Alpha-Toxic]

Hi,

A few of us have been discussing this, and would like you to try a few things:

1. Try enabling: "Turn off read caching if the upload speed is slow"

2. Try incresing advanced option: diskio.cache_reduce_minutes

We're wondering if the rate at which we expire the cache in your circumstances is slightly greater than the rate that some of your peers are getting the data from you.

1. Well, this works as advertised at low speeds, but when the speed increases uT still reads like mad. I just had a single torrent uploading at about 250-300 KB/s and it was reading at 20-30 MB/s.

2. I did not see any difference when playing with this setting (tried 10, 100, 1000). I have no idea what this does, so I don't know what a "sane" value would be; I just tried a bunch at random.

To me it seems that uT is reading the entire piece for every block it has to upload and then discards it from the cache.

[Anonymous1]

Is hanging issue fixed maybe ? I'm too scary to try it now

[Ulum]

I am a Russian user. Starting with version 25252 hangs when booting Last working version 25234. If you have unplugged all the torrents that do not hang up right away, but hangs up when you begin to start to run one at a time.

[dothackjhe]

Not to offend those who didn't like this release's UI, but I personally liked its designs. Btw, what do people meant by "issuing a stable version of uTorrent 3.0?" Isn't this beta version of uTorrent 3.0 stable enough for use? I've been actually using this version ever since its first release and had no problems with it whatsoever except when the time I updated to a higher version of its beta state which led to a capped download / upload speed (10 Kbps / 10 Kbps if I remember it correctly).

[icebox]

25303 is the first beta of 3.0 I tried as an earlier beta couldn't find all the torrents I had seeding under 2.2.1 was seeding. Now after a rather long search 25303 found them. I have two problems with the new version:

1) With torrents of multiple files previously downloaded under 2.2.1. when only some files were downloaded, the new version is finding the data invalid. Looking at the files list after doing a force recheck, the pieces that are fully contained within the downloaded files are OK. Pieces that overlap with skipped files are the problem. There is in fact nothing wrong with the files. Some of the torrents I had like this were OK after redownloading the allegedly bad pieces, but I have one where the problem repeats after the program re-downloads the "missing" pieces.

2) Please restore an option to have "Added" and "Completed" show a date and time, as in the previous versions, rather than "3 months ago" or "last week" I generally keep torrents sorted by date added and the lack of precision is annoying. This is important to me as some sites drop torrents a specified time after it is first posted, and the dates help me with planning.

Thanks.

Mark

[arvid]

Hi' date='

A few of us have been discussing this, and would like you to try a few things:

1. Try enabling: "Turn off read caching if the upload speed is slow"

2. Try incresing advanced option: diskio.cache_reduce_minutes[/quote']

1. Well, this works as advertised at low speeds, but when the speed increases uT still reads like mad. I just had a single torrent uploading at about 250-300 KB/s and it was reading at 20-30 MB/s.

2. I did not see any difference when playing with this setting (tried 10, 100, 1000). I have no idea what this does, so I don't know what a "sane" value would be; I just tried a bunch at random.

This setting controls the time a cache entry will stay in the cache. The default is to time out after 9 minutes.

To me it seems that uT is reading the entire piece for every block it has to upload and then discards it from the cache.

That is exactly what it is doing. This is what the read cache does, it assumes that a request for one chunk in a piece is likely to be followed by another request from the same piece. If you are uploading significantly slower than others in the swarm, or there are just a lot of other seeds the downloader might get chunks from, the downloader may have satisfied all other chunks from other peers by the time you've completed the first chunk. In this case, the read cache is completely ineffective.

You might want to turn off the read cache if this is a problem for you.

These are the fixes we will do to uTorrent to mitigate this problem:

1. have a fixed read cache line size of, say, 128 kiB, rather than the full piece

2. for fast peers, request entire pieces to improve cache performance for the sending peer

Please let us know if you have any other ideas that could mitigate this problem. One possibility is to try to predict the sequentiality of read requests, and adjust the cache line size accordingly. This is complicated and not clear that would actually buy us anything. For instance, windows internally just uses 128 kiB cache line sizes (unless the sequential file flag is set).

Since this is not a regression, and we're very close to a 3.0 stable, these changes will unfortunately not make it into 3.0. But I would like to thank you for bringing this to our attention.

[martix]

Apparently this new edition causes my computer to "stutter" from time to time.

Most noticeable during video playback, when it freezes for several seconds at a time.

Which is why I reverted to the stable for the time being.

[AdamK]

Not to offend those who didn't like this release's UI, but I personally liked its designs. Btw, what do people meant by "issuing a stable version of uTorrent 3.0?" Isn't this beta version of uTorrent 3.0 stable enough for use? I've been actually using this version ever since its first release and had no problems with it whatsoever except when the time I updated to a higher version of its beta state which led to a capped download / upload speed (10 Kbps / 10 Kbps if I remember it correctly).

Hi,

In this context, "stable" means a release that is not an Alpha, Beta, or RC. That means that it is the current shipping release of utorrent, on the front page. We promote a build to stable when we feel that all of the serious known bugs are gone (and when people stop sneaking featues in )

[dezz02]

Apparently this new edition causes my computer to "stutter" from time to time.

Most noticeable during video playback, when it freezes for several seconds at a time.

Which is why I reverted to the stable for the time being.

You can fix this by setting the taskpriority of the player higher. Or use MPC-HC, it has an option to do it automatically.

[Firon]

25303 is the first beta of 3.0 I tried as an earlier beta couldn't find all the torrents I had seeding under 2.2.1 was seeding. Now after a rather long search 25303 found them. I have two problems with the new version:

1) With torrents of multiple files previously downloaded under 2.2.1. when only some files were downloaded, the new version is finding the data invalid. Looking at the files list after doing a force recheck, the pieces that are fully contained within the downloaded files are OK. Pieces that overlap with skipped files are the problem. There is in fact nothing wrong with the files. Some of the torrents I had like this were OK after redownloading the allegedly bad pieces, but I have one where the problem repeats after the program re-downloads the "missing" pieces.

2) Please restore an option to have "Added" and "Completed" show a date and time, as in the previous versions, rather than "3 months ago" or "last week" I generally keep torrents sorted by date added and the lack of precision is annoying. This is important to me as some sites drop torrents a specified time after it is first posted, and the dates help me with planning.

Thanks.

Mark

1) This is a known issue. We're working on it, though.

2) Set gui.use_fuzzy_dates to false.

[Firon]

I am a Russian user. Starting with version 25252 hangs when booting Last working version 25234. If you have unplugged all the torrents that do not hang up right away, but hangs up when you begin to start to run one at a time.

Can you try 25309?

[Firon]

I had this happen again with the 25303 release as well. I did a "Force Re-Check" and it downloaded for several minutes and then gave the "Error: The Data is Invalid" message.

The fix did not in fact make it into the 25303 release. It is in the new 25309 build I just put up though. Could you try it?