xaxax

Established Members
  • Content Count

    34
  • Joined

  • Last visited

Community Reputation

0 Neutral

About xaxax

  • Rank
    Advanced Member
  1. Hey Dread, Yes, it was enabled. But I disabled it (and the Related tab too, btw), and the problem persists.
  2. I spoke too soon. I did a Force Recheck of 10 torrents. After that completed, I selected the 354 torrents, and utorrent hung. It is still hung, 40 minutes later... It looks like download and upload is happening, even though the Speed tab is frozen and not changing.
  3. I don't use the ratings tab, but I just checked and it was enabled (default I guess). I disabled it and the problem with pinning the cpu on selection disappeared. Suggest the ratings tab be disabled by default...
  4. Simply select the torrents. I didn't have any opportunity to do anything after selection because the mere action of selecting the torrents pins the cpu to 100%. I left it like that earlier today for about 5 hrs and eventually killed it. This morning, "a bunch" meant 354 torrents that were all "Finished" state. I wanted to do a 'Force recheck' on them but was unable to do so. I don't reboot my computer, I leave it on 24/7 with utorrent. Utorrent just grows and grows and grows... I just restarted it about 2 hrs ago and it is 171MB now. After a week it will be over 300 MB... In another week, it will be over 400 MB... Force recheck is significantly slower than it ever used to be. Regrettably, utorrent is no longer the small, fast software that it used to claim...
  5. Just upgraded to 3,3.2 and it still has the bug where if you select a bunch of torrents, then it pins the cpu and the app is totally unresponsive. The only option is to kill it with task manager.
  6. Utorrent froze on me tonight (20367), so I made a dmp file -- first one since last November. But unlike previous .dmp files that were in the range of 119 KB .. 228 KB, this one is 247,699 KB!!!! That's too big to upload anywhere.
  7. Switeck - thank you, that has definitely improved the download speed at least.
  8. I have become convinced that there is something wrong with utorrent 2.0 that makes the torrents so slow. Sometimes some of them go 'fast' (e.g. 50+ KB/s down) but usually they are very slow, like the 3 I have now - 0.1 KB/s, 2.2 KB/s and 2.7 KB/s. Version 1.8.5 used to always be pegged against the scheduler limit (40 KB/s up), but 2.0 hardly every reaches it, and usually the upload line hovers around 10 KB/s and the download line is lower than that. And then, yesterday, I saw this notice on one of the private trackers I visit: I tried to downgrade to to a version of 1.8.5 that I had saved, but it won't install. I have bt.tcp_rate_control=false and all other settings are defaults. Any advice??? (Edited to use quote from private tracker)
  9. I had a 'not responding' problem with uTorrent 2.0 build 18097 (Vista x64) - my first problem like this with 2.0. I did make a dump file, but the zipped version is still 117 MB (228 MB unzipped) so I have not uploaded it anywhere.
  10. @Greg Hazel - yes, bt.tcp_rate_control=true seems to give me worse throughput than if set to false (it seems to be about half the throughput). This isn't based on a test environment, just watching the throughput graphs on ut and netmeter. I've been using bt.tcp_rate_control=false for about 3 days now.
  11. I don't have a real test environment so can't really test that. I have bt.ransp_disposition set to 15 (default). @uthappyuser and @magao, and others... I think the rest of us are all just envious of your massive download bandwidth.
  12. I've seen utorrent 2.0 peers in various torrents, so it seems to me like that bug was fixed.
  13. I haven't seen these messages before. [2010-02-03 22:51:36] Reporting hang diagnostic information. [2010-02-03 22:51:36] http://www.utorrent.com/report_problem.php?v=67192320&h=y9w2Ka-5oGCRqmUy&w=17720006&p=hung&s=0&li=n:1:0:main:main:0&wm=68218:514:0:655552:2558931,68218:512:1:655552:2558884,68218:512:1:721088:2558869,68218:512:1:721087:2558853,68218:513:1:721087:2558837,461554:275:5:0:2558822,68218:512:0:721087:2558791,461554:275:1:0:2558791,68218:512:0:721087:2558759,68218:512:0:786622:2558635,68218:512:0:852157:2558541,68218:512:0:917693:2558510,68218:512:0:917692:2558494,68218:512:0:917691:2558494,68218:512:0:983227:2558479,68218:512:0:1048763:2558401,68218:512:0:1048762:2558401,68218:512:0:1114298:2558385,68218:512:0:1179834:2558369,68218:512:0:1310906:2558323 [2010-02-03 22:51:45] Hang reported successfully: [2010-02-03 22:51:45] http://www.utorrent.com/report_problem.php?v=67192320&h=y9w2Ka-5oGCRqmUy&w=17720006&p=hung&s=0&li=n:1:0:main:main:0&wm=68218:514:0:655552:2558931,68218:512:1:655552:2558884,68218:512:1:721088:2558869,68218:512:1:721087:2558853,68218:513:1:721087:2558837,461554:275:5:0:2558822,68218:512:0:721087:2558791,461554:275:1:0:2558791,68218:512:0:721087:2558759,68218:512:0:786622:2558635,68218:512:0:852157:2558541,68218:512:0:917693:2558510,68218:512:0:917692:2558494,68218:512:0:917691:2558494,68218:512:0:983227:2558479,68218:512:0:1048763:2558401,68218:512:0:1048762:2558401,68218:512:0:1114298:2558385,68218:512:0:1179834:2558369,68218:512:0:1310906:2558323 [2010-02-03 22:51:46] http://www.utorrent.com/report_problem.php?v=67192320&h=y9w2Ka-5oGCRqmUy&w=17720006&p=unhung [2010-02-03 22:51:48] Hang reported successfully: [2010-02-03 22:51:48] http://www.utorrent.com/report_problem.php?v=67192320&h=y9w2Ka-5oGCRqmUy&w=17720006&p=unhung
  14. I updated to RC5 and I have to give kudos to the developers: the upload, including overhead, follows the limit quite well. The jigsaw transfer rate that I saw on earlier RCs seems to have been resolved. (settings: net.calc_overhead=true. bt.connect_speed to 4 -- I had set it to 15 on 1.8.5 and, strangely, it didn't get reduced to 5 when I changed to RC5.)
  15. Ultima, Ondoy said it took 1.85 took a few seconds to get to maximum speed, but RC5 took 5 minutes (not 5 seconds)... Ondoy -- did you already post a graph of the speed ramp up for both 1.8.5 and RC5? It would most likely help the developers assess the problem.... Also... Just tested this on 1.8.5 and it has the same behaviour. I found that I can enable the Apply button by unchecking/checking "Enable scheduler" check box. IF I was making a decision on this Pref->Scheduler bug, I would not hold up rel 2 for this issue because (a) it existed in 1.8.5 and ( is not operation affecting.