µTorrent 3.1 stable (build 26671) (Page 3) / Announcements / µTorrent Community Forums
 

#51 2011-12-09 21:25:03

MirceaForce
Member

Re: µTorrent 3.1 stable (build 26671)

so far so good continue testing with new version

thanks guys

keep up the good work

Offline

#52 2011-12-10 00:16:34

Tomorrow
Member

Re: µTorrent 3.1 stable (build 26671)

Looks like build 26595 fixed the crash issue i was having. Still the download speeds seem odly low now. Going to test with some high speed torrent just to be sure. Could also be my Youtube upload hogging bandwidth on the background.

Btw i documented the advanced setting changes compared to 3.0. Check it out if you're into tweaking: New advanced settings 3.0 --> 3.1

Offline

#53 2011-12-10 01:06:57

rafi
Member

Re: µTorrent 3.1 stable (build 26671)

what speeds are you getting now? You do need to shut down all other bandwidth consumers for testing.

Offline

#54 2011-12-10 02:15:11

Ulum
Member

Re: µTorrent 3.1 stable (build 26671)

3.1 stable build 26595
Doesn't change the priority of downloads.

Offline

#55 2011-12-10 02:55:19

Tomorrow
Member

Re: µTorrent 3.1 stable (build 26671)

rafi wrote:

what speeds are you getting now? You do need to shut down all other bandwidth consumers for testing.

Yep it was Youtube. All is ok now.
No problem here changing priorities.

Offline

#56 2011-12-10 04:23:56

Reith
Member

Re: µTorrent 3.1 stable (build 26671)

Just updated to 3.1.  Why do I have this weird foreign text in the toolbar?

utorrent.jpg

Offline

#57 2011-12-10 06:30:25

hannubys
Member

Re: µTorrent 3.1 stable (build 26671)

Why the documentation is always out of date !!

Offline

#58 2011-12-10 08:43:39

osmosis
Member

Re: µTorrent 3.1 stable (build 26671)

Hmm I have this odd compulsion to watch boxing now for some reason.. roll

Reith wrote:

Just updated to 3.1.  Why do I have this weird foreign text in the toolbar?

Poorly handled settings.dat corruption. They were supposed to have fixed that though, I thought. If you can bear to, deleting your settings.dat should fix it; of course you'll have to redo all your settings and sizing.

Last edited by osmosis (2011-12-10 08:46:02)

Offline

#59 2011-12-10 09:09:57

rafi
Member

Re: µTorrent 3.1 stable (build 26671)

Instead of you watching boxing, maybe you can do  a how-to guide, using bencode to fix it in settings.dat. The world will thank you... wink

Edit:

OK, guys, try this "Guide" (RC... before I enter it as stable into my tips-guide...):

0. Close uTorrent
1. Run BEendode-editor http://forum.utorrent.com/viewtopic.php?id=31306 on your active settings.dat file
2. Search inside for "stitle" (no quotes)
3. Edit it (double click) and replace it with "Take our product survey"

Now, rerun uTorrent see if that did the trick ...

Let me know...

Now for the bonus-extra-fun part:

a. Search for  "s_url"
b. Edit in your own  URL, like this one to this on-line TIPs/guide: http://forum.utorrent.com/viewtopic.php?id=74820
c. Per the above 'guide' enter as stitle: "Rafi's tips-guide..."

And ... you have your own link the my favorite uTorrent on-line tips-guide... wink

Last edited by rafi (2011-12-10 11:23:19)

Offline

#60 2011-12-10 10:35:57

NapoTheGreat
Member

Re: µTorrent 3.1 stable (build 26671)

are there any news regarding this issue described here

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

http://forum.pleasuredome.org.uk/index. … opic=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

Offline

#61 2011-12-10 10:43:26

Simbiat
Member

Re: µTorrent 3.1 stable (build 26671)

I'm experiencing strange behavior with force re-check.
Here are the kinds of issues I get:
1. Open utorrent, force recheck a torrent - freeze
2. Kill previously freezed utorrent. Try to recheck again - recheck is not done - just freeze at 0.0%
3. Stop freezed recheck - uttorent freezes.

Offline

#62 2011-12-10 10:46:23

Simbiat
Member

Re: µTorrent 3.1 stable (build 26671)

BTW, I still experience hangs on exit

Offline

#63 2011-12-10 10:51:01

danei
Member

Re: µTorrent 3.1 stable (build 26671)

3.1 26595
1) When double-clicking a torrent file ut opens a dialogue but the dialogue can't remember its position, so it keeps part of it outside the screen area every time it's triggered.
2) Torrent status remains "moving" when actually all the files have been moved. (Set different dirs for downloading and finished torrents) and saving dir info is not refreshed as well in torrent list, also, no log item indicates file moving complete. Maybe you forgot to do all the necessary works after a torrent's file moved?

Offline

#64 2011-12-10 11:18:25

osmosis
Member

Re: µTorrent 3.1 stable (build 26671)

rafi wrote:

OK, guys, try this "Guide":

0. Close uTorrent
1. Run BEendode-editor http://forum.utorrent.com/viewtopic.php?id=31306 on your active settings.dat file
2. Search inside for "stitle" (no quotes)
3. Edit it (double click) and replace it with "Take out product survey"

a. Search for  "s_url"
b. Edit in your own  URL, like this one to this on-line TIPs/guide: http://forum.utorrent.com/viewtopic.php?id=74820
c. Per the above 'guide' enter as stitle: "Rafi's tips-guide..."

Now, rerun uTorrent see if that did the trick ...

Blanking s_url and stitle effectively removes the link too - much more my style. Good find!

I'd also like to suggest making empty "apps" "cache" "ie" and "dlimagecache" files in %AppData%\uTorrent for inclusion in your guide, as that REALLY makes sure they're disabled wink

I've had plenty of fun trying to disable all the new features. I've even got btapps.app_store and btapps.apps_channel set to "about:blank"

Last edited by osmosis (2011-12-10 11:29:09)

Offline

#65 2011-12-10 11:22:37

rafi
Member

Re: µTorrent 3.1 stable (build 26671)

osmosis wrote:

Blanking s_url and stitle effectively removes the link too - much more my speed. Good catch! wink

but... but... I don't want to remove the link, I want it to be my link... tongue
I didn't follow you, it increased "your speed" as well...?

Offline

#66 2011-12-10 12:30:58

hannubys
Member

Re: µTorrent 3.1 stable (build 26671)

osmosis wrote:

Blanking s_url and stitle effectively removes the link too - much more my style. Good find!

I'd also like to suggest making empty "apps" "cache" "ie" and "dlimagecache" files in %AppData%\uTorrent for inclusion in your guide, as that REALLY makes sure they're disabled wink

I've had plenty of fun trying to disable all the new features. I've even got btapps.app_store and btapps.apps_channel set to "about:blank"

Yeah, I did this too for btapps.app_store and btapps.apps_channel. And I'm trying to avoid the creation of "apps" "cache" "ie" and "dlimagecache".
This is how i spent my time with new release of utorrent, trying to disable useless things!

Offline

#67 2011-12-10 16:35:47

osmosis
Member

Re: µTorrent 3.1 stable (build 26671)

rafi: Does "Apply rate limit to transport overhead" checked allow the write cache to exceed during the ramp up with a fast torrent on your end? Unchecked I get that throttling, checked I can still go massively over... I feel like I found a correlation here.

#1 in my Buglist post has been updated.

Last edited by osmosis (2011-12-10 17:09:14)

Offline

#68 2011-12-10 18:09:17

Reith
Member

Re: µTorrent 3.1 stable (build 26671)

rafi wrote:

Instead of you watching boxing, maybe you can do  a how-to guide, using bencode to fix it in settings.dat. The world will thank you... wink

Edit:

OK, guys, try this "Guide" (RC... before I enter it as stable into my tips-guide...):

0. Close uTorrent
1. Run BEendode-editor http://forum.utorrent.com/viewtopic.php?id=31306 on your active settings.dat file
2. Search inside for "stitle" (no quotes)
3. Edit it (double click) and replace it with "Take our product survey"

Now, rerun uTorrent see if that did the trick ...

Let me know...

Now for the bonus-extra-fun part:

a. Search for  "s_url"
b. Edit in your own  URL, like this one to this on-line TIPs/guide: http://forum.utorrent.com/viewtopic.php?id=74820
c. Per the above 'guide' enter as stitle: "Rafi's tips-guide..."

And ... you have your own link the my favorite uTorrent on-line tips-guide... wink

Thanks, this fixed it.

Offline

#69 2011-12-10 21:19:14

rafi
Member

Re: µTorrent 3.1 stable (build 26671)

osmosis wrote:

rafi: Does "Apply rate limit to transport overhead" checked allow the write cache to exceed during the ramp up with a fast torrent on your end? Unchecked I get that throttling, checked I can still go massively over... I feel like I found a correlation here.

#1 in my Buglist post has been updated.

No idea. I have it checked all the time, and have no download speed limit.  I'll try it. Did it effect the cache even when you don't set any speed limit?

Edit:
btw, I've reported an issue with peers' speeds above 16MBps - not being displayed/limited correctly. Are you in those speed ranges?

Edit2:
Strange, since overhead shouldn't have anything to do with the cache. Only pure data should be in there. So, even IF the cache "speed breaks" do not limit the overhead, it should not be reflected in the cache display (unless it is buggy...).
Ah, and 30Mbps is outside the 16MBps problem "zone"...

My experience is with my own cache settings. Right now - the major difference in my case here (was - http://forum.utorrent.com/viewtopic.php … 60#p622260 ) is the setting of:

coalesce_write_size - I set it to x16 times the default (256K) - to 4M (4194304). It actually was 2M in older releases. At very high speeds - it more then doubles the max disk-write speed. I have it set to this all the time, and will recommend to the devs to set it so as default.

The new low_prio_disk - this one was reverted in this release (used to be as false - normal priority - in older releases).  This greatly effect the cache,  since this syncs the disk writes with the into-cache writes. I am testing both values.

Last edited by rafi (2011-12-10 23:42:25)

Offline

#70 2011-12-10 21:56:11

osmosis
Member

Re: µTorrent 3.1 stable (build 26671)

rafi wrote:

No idea. I have it checked all the time, and have no download speed limit.  I'll try it. Did it effect the cache even when you don't set any speed limit?

I don't actually have a speed limit set... "Unlimited" for Download and 90kB/s for Upload - I'm just getting this odd throttling effect when the write cache gets maxed on a fast torrent and "Apply rate limit to transport overhead" is disabled. Enabling it, for some reason, allows it to massively exceed the cache since I guess there's nothing to stop it (no throttling).

Edit: When it exceeds the write cache I'm usually downloading at around 1-3MB/s. My actual connection is 30Mbps/2Mbps.

Last edited by osmosis (2011-12-11 09:40:49)

Offline

#71 2011-12-11 02:25:12

EndlessRain
Member

Re: µTorrent 3.1 stable (build 26671)

26595 can't "Quit when Everything Completes"

Offline

#72 2011-12-11 03:32:39

Ulum
Member

Re: µTorrent 3.1 stable (build 26671)

Ulum wrote:

3.1 stable build 26595
Doesn't change the priority of downloads.

Changes, but does not update the table. Just after the restart. The same thing happens with column tracke

Offline

#73 2011-12-11 05:19:14

Ionel2k
Member

Re: µTorrent 3.1 stable (build 26671)

Any way to remove "Transfer To.. > Add Device" from the context menu?

Offline

#74 2011-12-11 10:06:28

goatie
Member

Re: µTorrent 3.1 stable (build 26671)

build 26595 - still getting odd cases of single hashfails preventing the torrent from completeing, abd than clearing after a force recheck.

Som RSS feeds have stopped working, too.

http://rss.thepiratebay.org/201 returns nothing, although my feed reader shows plenty of content
http://www.mininova.org/rss.xml on the other hand is fine.

Only difference I can see is that mininova includes the xml pagein the URL, PB doesn't?

Offline

#75 2011-12-11 10:21:44

rafi
Member

Re: µTorrent 3.1 stable (build 26671)

goatie wrote:

Som RSS feeds have stopped working, too.

Same here sad

Offline

Board footer

Powered by FluxBB

©2013 BitTorrent, Inc. µTorrent is a trademark of BitTorrent, Inc.