Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#3870 closed Bug (duplicate)

transmission doesn't reannounce after getting initial 404

Reported by: sardok Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.13
Severity: Major Keywords:
Cc:

Description

I have seen this happen many times on different trackers: the tracker website will list a torrent that hasn't yet registered with the tracker backend and transmission gets an initial 404 and the torrent never starts downloading even after the torrent no longer 404s. I have to manually pause and resume the torrent for it download. Here is the debug info from the mac client (version 2.13+ (11622)).

2011-01-02 19:23:41 -0800 torrent.c:507 [Error] linux.iso: Tracker warning: "tracker gave HTTP Response Code 404 (Not Found)"
2011-01-02 19:23:41 -0800 announcer.c:1401 [Info] linux.iso: tracker gave HTTP Response Code 404 (Not Found)
2011-01-02 19:24:53 -0800 announcer.c:1662 [Debug] linux.iso: Scrape successful. Rescraping in 1800 seconds.
2011-01-02 19:24:53 -0800 announcer.c:1717 [Debug] linux.iso: Success
2011-01-02 19:54:55 -0800 announcer.c:1662 [Debug] linux.iso: Scrape successful. Rescraping in 1800 seconds.
2011-01-02 19:54:55 -0800 announcer.c:1717 [Debug] linux.iso: Success
2011-01-02 19:56:18 -0800 torrent.c:494 [Debug] linux.iso: Got 0 peers from tracker
2011-01-02 19:56:19 -0800 torrent.c:494 [Debug] linux.iso: Got 0 peers from tracker
2011-01-02 20:08:09 -0800 torrent.c:1705 [Info] linux.iso: Pausing
2011-01-02 20:08:10 -0800 Torrent.m:318 [Info] linux.iso: restarting via startTransfer
2011-01-02 20:08:12 -0800 torrent.c:494 [Debug] linux.iso: Got 0 peers from tracker
2011-01-02 20:08:14 -0800 torrent.c:494 [Debug] linux.iso: Got 39 peers from tracker

Attachments (2)

announcer.diff (3.3 KB) - added by jordan 10 years ago.
better, worse, or no change?
announcer2.diff (2.3 KB) - added by jordan 10 years ago.

Download all attachments as: .zip

Change History (32)

comment:1 Changed 10 years ago by gunzip

I've noticed this undesirable behavior in Linux also and sardok brings up an important issue: on a 404 tracker error Transmission gives up immediately and seems to wait for 32 minutes before scheduling another announce.

In contrast, rtorrent on a 404 error will try a reannounce 40 secs later, and if that fails will wait 60 secs and try again, and if that fails will try 80 secs later, etc etc. Because of the vagaries of trackers and the www Transmission should be far more aggressive in this respect.

comment:2 Changed 10 years ago by sardok

Even after 32 minutes nothing changes. I just came home and found another torrent stuck with no peers for 7 hours. I had to manually pause and resume again.

comment:3 Changed 10 years ago by miso

  • Severity changed from Normal to Major

I also experience this. I am using an RSS client to feed torrents into a watchdir for Transmission, but have to make the client ignore items that are too new so that Transmission doesn't give up on them.

comment:4 Changed 10 years ago by Lee

seeing same problem here. i have to switch to yet another tracker (3rd one so far) because transmission never gets any peers unless i manually intervene. it's beyond annoying that transmission doesn't retry like other clients.

comment:5 Changed 10 years ago by theclub

Me too. I'm having same problem with many torrents.

comment:6 Changed 10 years ago by Chromy

From my experience, this is mainly an issue with private trackers and their race to have the best "pre" time. And those are the ones I mainly use, so I switched to utorrent a while back. I keep hoping this issue will be solved so I can return to transmission.

Changed 10 years ago by jordan

better, worse, or no change?

comment:7 follow-ups: Changed 10 years ago by jordan

Could someone test out the attached patch and see if it changes anything?

comment:8 in reply to: ↑ 7 Changed 10 years ago by Lee

Replying to jordan:

Could someone test out the attached patch and see if it changes anything?

Thanks, I'm testing the patch now. Will have results tomorrow.

P.S. Had to google how to apply patch. Might be good idea to include instructions on wiki and link to them whenever a patch is added.

comment:9 in reply to: ↑ 7 Changed 10 years ago by gunzip

Replying to jordan:

Could someone test out the attached patch and see if it changes anything?

based on my first test with the patch yes it's definitely better. i made a torrent with a known non-working tracker and here is wireshark capture:

http://i56.tinypic.com/30kzgow.png

the time is in seconds. so yes it's much more aggressive with the announces. i still don't know why "transmission-remote -t ID --reannounce" doesn't work on these unless that is by design. also if you do a pause/resume it continues with the longer intervals on a fail rather than starting the cycle over with the smaller intervals.

Last edited 10 years ago by gunzip (previous) (diff)

comment:10 Changed 10 years ago by jordan

  • Milestone changed from None Set to 2.20
  • Owner set to jordan
  • Status changed from new to assigned

comment:11 Changed 10 years ago by jordan

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

Committed in r11730.

comment:12 follow-up: Changed 10 years ago by jordan

gunzip, the manual reannounce via transmission-remote is a different issue. You're not allowed to manually reannounce more frequently than the tracker's stated manual announce interval. IIRC, our default for this value is two minutes.

comment:13 in reply to: ↑ 12 Changed 10 years ago by gunzip

Replying to jordan:

gunzip, the manual reannounce via transmission-remote is a different issue. You're not allowed to manually reannounce more frequently than the tracker's stated manual announce interval. IIRC, our default for this value is two minutes.

jordan, yes i did know you have a default miminum interval of two minutes. however even if i wait 5, 10 or even 20 minutes after the last failed announce (404 error) --reannounce still does work as it should (confirmed by wireshark) -- it doesn't do anything even though it responds "success".

i believe this is an important bug as this is precisely the situation where a user would want to intervene but can not -- the only recourse is to pause/resume. below is another wireshark capture i let run a little longer:

http://i54.tinypic.com/24l4sxt.png

after accelerated intervals in the beginning eventually the interval goes to 32 minutes before a retry -- this behavior is OK. however what is not OK is "tr-remote --reannounce" refuses to work at all no matter how long i wait after the last failed announce.

EDIT:

libtransmission/announcer.c
...
    /* unless the tracker says otherwise, this is the announce min_interval */
    DEFAULT_ANNOUNCE_MIN_INTERVAL_SEC = ( 60 * 2 ),
...

so for some reason this is not being honored for the 404 errors. transmission is completely blocking the user from doing a manual reannounce.

Last edited 10 years ago by gunzip (previous) (diff)

comment:14 Changed 10 years ago by gunzip

  • Resolution fixed deleted
  • Status changed from closed to reopened

Changed 10 years ago by jordan

comment:15 Changed 10 years ago by jordan

gunzip, give announcer2.diff a try on top of svn trunk.

comment:16 Changed 10 years ago by sardok

I think I'm running into another problem, though the symptoms are almost exactly the same as what I posted in the original description of this bug minus the 404 issue. I'm still 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.

comment:17 follow-up: Changed 10 years ago by jordan

one topic per ticket, please. :)

otherwise it's impossible to ever close a ticket when an issue is fixed...

comment:18 Changed 10 years ago by gunzip

Replying to jordan:

gunzip, give announcer2.diff a try on top of svn trunk.

Test Condition: announcer2.diff applied to 2.20b1 (11733)

sorry but the --reannounce still doesn't work, even 5 or 12 minutes after the last 404 error. same result as previous patch.

don't know if this may be a clue or not, but when i connect to a WORKING tracker, transmission seems to respect whatever the minimum interval is and i can reannounce with no problem. it's only when transmission is in the "404 error" loop that the reannounce command is non-functional no matter how long i wait.

comment:19 in reply to: ↑ 17 Changed 10 years ago by sardok

Replying to jordan:

one topic per ticket, please. :)

ok, opened #3931

comment:20 Changed 10 years ago by jordan

after investigating gunzip's bug here, it looks like it's a separate issue, too. I've opened ticket #3934 for manual-reannounce-after-404s, and am closing this automatic-reannounce-after-404 ticket as fixed. ;)

comment:21 Changed 10 years ago by jordan

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

comment:22 Changed 10 years ago by jordan

  • Component changed from Transmission to libtransmission

comment:23 Changed 10 years ago by jordan

  • Summary changed from transmission doesn't recheck after getting initial 404 to transmission doesn't reannounce after getting initial 404

comment:24 Changed 10 years ago by jordan

  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening based on comment 24 in ticket #3931.

comment:25 Changed 10 years ago by gunzip

@jordan: "automatic reannounce after getting initial 404" seems to have been fixed in r11730, at least it was on my end, but what is not mentioned in this thread is subsequently r11784 came along and introduced a bit of a regression with respect to retry times:

the initial fix had accelerated tries in the beginning, and after repeated fails (404s) would top out at a 32-minute interval .. very reasonable. but now with r11784 the interval tops out at a whopping 2+ hours, which seems very half-hearted and might earn Transmission the reputation of "giving up" too easily.

-    return ( MIN( minutes, 128 ) * 60 ) + jitter_seconds;
+    return ( MIN( minutes, 30 ) * 60 ) + jitter_seconds;

i recompiled with above change in libtransmission/announcer.c and now the behavior is more like it was in your original fix (r11730). could this change be made permanent or are there other side-effects that would prevent it.

Last edited 10 years ago by gunzip (previous) (diff)

comment:26 Changed 10 years ago by jordan

Is this ticket any different from #3931?

After reading through the two tickets, it seems like this ticket is a slight variation on the symptoms, but the cause is the same.

comment:27 Changed 10 years ago by x190

Jordan, I think comment:25 by gunzip is complaining about line 1021 in announcer.c "default: minutes = 120; break;". He would prefer that the default was 30 minutes. Otherwise, as you say, if #3931 is fixed then this ticket should be as well.

comment:28 Changed 10 years ago by jordan

comment:25 here is probably not going to be implemented, for the reasons describe in comment 40 of #3931. Increasing the penalty for consecutive failures will help to keep unresponsive trackers from bottlenecking the http tracker announces.

comment:29 Changed 10 years ago by jordan

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

Closing this ticket because it seems to be a duplicate of #3931. If this is incorrect, please open this ticket with more information. Thanks!

comment:30 Changed 10 years ago by jordan

  • Milestone changed from 2.20 to None Set

(dupes shouldn't have milestones; it messes up the bookkeeping...)

Note: See TracTickets for help on using tickets.