rafi

@Simon: if there is an intended features' list (or planed modifications/fixes) - it will be interesting to see it. Personally, I would like to see the RSS feature improved, and not just be on the to-do list for two years... http://forum.utorrent.com/viewtopic.php?id=44903

I guess it depends on the quality ... does it really matter ?...

it's a different issue, moogly, not 2.0 related. Simply a missing flag for HIS country. Too bad we don't know what country it is ... but I'm sure the guys at the "flags thread" will know http://forum.utorrent.com/viewtopic.php?id=2070

crashed while doing what ?

the "sense" is as explained in the help file: so you have to find a better "tactics" then 50-50 for uT in this case of concurrent UL/DL tasks... a possible way is - you can try and use the pseudo "priority" scheme by right-click->bandwidth allocation on each task. the help-file relates this setup to only uploading tasks, but anyways, it will only work IF you set a limit (a guess - to have a reference point). So if you eventually will decide to do this right thing, who knows... it might even work for mixed tasks... try it and tell us...

and how would you suggest uT should behave with no limits ? you need some free upload bandwidth for the download overhead, so it probably divides the upload 50%-50% between seeding and download.

or maybe just the same color as each (like in the speed graph) and if possible - dotted...

@Ondoy, you might be right. , I can't remember. And they lowered the default for connection_speed to 5 (connections-attempts/second). I think it's a good number, especially if you have a router, but you can try a higher one.

I wish I had your great connection ... a screeshot of your uT speed-graph/# of connections when this happens - will be interesting (but with calc_overhead=true)

since you did not say what your connection speeds are, proper settings should be : calc_overhead = true upload limit - ~70-80% of your connection max (use control-G/setup guide) And unless you have a connection with more then 1:15 UL/DL ratio, it should be fine. RC5: Context sensitive help in preferences: Can you please make F1 work in preference (like clicking the mouse on "?") ? Thanks... In setup guide/RSS downloader related dialogs (fav/add feed)- can you make F1 work for them too ? "?" will be nice there as well... Context sensitive help for the rest of the dialogs and even tabs-RC menu will be nice too

@xaxax: I agree, it can be done in a 2.01 release. but ... still, 2.0 should be fixing 1.8.5 bugs as well, ans since this is a 5 seconds fix... (ok, 5 minutes...) why not just do it. Oh, and Ondoy DID post a few graphs... http://forum.utorrent.com/viewtopic.php?pid=447153#p447153 show just the opposite since he is using a local ISP cache peer... @Ondoy: try increasing your bt.connect_speed a bit (though, it's not recommended) and reduce peer.disconnect_inactive to 100

GUI glitch (not sure it started in 2.0) : in the pref.->scheduler tab - when you change any of the "squares" - the "apply" button should be enabled . It stays disabled. So it's hard for you to test your limit + correct date settings in the speed-graph, since you have to press Ok and exit the setup to apply changes.

setup guide: should suggest the dslreport test-site ALSO and especially when the test server fails. download test - is too short for accurate measurement with large connection speeds, and actually a bit redundent... BTW, is the port being tested for both UDP and TCP forwarding ? (it should... ) and one more GUI improvement for 2.01... : "Stop all" for all buttons - more here: http://forum.utorrent.com/viewtopic.php?id=67212

great the 256K is almost exactly like I have (but 1:10 line) but both day & night... 22K limit works for me well though. In your case, the problem will be at night - you will simply never get 12M download with 512K up, even if you set it to 60K limit or even unlimited... Anyways, you need to also specify ~60K limit in the uT scheduler for your nights ...

@Virtual_ManPL : and what were your actual download speeds ? and your max possible connection speeds ? and did you use the setup-guide for you limits' settings ?

Ambiguity in data - is undesireable. Well, I'm sure uTorrent is clever enough to disregard those illegal address, and also subtract them from the total count ... at least - users will not continue asking "why the numbers do not match". I'm sure people will ask this same question about the speed numbers on the status bar and why they do not match, now , the set limit (with calc_overhead =true).

but... eventually, uTorrent loads the actual peers' list from them, right ? so why not just count them and put the exact numbers in the trackers tab instead of the reported numbers ? at least for UDP trackers ?

"open containing folder" on a torrent task, that is missing the torrent file (exidentally erased) - results in "open"ing the downloaded file itself. Since the file name and location IS known - uT should easily open the folder as well. Also the "open file" menu operation is grayed/disabled, and as we can see - can be enabled.

I'm not sure I can see "your" 5KB DL , but 0.9K difference sounds quite good to me... (and I didn't understand your UL related data.)

Nice fix of the overhead calculation. Both limiters work fine . Issues that still exist in RC5: - upload speed - does not comply with external tools measurement - calc_overhead - TRUE seems to still NOT be set by default (as previous version) - color scheme legend is needed for the speed graph (payload/overhead) - speeds - numbers better be reverted back to show full speed (for calc_overhead =TRUE). They seem like not complying to the limiters on the status bar.

if it's possible to still remember the IP4 address, and show the "country flag" and maybe the IP4 address as well for IPV6 peers - it can be nice.

@86195DFA : you mean that the line length is too short to fit it all in ? yes, they should provide 2 text lines for errors in the next release... - I also suggest to eliminate the use of xxx.yy Kbps for speeds , xxx is enough. - and.. showing the speed test progress and result on the speed graph will be nice - on the drop-down list - test results & current settings should be at the exact same format of the speed test - > test result was 157kbit/s (9 KB/s) > current settings 222kbit/s (12 KB/s)

I see up to 82K on the first one... You should remember that "overhead" counts too . Also, you should check what is your real connection upload speed, with your ISP speed test here: http://cables2.013net.net/upload/index.php But you are right, there is just a small chance that it will effect the results ( that are not VERY far away from 1.8.5 ) I hope RC5 will calculate the overhead better...

@Ondoy: and a ~65K upload limit did not help ? @fadeout: I can't see any issue with the upload limiter. Only with the miscalculation of the overhead... btw, I think the devs choose to display the real data-speed (same as with calc_ovehead=flase) and not the total. do you think it's more confusing ? I don't know... :/ http://img704.imageshack.us/img704/8743/62462284.png

@Zarggg/Virtual_ManPL : http://forum.utorrent.com/viewtopic.php?pid=446416#p446416 And the idea was to limit both data+overhead when calc_overhead = true, but from now - always to show the net-data in the numbers. I would rather have dotted lines for the totals though... Issues that I can still see in RC4: - overhead is now underestimated - I would rather have dotted lines for the totals though... http://forum.utorrent.com/viewtopic.php?pid=444873#p444873 - and for me (locally) - I still have an issue with seeding only, that seems not to work at all with uTP only communication. But I guess it's a local issue here (ISP/Firewall/router etc).