Jump to content

mcaspi

Established Members
  • Posts

    911
  • Joined

  • Last visited

Posts posted by mcaspi

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

    Thanks for the no feedback. It really motivates to try Alphas and Betas and give you guys feedbacks.

  2. "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' date=' announce and I see 8 peers. It looks like sometimes the peers number is increased dramatically.[/quote']

    This has nothing to do with that. There's nothing weird going on. You just don't always get the same number of peers from the initial request to the network. Don't clear your peerlist.

    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.

  3. test 12354651234234

    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.

  4. mcaspi, once you find hardware is broken...you can't change the software around to "fix" it..

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

    And if your ISP is mangling networking packets, uTorrent is limited in its ability to detect such corruption/slowing because many ways the ISP uses are going to resemble a lot of other causes/effects.

    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.

  5. If the problem is on their end, because they're using horribly broken networking software/hardware... there's not much that can be done through testing. :(

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

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

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

  8. I have that problem on ComCast, and attribute that mostly to older uTorrent versions' broken uTP implementation as well as having a tenuous connection to them.

    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.

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

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

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

×
×
  • Create New...