Opened 12 years ago

Closed 12 years ago

#2854 closed Bug (fixed)

Transmission doesn't retry an announce when the "tracker did not respond"

Reported by: rlavriv Owned by: charles
Priority: High Milestone: None Set
Component: Transmission Version: 1.83
Severity: Normal Keywords:
Cc: zulu.walker@…, tb@…

Description

Lots of "Tracker did not respond" errors are appearing when running Transmission 1.83 on DLink DNS-323 for some time (after approx half a day 50% of my 16 torrents turned red with stated error). Seems that Transmission is not re-querying tracker or there is connections leak.

Change History (38)

comment:1 Changed 12 years ago by charles

Does this problem persist in the nightly builds at http://transmission.xpjets.com/ ?

comment:2 Changed 12 years ago by rlavriv

I'll try to test with nightly snapshot.

comment:3 Changed 12 years ago by charles

trunk, r10095: libtransmission/announcer.c: (trunk libT) #2854 "tracker did not respond" -- when both scrapes and announces are vying for a turn, give announces a higher priority

comment:4 Changed 12 years ago by charles

trunk, r10085: taper off the number of new connections per pulse per torrent based on how long the torrent's been running. Brand-new torrents get a higher burst of new peer connection attempts, but long-running torrents don't need that kind of activity.

The goal of this patch is to prevent router overload by lessening the churn of new peers after torrents have reached steady state.

comment:5 Changed 12 years ago by charles

Side note: I've tried connecting to some of my trackers via "telnet hostname port" and get response times of anywhere from 1 second to 2 minutes. some timeouts are going to be unavoidable and the only thing we can do is try to handle them gracefully...

The commits above are to try to address some possible cumulative error from overloading the router, or through announces getting buried or backlogged. Other users chiming in with "still broken, I get a `tracker did not respond' error too" should reread the OP ;)

comment:6 Changed 12 years ago by charles

r10096 "Tracker did not respond" -- when calculating the interval to wait before retrying a failed announce or scrape, take into account that tracker's responses to other torrents' announces/scrapes. That way nonresponsive trackers will be less likely to logjam the announce/scrape queue

comment:7 Changed 12 years ago by charles

r10098 (trunk libT) #2854 "`tracker did not respond' errors" -- lengthen the time we wait before timing out. This was shortened not too many releases ago to prevent a logjam from dead tpb tracker announces; however, we now have better ways of doing that and the short deadline may be contributing to the "did not respond" errors.

comment:8 Changed 12 years ago by charles

r10099 (trunk) add a new field to distinguish from error messages returned from the tracker, and announce timeouts, so that they can be displayed differently. This is somewhat related to #2854

comment:9 follow-up: Changed 12 years ago by zulu.walker

  • Cc zulu.walker@… added
  • Priority changed from Normal to High

Build 10157 taken off svn and compiled for the DNS-323 still exhibits this error - "tracker did not respond" errors occur anywhere from upon startup of the daemon/GUI until after a few hours. Errors do not occur with 1.76 (9410) built for DNS-323.

comment:10 in reply to: ↑ 9 Changed 12 years ago by charles

Replying to zulu.walker:

Build 10157 taken off svn and compiled for the DNS-323 still exhibits this error - "tracker did not respond" errors occur anywhere from upon startup of the daemon/GUI until after a few hours. Errors do not occur with 1.76 (9410) built for DNS-323.

Keep in mind that we need to distinguish instances of an actual bug from an unresponsive tracker or overloaded router. If you're able to repeat this on multiple public trackers on a consistent basis, that's worth looking into... for example if you get those errors from startup until after a few hours on legaltorrents.com please say so.

comment:11 Changed 12 years ago by KyleK

To quote someone else from the DNS-323 forums:

After 16 hours of seeding (130 torrents) on 1.83 svn test build there are no any red arrows.

I've never noticed that problem myself, so I can't really comment on it.

comment:12 follow-up: Changed 12 years ago by KyleK

The situation has changed, it seems. Above user now writes:

Unfortunately, almost 24 hours after installation got a lot of red arrows.

Where are those arrows coming from? I've never seen an arrow in the Transmission WebGUI :)

comment:13 in reply to: ↑ 12 Changed 12 years ago by zulu.walker

Replying to KyleK:

The situation has changed, it seems. Above user now writes:

Unfortunately, almost 24 hours after installation got a lot of red arrows.

Where are those arrows coming from? I've never seen an arrow in the Transmission WebGUI :)

Probably from using Transmission Remote GUI (or dotnet), which I also use (and have those arrow icons).

@charles: As previously stated, changing back to an earlier version (such as 1.76 or even 1.82 - where it is allowed) does not exhibit the same problems. The connections, tracker, and torrents in question are one and the same in all testing situations which certainly isolates 1.83 (10040 and 10157 - the ones I've tested) as the culprit.

comment:14 Changed 12 years ago by charles

come by to #transmission in freenode and tell me which tracker I should be testing with for this?

comment:15 follow-up: Changed 12 years ago by rlavriv

After some investigations, I have found out that actually Transmission daemon is handling this error fine, and I see myself in list of seeds on tracker, but the Transmission Remote GUI still displays error. The tracker I refer to is torrents.ru

comment:16 Changed 12 years ago by rlavriv

I can also confirm that SVN build 10157 didn't resolve the issue.

comment:17 Changed 12 years ago by moonly

  • Severity changed from Normal to Major

I have a similar problem where I get "tracker did not respond" on only certain trackers but not others.

comment:18 follow-up: Changed 12 years ago by livings124

  • Severity changed from Major to Normal

moonly: How do you know that these certain trackers aren't down/blocking you?

comment:19 in reply to: ↑ 18 Changed 12 years ago by moonly

Replying to livings124:

moonly: How do you know that these certain trackers aren't down/blocking you?

I made sure to contact the tracker admins before posting here. They said that it was an issue with my current build of Transmission.

comment:20 follow-up: Changed 12 years ago by livings124

If you load up Transmission 1.76 or earlier, does it announce successfully?

comment:21 in reply to: ↑ 15 Changed 12 years ago by charles

Replying to rlavriv:

After some investigations, I have found out that actually Transmission daemon is handling this error fine, and I see myself in list of seeds on tracker, but the Transmission Remote GUI still displays error. The tracker I refer to is torrents.ru

Transmission Remote GUI is a third-party product not released or supported by the Transmission team. You need to report that issue to the Transmission Remote GUI developers at http://code.google.com/p/transmisson-remote-gui/issues/list

comment:22 in reply to: ↑ 20 Changed 12 years ago by moonly

Replying to livings124:

If you load up Transmission 1.76 or earlier, does it announce successfully?

I have yet to try downgrading but from user posts on the trackers forums, this does work successfully.

comment:23 Changed 12 years ago by livings124

Can you come into our irc room #transmission on freenode so we can get more info?

comment:24 Changed 12 years ago by livings124

The discussion off-ticket with moonly points to this being a connection issue on the tracker's end.

comment:25 Changed 12 years ago by charles

  • Summary changed from "Tracker did not respond" errors to Transmission doesn't retry an announce when the "tracker did not respond"

Okay this has turned into the ticket I was afraid it would back in ticket #5 -- some announcment failures are just going to happen, and that's all there is to it. The question, as the OP correctly stated, is whether or not Transmission re-queries the tracker. I've changed this ticket's summary to reflect that.

The commits above are to try to address some possible cumulative error from overloading the router, or through announces getting buried or backlogged. Other users chiming in with "still broken, I get a `tracker did not respond' error too" should reread the OP ;) Sideissue #1: The issue moonly saw appears to have been due to network problems. Connecting to his tracker's announcer URL's host/port was slow (or failed) even from a machine with no p2p running. That is not a Transmission bug.

Side issue #2: It appears Transmission Remote { gui, dotnet } are putting up some arrows or something when there's an announce failure, which is not something that we can control. This is possibly a misguided feature for torrents that have dozens of trackers... in those cases if a single tracker is offline, does the user really need to be notified? Anyway those issues should be raised with the authors of those GUIs, which have their own bug trackers.

I think the original issue is now fixed, but I'm going to leave this ticket open for discussion for a little while longer in case that's wishful thinking. :)

comment:26 follow-up: Changed 12 years ago by entropy

  • Cc tb@… added

I believe I have the same issue with versions of transmission greater than 1.82. With 1.83 and 1.90 using the trackers tracker.ourgtn.org:2710 and inferno.demonoid.com:3392 Transmission gives both announce and scrape errors on all torrents. It seems to be able to do DHT etc. fine, just not talk to the tracker at all.

Reverting to 1.82 fixes the issue. The trackers are up and very responsive, and I have no problems whatsoever connecting using 1.82, so I figure the issue must be with 1.83/1.90 rather than with the trackers.

comment:27 Changed 12 years ago by howl

One member of a tracker I moderate has reported that 1.83 and 1.90 are affected by this bug, he haven't tested 1.91. He is using Ubuntu 8.04 (hardy). At the same time members with 1.90 and 1.91 seems to not be affected by this bug under jaunty and karmic.

Could be related to the libevent version and the new dns system?

comment:28 Changed 12 years ago by howl

Update, 2 users with ubuntu hardy reported.

comment:29 Changed 12 years ago by charles

Howl: please read comment #25.

comment:30 Changed 12 years ago by howl

Sorry about it, it's not the same issue.

comment:31 in reply to: ↑ 26 ; follow-up: Changed 12 years ago by charles

Replying to entropy:

I believe I have the same issue with versions of transmission greater than 1.82. With 1.83 and 1.90 using the trackers tracker.ourgtn.org:2710 and inferno.demonoid.com:3392 Transmission gives both announce and scrape errors on all torrents. It seems to be able to do DHT etc. fine, just not talk to the tracker at all.

That's not what this ticket is about...

comment:32 in reply to: ↑ 31 Changed 12 years ago by entropy

Replying to charles:

That's not what this ticket is about...

Oh, well in that case I shall log a new ticket...

comment:33 follow-up: Changed 12 years ago by charles

  • Owner set to charles
  • Status changed from new to assigned

Okay. Whether or not timeouts occur, it does seem to be the case that Transmission will try again when they do occur, so this ticket is fixed.

comment:34 Changed 12 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:35 in reply to: ↑ 33 ; follow-up: Changed 12 years ago by slazZ

Replying to charles:

Okay. Whether or not timeouts occur, it does seem to be the case that Transmission will try again when they do occur, so this ticket is fixed.

I think it's true that transmission retries announces, because the tracker-daemon would timeout clients if they stop announcing (which, in my case, don't happen even transmission-remote-gui give me a "tracker did not respond" error), but: If such an annouce-error occur it seems that this is saved in the field "lastAnnounceResult" you can fetch via rpc. And even though the latest announce resulted in a "Success", the value of this field remains at "tracker did not respond". This behaviour is just a guess, though.

comment:36 in reply to: ↑ 35 Changed 12 years ago by slazZ

Replying to slazZ: might be caused by #2828

comment:37 Changed 12 years ago by slazZ

  • Resolution fixed deleted
  • Status changed from closed to reopened

Hope you don't mind that i reopen this ticket, otherwise this bug would get no futher attention. Or should I create a new ticket?

comment:38 Changed 12 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

slazZ: that's a separate issue.

Note: See TracTickets for help on using tickets.