Archived

This topic is now archived and is closed to further replies.

Firon

µTorrent 1.4.2 beta 435

Recommended Posts

All but 2 were from public trackers. :P The ones that got 0 hash fails were public torrents, funnily enough.

And um, I get stuff from public trackers all the time, I don't have any issues with 'em.

Share this post


Link to post
Share on other sites

8801.625: 67.164.57.47 : [Azureus/2400 ]: Disconnect: Invalid packet length

9282.750: 67.164.57.47 : [Azureus/2400 ]: Disconnect: Invalid packet length

9538.484: 67.164.57.47 : [Azureus/2400 ]: Disconnect: Invalid packet length

9701.656: 67.164.57.47 : [Azureus/2400 ]: Disconnect: Invalid packet length

9779.984: Banned 67.164.57.47

Each time there was invalid packet length, bam, hashfail. It may be a bug with Az 2.4.0.0, but since there were no µT clients in the swarm, I can't tell

Share this post


Link to post
Share on other sites

Tonight I shut off VPN (PPTP, IPSec) in the router.

Headed to the OpenOffice torrent to test.. it downloaded as fast as it could, so fast in fact when uncapped the crap router lost connection. no hash fails.. yay.

So I'll keep my fingers crossed that it was mostly a router issue. Hopefully. I'll know over time, but so far a good sign.

Btw, I don't know if this is a bug or just the nature of the protocol, but in my settings I have dl speed capped at 285 I think, but it was going at 333. When I uncapped it, it went a bit higher to 346 or so. Still, shouldn't the dl rate have remained lower around the 285 mark? It does great with the ul rate.

Share this post


Link to post
Share on other sites

It's quite difficult to cap the download rate accurately apparently. I've seen every program (even standard HTTP programs) have issues with getting it normal

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

I'm currently using build 426 and I'm downloading a 7,82 GB torrent with 2 MB peice sizes and

I have only got 1 hashfail and I have downloaded 91,7% of the torrent where half of the peers

I'm connected to are Azureus 2.4.0.0.

What could be the problem Azureus 2.4.0.0, is that maybe µTorrent isn't compatible with one

of Azureus encryption levels or that there is a bug with one of Azureus encryption levels.

Share this post


Link to post
Share on other sites

Bug?:

That's weird.. I just now looked at the log and there's a single hash fail on a queued item I haven't even started yet. In fact the 2 queued items have actually downloaded a couple megs each! How is that possible?

On hash failing:

So far so good.. since I twiddled around making sure my MTU was hardcoded to the same value as the router (1500), hardcoded a RWIN to a better value (32767) and turned off dmz gaming mode, upnp, ip multicasting, and VPN options, stuff seems better..

I am still getting the single isolated hash fail on a piece sporadically but it doesn't repeat itself. This is 'normal' behavior.

Of course I'm on different torrents now.. so we'll likely never know which end was the problem.. but I think 'for now' I am ok.

Still, that thing Firon spotted about the invalid packet length makes me wonder if all that torture I was going through was because of an Az client. I wonder if Az knows about it.

Btw guys, I don't think it's encryption.. these problems happen with or without it.

Share this post


Link to post
Share on other sites

I have bad news....

All torrents which I downloaded with recent beta versions of µTorrent *prior* to 427 fail a "force re-check". Since I was still seeding these with 427 it means that ***I*** have been the source of hash fails for other peers downloading these torrents.

So...................this means everyone (EVERYONE) who has been using any beta version of µTorrent prior to 427 MUST stop all their torrents and do a force recheck on every one of them or you will continue to "poison" the torrents you are seeding (or still downloading...see next paragraph).

This also applies to any extremely slow torrents you initially started downloading with a previous beta version and are still downloading with 427. I had one of those too and its "done" percentage was reduced when I did a "force re-check" on it.

This is why there have been several previous posts (from Firon and Boo, I believe) recommending that everyone stop and "force re-check" all their torrents. I think the problem has been known for a while now but no one has fully explained it.

Share this post


Link to post
Share on other sites

I checked all my torrents and all of them passed the hashcheck. on a torrent I'm downloading I only have 1 hash fail after 600MB downloaded (2MB piece size).

I'm using the latest public beta, didn't try the latest beta yet.

Share this post


Link to post
Share on other sites

argggghhhh.... i had 42 hashfails within 16 hours out of a 4GB torrent.

Can't be poisoned as i noticed a lot of hashfail from all the torrent since the last few betas.

Share this post


Link to post
Share on other sites

Does anyone know what the "piece cache" in Statistics is supposed to mean and why it's always so low (e.g. 10%)? I'd love to see separate overall read/write caching statistics implemented, which I don't think this is (at least I hope not).

Share this post


Link to post
Share on other sites

If the news media posted a headline "Invasion of small black spiders !" , then you can bet that suddenly everyone would notice small black spiders in their house that they previously had not noticed. :D:D

The same thing applies to hash fails and corrupted files. I had all of those things with 1.2 and 1.3 and ABC as well.

Just because one person has corrupted files doesn't mean the program is flawed.

Share this post


Link to post
Share on other sites

No hashfail issues with build 428, 0.15% failed. I believe that's normal. 5 of the hashfails were from one peer that got banned:

hashfails2zw.th.gif

Share this post


Link to post
Share on other sites

Thanks for the heads up on the new build ;P

--- 2006-02-21: Version 1.4.2-beta (build 428)

- Change: Smarter block hashing, tries to avoid re-reading from the file if possible.

- Change: Tracker connections obey max_halfopen/max_connections

- Change: Switching folder in the Add window tries to detect if you point at an already downloaded folder.

- Feature: Added log-to-file option in logger.

- Change: Added support for " in XML parser

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.