uTorrent not respecting minimum announce time

[Ultima]

@david999: I know you were only relaying the administrators' messages, but I'm just raising questions in general, not necessarily targeted at you. If it were a problem with µTorrent, I'd see it happening on every tracker I connect to. Unfortunately for that idea, I stared at 4 torrents yesterday, each on different trackers, and they all obeyed the announce time. I'm still not convinced the problem lies with µTorrent.

[david999]

I am not sure where the error lies but I believe the people at azureus had similar issues with their latest version and a patch was written, or so I have read. I have supplied this link to the affected trackers and would hope they can supply some input. Without seeing their logs I can only show this error message[announcing too fast no action necessary it will resolve itself ][error announcing too fast] but you do lose your stats while this is happening and it happens on most torrents from two of the trackers I am using. My ratio's are suffering accordingly, I hope between you the error can be found because yours is by far the best client and they are two of the better private trackers.

[alanmc]

Without seeing their logs I can only show this error message[announcing too fast no action necessary it will resolve itself ][error announcing too fast] but you do lose your stats while this is happening and it happens on most torrents from two of the trackers I am using. My ratio's are suffering accordingly

If uTorrent can't tell the tracker how much you've uploaded because it's "announcing too fast" then it can't tell the tracker how much you've downloaded either. So your ratio can't be affected.

[david999]

this also happens when seeding and that's when you lose your brownie points on some sites you don't get any credits until you upload x amount if when seeding you miss out on 15% of your upload stats this= no credits for upload at all

[supersoft]

uTorrent DOES NOT honour minimum announce time.

Here's part of my tracker's OK 200 response:

d8:intervali1800e12:min intervali60e5:peers|d2:ip13:xx.xx.xx.xxx.xxxx:peer id20:--------

If min interval was honored, uT should not allow another reannounce in less than 60 secs... but it does.

Azureus' announce button gets DISABLED during the 60 sec. period, as it should.

I know this functionallity is optional, but i'v read here that uTorrent does honor the flag. (but it doesn't).

[boo]

then there something wrong with your tracker, because if µTorrent didn't respect the minimum announce or

the flag, then lots of trackers would ban it, especially the big trackers.

[supersoft]

The fact that "big trackers" don't ban uT doesn't prove a thing; bitsoup & filelist, for instance, don't even send a "min interval" response or check it... (I've checked)

The fact is Azureus (a client I personaly dislike) honors the flag and uT does not.

No big deal, u can always implement an anti-hammering script -which I already have- but it would be nice if uT performed the way it says it does, so the tracker won't need to kick it until the next annouce. Would look neater, too.

I've also tested kTorrent in a Linux box and it also honors the min interval.

[Ultima]

If you're talking about the "Update tracker" thing not being disabled, that is not µTorrent disrespecting the min interval -- that's the user doing so. Could/should it be disabled? Perhaps, but if left alone, µTorrent does follow along, so µTorrent isn't disrespecting the interval.

If you are talking about the "Update tracker" thing, then what you're saying is almost like criticizing cars for not preventing accidents just because it doesn't just magically stop when it's about to get into an accident.

[imtcb]

ATM999 started this thread for me a while ago. I can 100% confirm that the issue I was having was resolved with the typo fix in RC1 of 1.6. The problems you guys are seeing are not the same as what I had.

From what I am reading, this would be more of a feature request to disable the manual update until the minimum interval time is met. If uT updates between the min interval and the interval everything is working fine. 60 second min inverval is seriously low.

For those that have had issues AFTER the typo fix in 1.6RC1 I suggest checking to make sure the correct spelling is being sent out. The typo in 1.5 could have matched up to a typo in your tracker that made you not have the issue then. Which would make sense if the problem started afterwards.

[supersoft]

According to BitTorrent protocol specs: http://wiki.theory.org/BitTorrentSpecification

# min interval: Minimum announce interval. If present clients must not reannounce more frequently than this.

it seems quite clear that the client must not reannounce, whatever the user does.

I guess this is precisely what this optional field is intended for: keeping the users from hammering the tracker's announce/scrape.

So this is not a "feature request", it's a SPEC -correctly honored by other clients who impede users from reannouncing below the minimum interval.

As for the car analogy, I'd say it's more like you shouldn't be allowed to keep on starting the engine if it's already running...

Besides, coding this should be a breeze:

(MInIntervalTimer > 0) ? UpdateButton.disabled : UpdateButton.enabled

[Ultima]

lol point taken regarding the analogy xD

I agree, it really is a simple fix, and it's actually something I wanted done a while ago (though I never really pushed it, nor have I ever really used the feature).

[supersoft]

Thing is I'm on both sides of the counter: am a personal user of uT & run a tracker... lol

uT is about the only client I ever use and I think it's great, but some very "nervous" users keep on ticking their refresh buttons all day long... That is what I'd like to avoid.

[Commodore64]

post # 43 2006-11-05 04:22:08

How many of these sites have spellchecked the script?

post # 44 2006-11-05 07:28:43

"I'm using a busted script that doesn't give the correct announce interval to clients, but I'll add an anti-hammering solution to the tracker just because I'm too lazy to spellcheck the announce script." Fun.

You know you guys are too funny! rather then investigating anything you bash everything and everyone else that doesn't agree

Ya know Harold I expected better from you rather then running with the pack !

post # 46 2006-11-05 18:22:11

I've seen enough cases of the spelling error come up to suspect that the original source of this anti-hammer code is broken.

Oh......really and what were they?? So let me get this right because utorrent doesn't like the spelling it hammers the announce??

Makes sense - ya right

Edit added this

In fact Harold didn't you ban it in the tracker you code ????

Yes, Me thinks you did...pifft for this very same reason and now you are defending it ????

Now that makes sense !!

/Edit

Look let me make this clear this client is seriously flawed in many ways anyone can see that and we (you) all know that...

So lets drop the pre-tense here k. I'm not going to list all of the flaws as you already know them

But the proof is in the pudding - so just track the hits to the tracker - like so..............

CREATE TABLE `ip_hits` (

`ip` varchar(30) NOT NULL default '',

`proxy_ip` varchar(30) NOT NULL default '',

`passkey` varchar(32) NOT NULL default '',

`agent` varchar(60) NOT NULL default '',

`lastaccess` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,

`hits` int(10) NOT NULL default '0',

`location` varchar(10) NOT NULL default '',

PRIMARY KEY (`ip`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

$ip = getip();

$ipp=getenv(REMOTE_ADDR);

$dt = gmtime() - 180;

$dt = sqlesc(get_date_time());

$agent = $_SERVER["HTTP_USER_AGENT"];

mysql_query("UPDATE ip_hits SET hits = hits + 1,lastaccess = $dt WHERE ip = " . sqlesc($ip) ."");

if (mysql_affected_rows () < 1) {

mysql_query("INSERT INTO ip_hits (ip, proxy_ip, passkey, agent, lastaccess, hits,location) VALUES (" . sqlesc($ip) ."," . sqlesc($ipp) ."," . sqlesc($passkey) . "," . sqlesc($agent) .", $dt, 1,'Announce' )");

}

Since all the talk is about private trackers I have added a provision for the passkey-

After adding this you will see that your client indeed does hammer the announce-

[DreadWingKnight]

Edit added this

In fact Harold didn't you ban it in the tracker you code ????

Yes, Me thinks you did...pifft for this very same reason and now you are defending it ????

Now that makes sense !!

/Edit

I implemented abusive announce detection in a preliminary stage, and NOT in the codebase that all these private trackers are using.

The instant you hit the PHP tracker codebase the private trackers are using, you no longer have this argument because:

> I haven't touched the abusive announce code in close to a year (SVN Revision 6 from CBTT's official SVN repo on http://svn.depthstrike.com).

> The code was labeled "Experimental" in the CVS and SVN changelogs.

> I discovered that there were major problems in my own codebase that I didn't have time to fix, so I backburner'd the code development.

> Private trackers use a PHP based tracker system. The one I code is NOT PHP.

http://wiki.depthstrike.com/index.php/Tracker_Information <-- my banlist with reasons. Nice of you to do your research.

[kenkopin]

If it is of any consequence, I am seeing 1.7.2 announcing too fast on a torrent. I am on TvTorrents.com and I have been on here for more than a year, the only thing different about this particular torrent is that there are a HUGE number of seeds and peers. Currently reading 0(1165) seeds and 12(212) peers. All the other torrents I do on here are acting fine. I have 4 active torrents going with Tvtorrents at the moment, and only this one is getting the Announcing Too Fast failure. I'm not manually updating the tracker, it's doing it all by itself.

Kenkopin

[DreadWingKnight]

kenkopin, your problem probably has to do with the fact that you have 4 torrents active with them at a time.

Does the problem persist if you reduce your active torrent count with them?

[kenkopin]

I have had as many as 10-12 open torrents (with this same tracker), and as few as one. This is the first time I have ever seen it do this. It ALWAYS seems to respect the 20 minute Failure counter, but when it goes back to the normal 30 minute counter, within 30 seconds, it'll switch to "updating..." and then come back with the Failure message again.

And yes, I shut down the other torrents to see if it helped. It didn't. I also don't have any "paused" torrents hiding at the bottom of the list.

I just watched it do it again. It was about a minute after the counter had reset to a normal 30:00 counter. (Like 1:10 or so. I blinked at the wrong time.)

---

Ok, it's now a couple hours later. I've stopped and restarted utorrent. It ran ok for a while, then started doing the announce too soon thing again.

I have also restarted the other torrents that I shut down earlier. They are still behaving normally.

---

Edit #2 - The next day.

Ok, uTorrent is still running, and I am no longer getting the announcing too fast failure. The only difference I can see is a reduction in the number of Seeds 0(1099) and Peers 3(31)

---

Edit #3 - Beginning to see a pattern...

Ok, the torrent from earlier has been behaving for a day now. 0(857) Seeds 1(28) Peers. I now however, have a NEW torrent acting up. Same tracker (tvtorrents.com)

IT'S currently at 0(486) Seeds and 34(219) Peers. Anyone else see what I see? Peers above 200 seems to be my culprit. Of course, someone will swoop in and tell me how that have run torrents with over 200 peers, and that I'm an idiot. That's fine, just as long as you can give me an alternative explination for what is going on... Oh! One other thing I forgot to mention is that both of the torrents are set for No DHT. That might be part of the cause.

---

Edit #4 - Version 1.7.4 no better...

Well, I seem to be talking to myself here, but I've now updates to 1.7.4, and just this morning, I have ANOTHER torrent announcing too fast. Peers 0(770) and Seeds 21(145). Another "No DHT" torrent on TVTORRENTS.COM. It always seems to be on very busy torrents.

---

Edit #5 - Version 1.7.5 as well..

Ok, look. I know there is a feeling that the people experiencing these problems are all cranks, but CLEARLY there are only two possible explanations for the phenomena people are seeing...

#1 uTorrent is broken in some subtle, devious way, which has escaped all current efforts to find it.

or

#2 Something about specific trackers (especially ones using "anti-hammer" code) is goading uTorrent into updating well before the timer says it should.

Either way, doesn't it seem like something that should be fixed?

---

Edit #6 - An offer to help...

Ok, I think part of the problem is that the people who can fix this are having difficulty seeing the problem for themselves. This is fixable. I have the ability to create an account on the torrent server I'm on with enough credits to cover whatever amount of trading you would end up doing, and can tell you what torrents you will want to watch for to ensure you encounter the same problem. Fortunatly, weekly TV series are very predictable in their arrival and popularity.

If anyone in authority on this forum wishes to take me up on this offer, please contact me through the forum, or just leave a reply to this post, and we'll work something out. I can probably manage as many as three accounts of this type, as long as the people asking for them are legitimate utorrent coders, or forum moderators. I'll check first, so no funny business, people.

[MIODude]

I was watching mine just now,

The announce countdown started at 30 minutes.. counted down to 29:05, then jumped to 0:04 and continued counting down to 0 then re-announced.. Then, back to 30 minutes.. down to 29:10, then started counting down from 0:10 to 0 again, then re-announced.. After that, i got the "announcing too fast" error. Can the tracker cause the utorrent to change the countdown suddenly to a different value and continue counting down?

[Ultima]

A tracker can't make µTorrent change the announce time until µTorrent has run down the tracker's previously-specified announce interval, and receives the interval again (updated or not) in the next announce.

[Saribro]

I've seen this happens once (on 1.7.5). Just the once though, never before or since. Announce interval was set at 60 minutes, countdown started, then at ~57 minutes µTorrent reannounced, countdown reset, at ~58 minutes reannounce. I stopped the torrent, restarted µTorrent, started the torrent again: Everything back to normal.

Extremely strange, but it really happened .

[DaVrOS]

Yes, its had that bug for a while - I thought everyone knew.. maybe I should have mentioned it a while back. Azureus does the same thing.

Azureus actually does it much worse than UT does. We had to re-write the tracker code just to deal with it just to deal with it.

We found that UT - even though it did it.. it wasnt to the same degree as Azureus.

That was comparing UT 1.7.2 and Azureus 2.5.0.4 though.

Also noticed it seems to affect some trackers more than others.

[elow]

sorry for bringing up this old thread but i've got exactly the same problems with 1.8.4 and some older versions, too.

[DreadWingKnight]

The amount of information you have provided is painfully lacking.

[elow]

why should i repeat what has been described several times in this thread already?

but anyway

I was watching mine just now,

The announce countdown started at 30 minutes.. counted down to 29:05, then jumped to 0:04 and continued counting down to 0 then re-announced.

exactly the same here. after then it's fine tho. and it's not on all trackers but on the majority.

well, nothing new at all as i said.

[DreadWingKnight]

What state was the tracker in for those 55 seconds?

What is the minimum interval defined for the offending trackers?