Jump to content

skynetman

Established Members
  • Posts

    24
  • Joined

  • Last visited

skynetman's Achievements

Member

Member (2/3)

0

Reputation

  1. in 2228 download limit is broken
  2. Bug in 1.6RC1 never happened before: Under # column all numbers disappeared. I can still order by # but i can't see them. Restarted utorrent fixed it.
  3. About disk cache: 1) In bytes read graphic i see it loads 128KB each time, even if the only file running is 701x 256KB. Shouldn't it load from disk at least a full piece? 2) Some clients as azureus request successive pieces to allow efficiency improvements to their caching algorithm. You could load more than one chunk each time if u know that u are talking with an azureus client 3) You could implement some sort of maxi piece (for example 10 pieces each) and then request the pieces inside in order, so that u can improve read cache hit and reduce the number of disk accesses. 4) I set 80MB of buffer and no matter what cache options i disabled i can't fill it all. It uses maximum half of it. Shouldn't it try to fill all the cache to improve cache hits? Bye
  4. Firon, when u use F2 to rename a torrent ad then u press esc because u want to keep the original name (in case u forgot what it was or pasted the wrong name), utorrent minimizes to tray too. It should only cancel the renaming.
  5. Firon, new cache system does not seem to clear cached data when u delete a completed torrent. Is that ok? What does it mean "hashing" line in read stats? it's # is increasing
  6. There is still a small bug. If "move completed downloads" is set and 2 torrents have been created by the author with same folder name, utorrent refuses to move the second torrent that completes and moves only the first torrent files. Files and folder of the second remain in "new downloads" folder.
  7. Ares: no one will activate encryption unless it's default option. No one cares about other's problem
  8. "use additional upload slots if...." has too high responsiveness: it opens even 4-6 slot almost simultaneously. U should set a limit to the number of slots that can be opened in upload to 1 per 10 seconds for every torrent IF ABOVE the slot number limit, else new clients steal bandwidth from existing ones. If u look at peer list ordered by upload speed u'll see what i mean.
  9. 2 files in download, 3 slot per file setting, upload speed limit at 16 (total up line speed = 32, so not capped): 12 total slots opened by utorrent with with "queue.dont' count slow upload" set at false. Usually setting to false decreased the number of opened slots, it seems has no effect. Doesn't they seem too many to you? 16 KB/12 slot= 1.3KB average upload speed per slot
  10. "Don't count slow upload = false" seems to have no effects. utorrent still opens the same amount of slots in upload.
  11. exactly. So u can remove "allow legacy" option and change "encryption, always" to "encryption always, when possible" to make it more clear.
  12. domz: if i disable that, will i be able to download from standard client without encryption? it is not clear. If the answer is yes, they should disable it automatically when setting encryption always
  13. Sorry guys but i do not understand. If i have ENABLED ALWAYS, and another 418 connects to me, we should ALWAYS have an E, even if he has disabled. Else how i can bypass my ISP? In fact i wasn't only uploading to him but downloading too and i was limited in download from that client at 1-2KB/s by my ISP. When i restarted the torrent then we had an E as we should. Is it more clear? How it is working now it's useless 50% of the time. if by chance i connect to him first, we have an E, if he connects to me first, we do not have it, even if in the future i start downloading from him.
  14. There is still a bug in 418. I have disabled outgoing encryption and a remote client has "enabled always" (both 418). Sometimes we have an E flag, sometimes not. It should always be encrypted as at the other side is forced. The first attempt had no E, i said him to stop torrent and restart and we had an E. It seems that if i start connection we never get encryption no matter what.
  15. Situation. A remote utorrent has "force encryption on data" and i must pass him some missing part of a file (i have outgoing enc disabled). When we both had beta 413 it was correctly showing E Now i updated to 417 and there is no more E. Is there a bug? EDIT: problem solved when he updated to 417
×
×
  • Create New...