unforgiven_sh

Established Members
  • Content Count

    44
  • Joined

  • Last visited

Everything posted by unforgiven_sh

  1. Since the new disk i/o was introduced in 3.3 I'm getting abnormal pagefile usage with every version since. The pagegefile usage gets increased up to 1.5 Gb and frees up as soon as I close uT. I've seen few posts here mentioning that problem but haven't seen any solutions. Is this even acknowledged by the devs?
  2. Is the unusual pagefile usage in 3.3 even being looked at by the devs? I've seen it being mentioned here multiple times but nothing's being done about it. I've been updating uTorrent for every new (3.3) build and reverting back to 3.2.3 after a few hours. The problem is: whenever I close uTorrent 3.3 after it's been running for several hours there's a 200-300 mb drop in task managers physical memory usage history graph. And if someone is saying the problem is at my end, they should first explain to me why its not happening with 3.2.3
  3. @conquerist: I had the exact same problem. Downgraded back to 3.2.3 (28705) and everything workes flawlessly. Don't plan upgrading any time soon.
  4. there's no change-log for 29342
  5. uTorrent 3.3 Build 29342 Can anyone explain whats causing this?
  6. @rafi: this is the 3.3 thread
  7. there's no need for "uTorrent Lite". just move the non-essential stuff to uTorrent Plus and make a win-win out of it.
  8. build 29126 nope, not in my case
  9. had to downgrade to 3.2.3 because of this
  10. ive had much lower speeds than 2.1 (same torrents, same settings) so i reverted back
  11. when turning off the bandwidth management (bt.transp_disposition = 5) should we also disable bt.tcp_rate_control and net.calc_overhead ?
  12. i have the same problem as xacox, but im not a initial seeder tough, just a normal peer. the speed graph used to look like a mountain landscape until i disabled the bandwidth management in the bittorrent settings section. now the graph is a straight line going along my max ul/dl speed values. everyone experiencing the same speed problems should try the same
  13. adding torrents when client is not running has a bug i believe. when i open a torrent it just brings out the program so i need to open the torrent again to add it to the queue. can someone take a look at this?
  14. i get great speeds with this build, its amazing the only thing i noticed is the reduced DHT count in the uT's status bar, on 1.8 i was getting 300+ while now it stays at 150+. also two GUI bugs: when browsing torrents by labels and then clicking on the 'all' field on the left panel nothing changes. the second one is the blue wave icon above the 'all feeds' field cut in half by the separator line will stick with this build for now -------------------------------------------------------------- edit: the DHT is back to normal, and the 'label' - 'all' switching works, sorry
  15. in the setup guide the save & close button should always be enabled because i cant get any results from any of the test servers (always getting errors). when i manually choose my connection type i cant apply it because the save & close button is grayed out. i assume that the save & close button becomes functional only after a successful b/w test, but we should be able to change the connection type without doing the test because its too buggy ATM
  16. @Simon100: 1. try disabling net.calc_overhead and bt.tcp_rate_control in the advanced settings 2. if nr 1 doesnt help turn off 'Enable bandwidth management' in the bittorrent settings 3. if nr 2 doesnt help either you can go to 1.8.3 anytime
  17. @Ichpuchtli: have you tried the conservative settings: http://forum.utorrent.com/viewtopic.php?id=58404 ? it helped me a lot, you can try it for a couple of hours/days then revert to the old settings if it doesnt help
  18. it would be better if uT's automated speed test could use http://www.speedtest.net/ servers
  19. Switeck: it was a test download, just to show you the bug (which isnt related to u/l nor d/l), it wasnt anything that i would download and seed anyway
  20. found a bug: the program somehow reports much more peers then the actual count screenshot: http://img32.imageshack.us/img32/8199/55169708.jpg the seeds nr is exact but the peer nr isnt
  21. after doing some more tests i found out that my speed problem WAS uTP related. i tried TCP only (bt.transp_disposition=5) as rafi pointed out, "Enable bandwidth management" check-box got disabled by itself and after restarting the app transfer speeds went back to normal. (i went forth and back few times to conform this was the problem) @dev team: please take care of this one
  22. as i said i tried disabling "Enable bandwidth management" check-box since its said it disables uTP connections but the result was the same
  23. three more screenshots: http://img44.imageshack.us/img44/1663/2b1.jpg http://img11.imageshack.us/img11/1962/2b2i.jpg 5 sec step: http://img44.imageshack.us/img44/203/2b3.jpg