Opened 10 years ago

Closed 9 years ago

#4638 closed Bug (fixed)

Transmission sends an initial 'stopped' event when adding a torrent via RPC

Reported by: ankel Owned by: jordan
Priority: Normal Milestone: 2.72
Component: libtransmission Version: 2.42
Severity: Major Keywords: announce event stopped started
Cc:

Description

If a new torrent is added to transmission-daemon through web-interface (maybe also from a Qt,Gtk) the first announce is sended to tracker with a event=stopped state. This lead to an announce error and impossibility to download on private tracker that i'm using.

After a daemon restart or if the failing announce url from the same Tier is deleted, then next announce work normally with a event=started being sent.

Attachments (3)

annc-err-fix.patch (487 bytes) - added by cfpp2p 9 years ago.
tr-4638-rev-02.diff (904 bytes) - added by jordan 9 years ago.
tr-4638-rev-03.diff (884 bytes) - added by jordan 9 years ago.

Download all attachments as: .zip

Change History (27)

comment:1 Changed 10 years ago by ankel

Looks like this is only tied to transmission-web or transmission-rpc. Because if the torrent is added without the "Start when added" option and left with Paused state then manually starting the torrent works fine with the right event=started sent to tracker.

comment:2 Changed 10 years ago by gunzip

ankel: i tried "Start when added" option with web-client and a private torrent and found that the event=stopped is initially sent as you mentioned, but it is immediately (within a second or two) followed by another announce with event=started. the torrent connected fine, so from what i can see it's a moot point. i ran a few tests as:

$ TR_CURL_VERBOSE=1 transmission-daemon -f

using transmission-daemon 2.42+ (13095), Linux Debian

comment:3 Changed 9 years ago by briped

I'm using the built-in transmissiond that comes with Synology DownloadStation? (transmissiond 2.42 (13013)). I can see that this issue isn't fixed in the 2.51 (when reading changelogs).

When adding through webinterface, certain (one specific that I know of) private trackers will return the error "client sent event=stopped". Most trackers will just work around this, although this specific tracker is very adamant that they will not work around it, that it should be fixed in the client.

According to the BTP specification, this is what I found about the event request:

event: If specified, must be one of started, completed, stopped, (or empty which is the same as not being specified). If not specified, then this request is one performed at regular intervals.

started: The first request to the tracker must include the event key with this value.

Pausing the torrent and starting it again works. Adding torrents using a pickup folder also works as expected.

comment:4 Changed 9 years ago by livings124

#5022 is a duplicate of this.

comment:6 Changed 9 years ago by Twoz

Does someone know how to fix this?

comment:7 Changed 9 years ago by jordan

  • Status changed from new to assigned

comment:8 Changed 9 years ago by jordan

  • Milestone changed from None Set to 2.72

comment:9 Changed 9 years ago by jordan

Confirmed. Here's an excerpt of the TR_DEBUG_FD log that I get adding a clearbits torrent from the web client:

[11:55:25.994] [Rob Hunter - The Return of the Orange Virgin MP3 Audiobook---http://tracker001.clearbits.net:7070] Sending announce to libcurl: "http://tracker001.clearbits.net:7070/announce?info_hash=%09%86Y%8f%df0%1f%c6%ae%5c%03%2f%ce%01%d3%b1%d1rMe&peer_id=-TR261Z-388ngl7moyms&port=52523&uploaded=0&downloaded=0&left=537872541&numwant=0&key=33ae45b7&compact=1&supportcrypto=1&event=stopped" (announcer-http.c:301) [11:55:27.786] [Rob Hunter - The Return of the Orange Virgin MP3 Audiobook---http://tracker001.clearbits.net:7070] Sending announce to libcurl: "http://tracker001.clearbits.net:7070/announce?info_hash=%09%86Y%8f%df0%1f%c6%ae%5c%03%2f%ce%01%d3%b1%d1rMe&peer_id=-TR261Z-frbgkmi56lyl&port=52523&uploaded=0&downloaded=0&left=537872541&numwant=80&key=33ae45b7&compact=1&supportcrypto=1&event=started" (announcer-http.c:301) [11:55:28.190] [Rob Hunter - The Return of the Orange Virgin MP3 Audiobook---http://tracker001.clearbits.net:7070] Sending periodic reannounce in 1800 seconds (announcer.c:1178)

comment:10 Changed 9 years ago by cfpp2p

problem is torrentInit() calls tr_torrentVerify() and when doStart is true verifyTorrent() calls tr_torrentStop() which eventually sends the event=stopped. I'll post a patch to fix as soon as I test it.

Changed 9 years ago by cfpp2p

comment:11 Changed 9 years ago by cfpp2p

Here is a patch to fix. Tested with web client and transmission-remote; with and without full/partial pre-existing data; local torrent file, torrent from URL and magnet link.

Before and After-fixed log below exampling one of the tests.

transmission-remote -n <user>:<pass> -a http://<example.com>/<example>.torrent

BEFORE fix---

GET /announce?info_hash=c%cem%d5%cfLX%84-%01%f7Z%c1f%b9%f9yQ%29%e2&peer_id=-TR271Z-3ki17kq61hl4&port=51413&uploaded=0&downloaded=0&left=33726096&numwant=0&key=14bbc3bf&compact=1&supportcrypto=1&event=stopped HTTP/1.1 User-Agent: Transmission/2.71 Host: 192.168.1.2:7777 Accept: */* Accept-Encoding: gzip;q=1.0, deflate, identity

GET /announce?info_hash=c%cem%d5%cfLX%84-%01%f7Z%c1f%b9%f9yQ%29%e2&peer_id=-TR271Z-3ki17kq61hl4&port=51413&uploaded=0&downloaded=0&left=33726096&numwant=80&key=14bbc3bf&compact=1&supportcrypto=1&event=started HTTP/1.1 User-Agent: Transmission/2.71 Host: 192.168.1.2:7777 Accept: */* Accept-Encoding: gzip;q=1.0, deflate, identity

GET /scrape?info_hash=c%cem%d5%cfLX%84-%01%f7Z%c1f%b9%f9yQ%29%e2 HTTP/1.1 User-Agent: Transmission/2.71 Host: 192.168.1.2:7777 Accept: */* Accept-Encoding: gzip;q=1.0, deflate, identity

AFTER fix---

GET /announce?info_hash=c%cem%d5%cfLX%84-%01%f7Z%c1f%b9%f9yQ%29%e2&peer_id=-TR271Z-7uwlu60x0kne&port=51413&uploaded=0&downloaded=0&left=33726096&numwant=80&key=2b487bc2&compact=1&supportcrypto=1&event=started HTTP/1.1 User-Agent: Transmission/2.71 Host: 192.168.1.2:7777 Accept: */* Accept-Encoding: gzip;q=1.0, deflate, identity

GET /scrape?info_hash=c%cem%d5%cfLX%84-%01%f7Z%c1f%b9%f9yQ%29%e2 HTTP/1.1 User-Agent: Transmission/2.71 Host: 192.168.1.2:7777 Accept: */* Accept-Encoding: gzip;q=1.0, deflate, identity

comment:12 Changed 9 years ago by jordan

I think this tracks down the right problem (adding torrent --> verify --> tr_torrentStop() --> announcer stop) but I'm not sure about that patch.

It seems to me that the problem is this block in verifyTorrent():

    /* if the torrent's running, stop it & set the restart-after-verify flag */
    if( tor->startAfterVerify || tor->isRunning ) {
        /* don't clobber isStopping */
        const bool startAfter = tor->isStopping ? false : true;
        tr_torrentStop( tor );
        tor->startAfterVerify = startAfter;
    }

This block is doing two useful things: (1) it calls tr_torrentStop() if we're running, and (2) sets startAfterVerify to false if the torrent's already stopping. The bug is that it also calls tr_torrentStop() even if the torrent isn't running...

IMO (1) and (2) are only coincidentally joined here, so we can clean this up and fix the bug by separating them into different blocks.

What do you think of tr-4638-rev-02.diff?

Changed 9 years ago by jordan

comment:13 Changed 9 years ago by cfpp2p

What do you think of tr-4638-rev-02.diff?

I'm not sure I like the case where tor->isRunning is true and tor->isStopping is also true. Might it be that in this case that bandwidthPulse() hasn't applied tr_torrentStop() yet and verifyTorrent() will go straight on through without the torrent actually stopped yet, nullifying the purpose of tr_torrentStop() within this context.

comment:14 Changed 9 years ago by jordan

Oh, that's a good catch. Let's always stop if the torrent is currently running.

Changed 9 years ago by jordan

comment:15 Changed 9 years ago by jordan

cfpp2p, what do you think of rev 3?

comment:16 Changed 9 years ago by cfpp2p

cfpp2p, what do you think of rev 3?

Why not like this since torrentInit() sets tor->isRunning = 0; immediately after doStart = tor->isRunning; This will keep the original format and intents of this code within verifyTorrent(). This should work.

     /* if the torrent's already being verified, stop it */
     tr_verifyRemove( tor );

    /* if the torrent's running, stop it & set the restart-after-verify flag */
    if( tor->startAfterVerify || tor->isRunning ) {
        /* don't clobber isStopping */
        const bool startAfter = tor->isStopping ? false : true;
        if( tor->isRunning ) tr_torrentStop( tor );
        tor->startAfterVerify = startAfter;
    }

comment:17 Changed 9 years ago by jordan

verifyTorrent()'s ability to call tr_torrentStop() even when the torrent isn't running seems like a bug to me. I don't see why we'd want to preserve that?

comment:18 Changed 9 years ago by cfpp2p

verifyTorrent()'s ability to call tr_torrentStop() even when the torrent isn't running

no, I've got if( tor->isRunning ) tr_torrentStop( tor );

in 4638#comment:16

which is what you had put in your rev diffs

comment:19 Changed 9 years ago by jordan

  • Resolution set to fixed
  • Status changed from assigned to closed
  • Summary changed from Bad announce EVENT parameter to Transmission sends an initial 'stopped' event when adding a torrent via RPC

Point taken. I don't see a path where startAfterVerify can be unset by tr_torrentStop(), but it probably is safer to keep the original code's behavior of keeping a temporary to hold startAfter until after tr_torrentStop()'s been called.

Fixed r13573

comment:20 Changed 9 years ago by cfpp2p

  • Resolution fixed deleted
  • Status changed from closed to reopened

This did not fix the real problem. See #5092

comment:21 Changed 9 years ago by jordan

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

The behavior reported in this ticket is fixed though... otherwise, why open a duplicate ticket.

comment:22 Changed 9 years ago by x190

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:23 Changed 9 years ago by x190

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

comment:24 Changed 9 years ago by x190

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.