skynetman

in 2228 download limit is broken

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.

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

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.

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

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.

Ares: no one will activate encryption unless it's default option. No one cares about other's problem

"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.

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

"Don't count slow upload = false" seems to have no effects. utorrent still opens the same amount of slots in upload.

exactly. So u can remove "allow legacy" option and change "encryption, always" to "encryption always, when possible" to make it more clear.

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

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.

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.

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

So turning PE on will reduce DL speed? Is this for sure or just a possibility? No i'm saying that disabling one type of incoming connection (referring to ENCRYPTION or not) can reduce your download speed. In fact if someone forces encryption and u refuse encrypted incoming connection u will not upload to him (and you will download zero to few bytes from him too) It's not peer echange.

Yes, a lot better Under "incoming connection" write IF U CHANGE THIS U WILL REDUCE YOUR DOWNLOAD SPEED TOO or pop up an alert just in case anyone wants to try

@Firon: so if someone wants from me data ENCRYPTED, does my client always accept? Better to add OUTGOING to options to make it clear

I think that peer exchange should be enabled by default without any option to disable it. What's the purpose in disabling it? Same thing for encryption. The final version should always accept standard and encrypted connections. There should be only one option IMHO: enable ALL traffic or not. In fact encryption has always to be enabled on one side, else it is not useful. If i am using a provider that limits torrent and want to bypass it, i enable encryption but other peer must have already enabled it. So hanshaking should always use encrypted connections, while encryption on data would be used only by the ones that need it. Right?