mcaspi

Established Members
  • Content Count

    911
  • Joined

  • Last visited

Everything posted by mcaspi

  1. Thanks. One more thing. I recently made a fresh install of version 3.1 and the setting for outgoing connections in Protocol Encryption is Disabled (was Enabled before). Is this the recommended setting these days?.
  2. Build 25760 isn't on auto-update yet? Or "Update to beta versions" updates to betas only and not alphas that need a manual update.
  3. Thanks for the no feedback. It really motivates to try Alphas and Betas and give you guys feedbacks.
  4. Got 3 seeding torrents, 1 on hard disk and 2 on a USB device. "Completed" and "Seeding" shows (3) but the only torrent that is there is the one on the hard disk. Also, "Clear peer list" doesn't change the (X) numbers in "Seeds" and "Peers" columns immediately. I see the correct numbers only later.
  5. What is the reason the # of peers on DHT dropped from ~200-300 max in 2.x to typical 20-50 in 3.x ? Yesterday I also got 30,60,... nodes. Today it looks fine.
  6. Had it once. Deleted dht.dat and dht.dat.old and then it got fixed.
  7. I'm talking about an increase within minutes (between two announces one after the other) and not from the initial request to the network. If I'm used to see around 10 peers in DHT and 25 peers on the next announce, I don't understand why it happens so fast. And I see around 330 peers on 3.0. Edit: Seeing it again. Got 27 peers and didn't like it. Cleared peers list after less than 5 minutes, announced and got 6. It looks like each announce gives a different numbers of peers.
  8. "Fix: DHT responses would sometimes be invalid" Still see weird things with DHT. At one point I have 10 peers max. A few minutes later there are 25 peers. Clear peer list, announce and I see 8 peers. It looks like sometimes the peers number is increased dramatically.
  9. Great work guys. Thanks a lot.
  10. Firon, I see users that want to change to Vuze because uTorrent doesn't work the way it used to work and they're right. If you find this funny, and you find it is also funny that someone is trying to help improve the software so these users won't switch to other clients, then you may continue.
  11. Why not?. Detect a bad uTP connection and if you find it, "mark" this connection as a "non uTP" for, let's say, the rest of the session, and switch to the old running TCP connection. Why being stuck with the "All mighty uTP"?. Switeck, I'm almost sure that if BitTorrent was able to make the softwares it's made, it can find a way to detect bad uTP connections. Just watch a change from a working TCP connection to a bad uTP connection and you'll see a total mess there. BitTorrent just needs, in my opinion, to get rid of the fixation about uTP because it looks like things work on broken hardware when using TCP.
  12. Why not changing the connection to TCP which work on that specific connection, the same way I manually do it? . In my opinion I showed you a problem. If you think that a sudden drop in the speed from X kB/s to 0 immediately after switching to uTP and starting the transfer (or in other words "no transfer") is not a problem that uTorrent can fix, then I'd like to show you how Wikipedia describes a bug (in my opinion): "A software bug is the common term used to describe an error, flaw, mistake, failure (to transfer data), or fault in a computer program or system that produces an incorrect or unexpected result (data is not transfered), or causes it to behave in unintended ways (data is not transfered). Most bugs arise from mistakes and errors made by people in either a program's source code or its design".
  13. Whatever reason it is, observations show me more active connections and faster transfers using TCP and part of the problem might be uTorrent's fault. Maybe this TCP/uTP issue is why many users complain that the new versions are slower than the older ones.
  14. Another case. My 2.0.4 connected to 2 peers using 2.0.4 on the same ISP (them) and transfering TCP. When I enable uTP, the transfer continues to one of them. To the other, the transfer drops to 0. In my opinion uTP needs more testing.
  15. I did that change even before you wrote it (asked just to make sure). In this certain connection speed dropped to 0. It looks like the remote client chooses uTP as the connection type. It looks to me that certain client versions can't make a good uTP connection and that is why I choose to disable it.
  16. If that is so, why not disable uTP in those cases by software. I (2.0.4) download at 20-30 kB/s from a Bittorrent 7.0 peer using tcp. uTP drops it to 0.
  17. Thanks. I'll continue to watch this.
  18. Don't use a router. The problem happens with some peers, not all of them. I can run the client using uTP but the thing is that the transfers with some peers will drop to 0 so I don't use it. That is why I guess it is related to the isp's.
  19. I disabled uTP on my client. Found out that some isp's don't like uTP transfers. Shawcable is one of them. The moment the connection is changed to uTP speeds drop to 0. And this is one of the suggested changes in the settings to speed up transfers.
  20. mcaspi

    Flags

    nope. settings.dat is in %AppData%\uTorrent and utorrent.exe in in C:\Program Files\uTorrent.
  21. mcaspi

    Flags

    flags.conf and flags.bmp are in my %AppData%\uTorrent, peer.resolve_country is false,domains are in the .conf file and I get the American flag.
  22. mcaspi

    Flags

    Yep. I'd like to ask a question. Does uTorrent determines the flag by looking at the resolved IP first. If the answer is yes then this is the problem in my opinion. I think that it should look in flags.conf first because the exceptions are there and if there is no match, look at the resolved IP.