Opened 11 years ago

Closed 10 years ago

#3931 closed Bug (fixed)

"Announce is Queued" but torrent doesn't announce itself to trackers

Reported by: sardok Owned by: jordan
Priority: Normal Milestone: Sometime
Component: Transmission Version: 2.13
Severity: Normal Keywords:
Cc:

Description

This is very similar to #3870 minus the 404 issue. I'm seeing some torrents repeatedly not getting any peers even though the announce and scrape are successful. The torrent inspector shows there are loads of seeds, but the message window keeps logging "Got 0 peers from tracker" and nothing else, even under debug level. But if I manually pause and resume the torrents, I can connect to the seeds.

version: 2.13+ (11729)

Attachments (1)

announce.diff (10.3 KB) - added by jordan 11 years ago.

Download all attachments as: .zip

Change History (72)

comment:1 Changed 11 years ago by ijuxda

Could it be related to these bugs?

diff --git a/libtransmission/announcer.c b/libtransmission/announcer.c
index 231f2fe..1c99cae 100644
--- a/libtransmission/announcer.c
+++ b/libtransmission/announcer.c
@@ -645,7 +645,7 @@ publishNewPeers( tr_tier * tier, int seeds, int leechers,
     if( tier->tor->tiers->callback != NULL )
         tier->tor->tiers->callback( tier->tor, &e, NULL );

-    return compactLen / 6;
+    return compactLen / ( sizeof( tr_address ) + 2 );
 }

 static int
@@ -1197,7 +1197,7 @@ parseOldPeers( tr_benc * bePeers, size_t * byteCount )
         walk += sizeof( tr_address ) + 2;
     }

-    *byteCount = peerCount * sizeof( tr_address ) + 2;
+    *byteCount = peerCount * ( sizeof( tr_address ) + 2 );
     return array;
 }

comment:2 Changed 11 years ago by jordan

The former isn't a bug, but the latter is. Anyway the tracker peer parsing would be the same from announce to announce, so I doubt that's the issue. Xref: #3933

comment:3 follow-up: Changed 11 years ago by jordan

sardok, a question about the "2.13+" note here. Did this behavior exist in 2.13 as well?

comment:4 in reply to: ↑ 3 Changed 11 years ago by sardok

Replying to jordan:

sardok, a question about the "2.13+" note here. Did this behavior exist in 2.13 as well?

I couldn't say for sure, since the 404 issue was present at the same time and presented itself with very similar symptoms.

comment:5 Changed 11 years ago by sardok

This might actually be directly related to the 404 issue (#3870). I watched a torrent that initially had a 404, then it rescheduled the announce, and the announce and then a scrape succeeded. But the debug log still kept showing that it got 0 peers. After 5 minutes I paused and resumed the torrent and it was able to find the peers.

It might help if there were more debug messages. I've noticed that debug messages don't even include announces for private trackers, I only see LPD and DHT announces for the public trackers.

comment:6 Changed 11 years ago by sardok

I finally figured out the cause- the torrent gets posted to the site and initially there are no seeds. Some minutes later, the seeder joins, but transmission has already made it's announce request and is now waiting the min interval, which I'm guessing is ridiculously long (though that doesn't appear to be exposed anywhere by transmission). I determined this from the 'Last Announce' time field in the torrent inspector as well as the message 'Announce is queued'. When running transmission-remote -t $id --reannounce, it got it's peer list and all was well (7 hours after it was added).

What's strange is that all the 20+ other torrents in transmission at the time had the message 'Next announce in $time', not 'Announce is queued'. Could that indicate something more? Hint, hint- more debug messages would help.

comment:7 Changed 11 years ago by livings124

Trackers specify a minimum announce interval. If it's saying that the next announce is in 7 hours, that's what the tracker specifies and is required for Transmission to wait.

comment:8 Changed 11 years ago by sardok

No, 7 hours is when I manually renannounced. I don't know what the tracker's interval is because transmission doesn't show it to me anywhere; it could be 200 hours for all I know. But I'm suggesting Transmission try a bit harder if it gets 0 peers initially, since this happens regularly on several different tracker sites.

comment:9 Changed 11 years ago by livings124

I though you said the trackers has the message 'Next announce in $time'.

comment:10 Changed 11 years ago by sardok

No, the torrent inspector displayed that message for all the _other_ torrents; the ones exhibiting this problem displayed only 'Announce is queued'.

comment:11 Changed 11 years ago by livings124

Ah, I see

comment:12 Changed 11 years ago by jordan

'Announce is queued' is something that other people have reported too.

Looking through the announce code, our announce response handler seems either to complicated, or not sophisticated enough -- currently we differentiate between 2xx, 3xx, 4xx, and 5xx http response codes and use the ranges to decide whether or not to queue a reannounce.

However, some of those error ranges have individual error codes that require different handling, and we don't handle that. So in that regard, we're not sophisticated enough.

Maybe more importantly, some trackers don't always return the error codes you'd expect, so sophisticated error handling may be overkill anyway.

What we could do, is simplify the handling into two groups: 200 and everything else (except for redirects, which libcurl handles), and non-200 an error where we'll try to reannounce, but on intervals that increase on an exponential curve so that we don't hammer the tracker.

Changed 11 years ago by jordan

comment:13 Changed 11 years ago by jordan

  • Milestone changed from None Set to 2.21
  • Owner set to jordan
  • Status changed from new to assigned
  • Summary changed from Torrents not getting peers unless they are manually paused and resumed to "Announce is Queued" but torrent doesn't announce itself to trackers
  • Version changed from 2.13+ to 2.13

sardok: I'm revising this ticket's Summary to include the "Announce is Queued" phrase, which may help other people to find this ticket in the future. If I've misunderstood you, let me know and I'll change it back.

comment:14 Changed 11 years ago by jordan

  • Milestone changed from 2.21 to 2.20

Promoting to 2.20 for a third beta, based on feedback from the other transmission devs

comment:15 Changed 11 years ago by jordan

r11784 -- announce.diff committed to trunk

comment:16 Changed 11 years ago by jordan

sardok, does the patch make things better, worse, or no change?

comment:17 Changed 11 years ago by sardok

thanks jordan, i'll watch over the next day or two and report back.

comment:18 Changed 11 years ago by jordan

(jusid reports that powl(), which was added in r11784, doesn't exist on uclibc. Let's replace that call with simple bit shifting or with a switch statement...)

comment:19 Changed 11 years ago by jordan

jordan * r11790 libtransmission/announcer.c:

#3931 "announce is queued" -- minor revision for uClibc compatibility

jusid reports that powl() doesn't exist on uClibc, so getRetryInterval() needs to work without it. A simple left-bit shifting would be fine, but since we max out after a handful of cases, a switch statement seems slightly more readable than shifting or powl().

comment:24 Changed 11 years ago by sardok

Upgraded to 11784. Got a torrent today with an initial 404 and #3870 re-exhibited itself. The torrent inspector still showed 'Announce is queued'. Later, after I manually restarted it, the inspector displayed next announce in 30 minutes, so my assumption in comment #8 was wrong.

comment:25 Changed 11 years ago by sardok

Still seeing torrents with 'Announce is queued' problem. In one case there was a message 'Tracker did not respond', then it re-announced 2 minutes later and displayed 'Got 0 peers from tracker' and showed 'Announce is queued'.

comment:26 Changed 11 years ago by jordan

sardok, is this reproducible? If so, what specific steps should I take to recreate this behavior? Does it always happen with a specific torrent?

comment:27 Changed 11 years ago by sardok

I guess it's reproducible if you have a test tracker to emulate the behavior I described. What happens is many private trackers rush to publish torrents on their website as soon as they are available and the tracker either doesn't yet have the torrent (resulting in a 404) or the torrent has no seeder yet. The tracker usually syncs with the website within a few minutes, so the torrents work after that point- that's why manually pausing and resuming works. So I can't point you to a specific torrent.

This probably affects mainly folks who are broadcatching fresh torrents from private trackers.

comment:28 follow-ups: Changed 11 years ago by Astara

This bug is a dup of 3829. The symptom of 0 trackers is the first symptom of #3829 (it's listed in symptoms detailed '7 weeks ago' (sorry, date and time stamps seem to be unavailable or have been disabled in this bug tracking system -- odd for a bug tracking system, since referring to something with a date+time of '7 weeks ago' is cumbersome and not very productive).

Don't look for this being related to the announce period, since I've had torrents stay in the '0' peers state for well over a day (when the announce period on the tracker site was 30 minutes).

Increasing the number of torrents leads to transfers not being recorded by the tracker site. This has the effect of not giving credit for uploads (among other possibilities).

This bug affects old and new torrents (i.e. not just those broadcatching).

comment:29 in reply to: ↑ 28 Changed 11 years ago by ijuxda

Replying to Astara:

date and time stamps seem to be unavailable or have been disabled in this bug tracking system -- odd for a bug tracking system, since referring to something with a date+time of '7 weeks ago' is cumbersome and not very productive).

This annoyed me as well, until I discovered that the age text is wrapped in a link which contains a more precise date. It would be nicer though to just have an exact date shown somewhere in the comment, rather than making users mentally url decode the link and adjust timezones when they want to know this information.

comment:30 in reply to: ↑ 28 Changed 11 years ago by sardok

Replying to Astara:

This bug is a dup of 3829. The symptom of 0 trackers is the first symptom of #3829 ...

Don't look for this being related to the announce period, since I've had torrents stay in the '0' peers state for well over a day (when the announce period on the tracker site was 30 minutes).

Yes, I've noticed the same.

Increasing the number of torrents leads to transfers not being recorded by the tracker site. This has the effect of not giving credit for uploads (among other possibilities).

I just looked at the "snatchlist" from a couple of trackers and it is indeed not recording the download stats for about 1 out of every 10 torrents I have snatched.

This bug affects old and new torrents (i.e. not just those broadcatching).

That's good news then :) The more people it affects, the higher the priority.

Update: I just fully read your ticket and it seems like this should only be a problem when there are a lot of torrents. But I consistently see this when I only have a total of 10 torrents, where 5 of those are from the affected tracker.

Last edited 11 years ago by sardok (previous) (diff)

comment:31 Changed 11 years ago by ijuxda

The torrent inspector shows there are loads of seeds, but the message window keeps logging "Got 0 peers from tracker" and nothing else, even under debug level.

I just saw this for the first time with the gtk client (r11809). I had just added a torrent with 3 others already running and got an initial "400 bad request" response from the tracker, then the "got a list of 0 peers". I notice that the added torrent had only one tracker, and that this tracker was the same as for one of the other torrents. That torrent is now also showing the "got a list of 0 peers" with the same age (i.e. both say "X minutes ago") and the "queued to ask for more peers" status appears to be stuck for both of them.

comment:32 follow-ups: Changed 11 years ago by x190

I wonder how many of all these "Got 0 peers from tracker" issues involve private trackers. Private trackers sometimes have a complex set of rules governing when and by whom a given torrent may be downloaded. So, what users are seeing could be intentional behavior by the tracker rather than any Transmission error.

comment:33 Changed 11 years ago by sardok

I do mostly use private trackers, so have only noticed the problem on private trackers. But I have full privileges on those trackers, so it isn't a temporary wait issue. besides which, most trackers will return a useful error string in those cases.

Now that I know what to look for, I see that whenever this happens some of the other torrents from this tracker for which I am seeding have 0 peers. So I also believe this is a dupe of #3829.

comment:34 in reply to: ↑ 32 Changed 11 years ago by Astara

Replying to x190:

I wonder how many of all these "Got 0 peers from tracker" issues involve private trackers. Private trackers sometimes have a complex set of rules governing when and by whom a given torrent may be downloaded. So, what users are seeing could be intentional behavior by the tracker rather than any Transmission error.

None of the trackers I use are exclusively private. Besides I don't think whether you are public or private determines when your net connections get over-written or the tracker loses track of your upload and download amounts -- if anything I'd think a private tracker would be more interested in keeping track upload and download volume to be able to compute ratios.

comment:35 in reply to: ↑ 32 Changed 11 years ago by ijuxda

Replying to x190:

I wonder how many of all these "Got 0 peers from tracker" issues involve private trackers.

Just to clarify, the tracker that manifested the bug for me was a public http tracker and I am sure it was functioning correctly and actually had peers for the torrents in question.

comment:36 Changed 11 years ago by x190

"Announce is Queued" but torrent doesn't announce itself to trackers. This is the summary for this ticket. As of r11790 the following is the retry schedule you should see AFAIK.

1090    1089    getRetryInterval( const tr_tracker_item * t ) 
1091	1090	{ 
 	1091	    int minutes; 
 	1092	    const unsigned int jitter_seconds = tr_cryptoWeakRandInt( 60 ); 
 	1093	    switch( t->consecutiveAnnounceFailures ) { 
 	1094	        case 0:  minutes =   1; break; 
 	1095	        case 1:  minutes =   2; break; 
 	1096	        case 2:  minutes =   4; break; 
 	1097	        case 3:  minutes =   8; break; 
 	1098	        case 4:  minutes =  16; break; 
 	1099	        case 5:  minutes =  32; break; 
 	1100	        case 6:  minutes =  64; break; 
 	1101	        default: minutes = 128; break; 
 	1102	    } 
 	1103	    return ( minutes * 60 ) + jitter_seconds; 
1095	1104	} 

The "400 bad request" error could have numerous causes on both ends of the exchange as well as in between, so IMHO, that would be a separate issue if someone can show that Transmission is at fault. In any case, the "Got 0 peers from tracker" response would be expected given that the tracker is saying the request was malformed regardless of the cause of that malformation.

comment:37 follow-up: Changed 11 years ago by sardok

Well, only one person here mentioned '400 bad request' in the comments, so that wouldn't explain not getting any peers for the others. I usually either see an initial 404, or no error whatsoever, before entering the getting the 'Got 0 peers'. I got 3 of these torrents earlier today. Then I deleted all torrents I was seeding that have no peers, and the following 12 torrents I added all worked fine. More anecdotal evidence that it might really be #3829.

comment:38 in reply to: ↑ 37 ; follow-up: Changed 11 years ago by x190

Replying to sardok:

Well, only one person here mentioned '400 bad request' in the comments, so that wouldn't explain not getting any peers for the others. I usually either see an initial 404, or no error whatsoever, before entering the getting the 'Got 0 peers'. I got 3 of these torrents earlier today. Then I deleted all torrents I was seeding that have no peers, and the following 12 torrents I added all worked fine. More anecdotal evidence that it might really be #3829.

Yes, any error in the 400-500 range would result in not getting any peers. I'm just trying to clarify this ticket a bit as it's hard to tell exactly what problem you are reporting.

A: "Announce is Queued" but torrent doesn't announce itself to trackers. Would you say this is now fixed? If not, what are the exact symptoms you are seeing?

B: Considering that the 0 peers issue could be related to tracker errors, policy, or the fact that there are no peers in their list at a given time for a given torrent, do you have any other specific related issues? Would these issues be more efficiently addressed in a separate ticket?

comment:39 in reply to: ↑ 38 Changed 11 years ago by sardok

Replying to x190:

A: "Announce is Queued" but torrent doesn't announce itself to trackers. Would you say this is now fixed? If not, what are the exact symptoms you are seeing?

No, this is still a problem. I'm repeating myself now- the symptom is that added torrents get stuck in the 'Announce is queued' state, sometimes when there is an initial error, sometimes when the torrent initially has no peers, sometimes when the torrent is perfectly healthy (no error, lots of peers). I believe that all cases happen for me when I am seeding older torrents to the same tracker and those older torrents have 0 peers, but I wasn't paying attention to that fact when I first reported it. The detailed description of #3829 seems to account for this behavior.

B: Considering that the 0 peers issue could be related to tracker errors, policy, or the fact that there are no peers in their list at a given time for a given torrent, do you have any other specific related issues? Would these issues be more efficiently addressed in a separate ticket?

Tracker policy can be ruled out, at least for my case and response to part A above covers tracker errors and no initial peers. There is a separate ticket for the 404 issue, which can be expanded to cover any initial error. And there is ticket #3829, which might be the root cause of everything.

Last edited 11 years ago by sardok (previous) (diff)

comment:40 Changed 11 years ago by jordan

jordan * r11833 libtransmission/announcer.c:

(trunk libT) #3931 "'Announce is Queued' but doesn't get announced" -- remove the 'unresponsive tracker' penalty from torrents whose announce time has been reached.

The 'bad tracker' penalty was introduced in 2009 after a top tier trackers went down. Announces to it would hang, tying up an announce slot in libcurl for minutes at a time. If a user had enough torrents from that tracker, it could bottleneck all announce slots. The workaround was to deprioritize failing trackers so that they wouldn't obstruct other trackers:

  1. The interval between announces was longer for nonresponsive trackers.

  1. Once an unresponsive tracker's announce was ready to go, it would be bumped down the queue if other announces were ready too.

Part 2 probably contributes to #3931. If there are enough torrents loaded, there will always be good tracker announces that get pushed ahead of a bad one in the queue. Modifying 2's heuristics is one option, but it's simpler to remove it altogether because Part 1 has been strengthened by getRetryInterval()'s harsher grading for consecutive failures. Shifting the burden to getRetryInterval() also gives better visual feedback to users than Part 2 did.

This commit removes "Part 2" as described above.

If anyone seeing this behavior could give r11833 or higher a try and report back, that would be great.

comment:41 follow-up: Changed 11 years ago by jordan

Yet even more explanation: all but one of the move-to-the-front-of-the-queue loopholes have been removed. In general, the announce that's been queued the longest will be the next one to get processed.

https://trac.transmissionbt.com/browser/trunk/libtransmission/announcer.c?rev=11833#L1450

Last edited 11 years ago by jordan (previous) (diff)

comment:42 Changed 11 years ago by jordan

  • Milestone changed from 2.20 to Sometime

So, no feedback on r11833 yet?

comment:43 follow-up: Changed 11 years ago by sardok

I'm running r11842 and just encountered a torrent with an initial error of 'Tracker did not respond' followed by 'Announce is queued' and 'Got 0 peers'. Pausing and resuming the torrent manually immediately got 50 peers. This was on a private tracker and at the time I was seeding 7 other torrents on this same tracker, all with 0 peers. So it looks like this is still a problem.

comment:44 in reply to: ↑ 43 Changed 11 years ago by x190

Replying to sardok:

I'm running r11842 and just encountered a torrent with an initial error of 'Tracker did not respond' followed by 'Announce is queued' and 'Got 0 peers'. Pausing and resuming the torrent manually immediately got 50 peers. This was on a private tracker and at the time I was seeding 7 other torrents on this same tracker, all with 0 peers. So it looks like this is still a problem.

Sardok: This is not useful information. How long did the tracker stay in the "Announce is queued" state without re-announcing?

comment:45 Changed 11 years ago by sardok

The torrent was in that state for 20 minutes before I took manual action.

P.S. That was a pretty gruff response to somebody trying to help :(

comment:46 Changed 11 years ago by jordan

sardok, don't mind x190. he always gets that way when he's got a few drinks in him.

comment:47 Changed 11 years ago by jordan

sardok, iirc you're running transmission-daemon, right? How many torrents do you have loaded? Do the other torrents announce on schedule? Is it typically an isolated torrent (such as, maybe it's getting forgotten in the code somewhere) or do a lot of them go "queued" for a period and then clear out (as if there's a logjam effect of torrents trying to all announce at once)? Do other announces go through while one torrent stays queued for 20 minutes?

comment:48 Changed 11 years ago by sardok

I'm running Mac SVN version. I had a total of 16 other torrents active (seeding) at the same time. The other torrents were all announcing fine while the problem torrent was stuck, so it doesn't appear to be the result of a logjam. Before r11833, this would usually affect several torrents at a time when it happened. I don't think I have enough data to say if the situation has changed yet. My broadcatcher (rss reader feeding into a transmission watchdir) should be downloading another 8 torrents tonight, so I'll see if any of those are affected also.

comment:49 Changed 11 years ago by sardok

Reporting back. 11 more torrents from the same tracker and no problem, so this is probably solved. I'll keep watching over the week and see if it happens again.

comment:50 Changed 11 years ago by jordan

Thanks for the update, sardok. I'm glad to heard things seem to be better so far :)

comment:51 Changed 11 years ago by sardok

Encountered another one. First got a 404, then remained in 'Announce is queued' state and never attempted another re-announce. Manually paused and resumed it 5 hours later.

This time, though, the problem torrent was on a tracker on which I had never experienced the problem before. I had about 20 other active torrents (mostly seeding), but no other torrents to the tracker with the problem torrent.

version: r11852

comment:52 Changed 11 years ago by jordan

Interesting. did the 20 other torrents continue to periodically announce during those five hours?

comment:53 Changed 11 years ago by sardok

Yes, the other torrents were announcing fine during this time, though I had to search the log for 'from tracker'. Only DHT and LPD announces are explicitly logged in the debug log, so private trackers only show the 'Got x (peers|seeds) from tracker' in the log.

comment:54 Changed 11 years ago by jordan

Thanks sardok, that's helpful information. (I think. :)

I'm still not sure where the problem is, but the info over the last few comments are helping me to understand where it's not. . .

comment:55 Changed 11 years ago by jordan

Could you keep me posted if this happens again, and if so, whether or not it happened after the tracker returned an error, like the 404 you mentioned in comment:51?

comment:56 Changed 11 years ago by sardok

Will do.

comment:57 in reply to: ↑ 41 ; follow-up: Changed 11 years ago by x190

Replying to jordan:

Yet even more explanation: all but one of the move-to-the-front-of-the-queue loopholes have been removed. In general, the announce that's been queued the longest will be the next one to get processed.

https://trac.transmissionbt.com/browser/trunk/libtransmission/announcer.c?rev=11833#L1450

Is this the one loophole that's biting us? FWIW, while testing the udp tracker patch, I find the stuck in "Announce is queued" issue quite easy to reproduce with only two torrents both using the same two trackers. If one of those trackers is intially unresponsive at resume all the "queued stuck" problem arises. Pause and resume of individual torrents reverts to expected behavior (Announce in progress...).

comment:58 in reply to: ↑ 57 ; follow-up: Changed 11 years ago by jordan

Replying to x190:

Is this the one loophole that's biting us?

Probably not. Do you have reason to think it is?

FWIW, while testing the udp tracker patch, I find the stuck in "Announce is queued" issue quite easy to reproduce with only two torrents both using the same two trackers.

God only knows what kind of additional complications the udp tracker patch is adding. Please don't mix the UDP tracker ticket with this ticket; that one's for a new feature still in development and this one is a bugfix for existing code.

Last edited 11 years ago by jordan (previous) (diff)

comment:59 in reply to: ↑ 58 Changed 11 years ago by x190

Replying to jordan:

Replying to x190:

Is this the one loophole that's biting us?

Probably not. Do you have reason to think it is?

You have only stated that one loophole was left open but you haven't mentioned what it entailed.

comment:60 Changed 11 years ago by jordan

Yes, the one in that link is the one I was referring to (which is why I linked to it right after referring to it ;) but IMO it's a Good Thing and is probably not causing the problem described in this ticket...

comment:61 Changed 11 years ago by x190

jordan, have you considered the possibility that this issue is not caused by a queuing issue, as sardok and others have indicated that they are running ~20 torrents or much less, likely well under the 48 slots allowed as sardok uses private trackers, so likely only 1 tier per torrent?

It appears that the stuck tier has become completely forgotten by the code. Perhaps one of those comparisons isn't returning the result expected? Just offering a different POV. :)

Last edited 11 years ago by x190 (previous) (diff)

comment:62 Changed 11 years ago by jordan

x190: yes, that's what seems to be happening, but I'm not sure how/why. It's frustrating to not be able to reproduce the issue myself in testing.

sardok, any news? :)

Last edited 11 years ago by jordan (previous) (diff)

comment:63 Changed 11 years ago by sardok

I finally encountered the problem again, on a different private tracker this time. Had no other torrents from that tracker either. And the debug log didn't show anything relevant. Since the occurrences have decreased from several times a day to once every couple of weeks, I guess the priority of this bug is pretty low now. But if there's any debug messages you could add to help track this down, I'd be happy to finally give you some useful information :)

comment:64 Changed 11 years ago by sardok

Got another one. This time there was an initial 404, then stuck in 'Announce is queued'. Had no other current torrents from that tracker at the time.

comment:65 Changed 11 years ago by sardok

And another one. Same as last comment.

comment:66 Changed 11 years ago by jordan

sardok, what svn revision were you using when those last two happened?

There have been a lot of updates to the announce code over the last 3-4 days to add support for UDP trackers. If you haven't updated recently, you should probably get a new nightly.

comment:67 Changed 11 years ago by sardok

r12065 and r12130. I just updated to latest svn revision.

comment:68 Changed 11 years ago by sardok

Using r12261, and I got another one. Debug log only showed:

  announcer.c:981 [Info] $my_torrent_name: Could not connect to tracker

and the only logged activity after that was successful scraping. Pausing and resuming immediately pulled in a list of peers. Had a total of 21 other torrents seeding at the time and no other torrents to the same tracker with the problem torrent.

comment:69 Changed 11 years ago by jordan

That code looks like this:

979    /* set the error message */
980    dbgmsg( tier, "%s", err );
981    tr_torinf( tier->tor, "%s", err );
982    tr_strlcpy( tier->lastAnnounceStr, err, sizeof( tier->lastAnnounceStr ) );
983
984    /* switch to the next tracker */
985    tierIncrementTracker( tier );
986
987    /* schedule a reannounce */
988    interval = getRetryInterval( tier->currentTracker );
989    dbgmsg( tier, "Retrying announce in %d seconds.", interval );
990    tier_announce_event_push( tier, e, tr_time( ) + interval );

So it looks like a retry should have been scheduled even if the connection failed...

comment:70 Changed 11 years ago by sardok

Right, that's what it should have done, but 3 hours later and there was still nothing but scrapes in the log. The announce interval for that tracker is 30 minutes and I thought on errors, that transmission used an exponential delay. So I would have expected it to retry shortly after the initial error. Can you please add some debugging somewhere so I can give you some useful information to help pinpoint this problem.

comment:71 Changed 11 years ago by sardok

Got another one last night and just noticed it now. Stuck for 11 hours. Transmission (r12328) got an initial 'Tracker error: "unregistered torrent"'.

comment:72 Changed 11 years ago by jordan

r12333: add more debugging information for the next announce interval when an announce error is encountered, as requested by Sardok in comment:70 of #3931

comment:73 Changed 10 years ago by jordan

Is this still an issue in 2.31?

comment:74 Changed 10 years ago by sardok

No, I haven't experienced the since the last comment 7 weeks ago. Thanks!

comment:75 Changed 10 years ago by jordan

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

cool.

Note: See TracTickets for help on using tickets.