Opened 4 years ago

Last modified 4 years ago

#6127 new Bug

announcer slots are not properly accounted for

Reported by: reardon Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.92
Severity: Normal Keywords:


Seems to be an old bug in multiscrape() [announcer.c]

The slotsAvailable accounting is wrong; slots are incremented but not decremented properly. It should be:

    /* send the requests we just built */
    for (i=0; i<request_count; ++i)
        scrape_request_delegate (announcer, &requests[i], on_scrape_done, announcer->session);

Change History (2)

comment:1 Changed 4 years ago by cfpp2p

Over time then slotsAvailable might become so large that in theory we would always scrape (or announce) everything. But we have

static time_t
get_next_scrape_time (const tr_session * session, const tr_tier * tier, int interval)
    time_t ret;
    const time_t now = tr_time ();

    /* Maybe don't scrape paused torrents */
    if (!tier->isRunning && !session->scrapePausedTorrents)
        ret = 0;

    /* Add the interval, and then increment to the nearest 10th second.
     * The latter step is to increase the odds of several torrents coming
     * due at the same time to improve multiscrape. */
    else {
        ret = now + interval;
        while (ret % 10)

    return ret;

which directly affects tierNeedsToScrape () Scrapes then should still spread out into batches. r12334 r12297

An example of problems although might be appearing here ticket:5300#comment:4

In theory exceeding 48 (MAX_CONCURRENT_TASKS) is possible.

Scrape and announce batch timings can become complicatedly randomized over time.

comment:2 Changed 4 years ago by cfpp2p

@reardon thanks for this too. With some care I was able to patch also so that I have a setting and can change slotsAvailable at session initialization, if the need for that ever occurs.

Note: See TracTickets for help on using tickets.