µTorrent Helper
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Ultima

  1. All other things assumed configured correctly, you can test using the OpenOffice.org torrent. If you can max your connection out, you're in good shape. Edit: Wow... lookie below... I've got psychic powers or something (jp xD)
  2. It's not just encryption, it's Azureus' encryption that's messed up. They fixed it in CVS already.
  3. Point taken, and noted above. I'm pretty sure Technarch was talking about b428, as was osmosis (clearly ;P)
  4. @Technarch: I'm not sure if you were being sarcastic, but if you weren't, I'll just tell you that the "Disk Overload" message has been around for a while. See if this thread helps you. Edit: Interestingly, I just saw that message for the first time as well (b428)... and I was only downloading at ~40KB/s... Oh well, I'll deal and live =P
  5. I believe you mean "touché" ;P
  6. If what Firon said earlier still holds, then that's my hunch as well... maybe shadek is making his claim prematurely ;P
  7. Hm... odd... the Azureus thing wasn't fixed in a public release, so if µTorrent wasn't the problem, then the hashfails should still be occurring. Maybe both clients had some problems. Oh well.
  8. Lookie at Firon's post just above... An Azureus dev fixed the problem in CVS, so it was actually Azureus sending bad pieces, not µTorrent corrupting them.
  9. Thanks for the heads up on the new build ;P
  10. Heh it's good to see someone at least looking through old threads before posting new threads... but continuing a discussion that did clearly end 4-5 months ago? Very odd xD
  11. Odd... I was playing with the download limiter today when downloading two different versions of OpenOffice.org too (when I was testing the columns for ascending/descending inconsistencies), and it was working just fine (FYI, I limited to 15KB/s for both torrents).
  12. Yeah it's *probably* established that build 427 still has the hashfail issue -- more than enough people have reported the problem =T
  13. Eh sorry if that first part of my message looked like it was pointed at you... krazyson had posted an image, to which I addressed him with that message (I guess the FAQ entry answered his questionless query =P).
  14. What are you trying to show? If you're showing that there's wasted data without any hashfails, this FAQ entry might be good reading for you =P (This part of the post was directed at krazyson, but he deleted his post) @rafi: I'd expect intuition to be correct in this situation ;P
  15. Why is it that when a piece fails, one particular peer is banned then (provided it fails enough times)?
  16. http://forum.utorrent.com/viewtopic.php?pid=47047#p47047 Firon was addressing s168pin, who offered his help for coding a WML version. Not sure if Directrix took up that offer, or if he (s168pin) stood behind the offer.
  17. I believe it all comes from one peer.
  18. While that's true, it's a rare occurrence. I agree, for the moment, it'd be best to go back to build 425 if you can't stand the hashfails.
  19. Hm... there have been an abnormally large amount of hashfail reports as of late... maybe the bug hasn't been fixed completely?
  20. Are you sure it's not the torrent that's poisoned? Just wondering =T
  21. Upside down...? Do you mean it's sorting descending instead of ascending? If that's the case, just click the column title again.
  22. Yeah... there are people who fake their client ID...
  23. Yes, it's possible. But it hurts the swarm -- the file(s) don't get distributed as widely as it possibly can, and it ends up becoming closer to HTTP transfer, thus losing most of the BitTorrent advantages.
  24. Hm... for people who really want to see it but disabled the underline thing for mouse clicks, press Alt, then Enter (not as a combination, but in sequence). You'll see what Firon's talking about =]