announcer slots are not properly accounted for

[reardon]

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)
    {
        --announcer->slotsAvailable;
        scrape_request_delegate (announcer, &requests[i], on_scrape_done, announcer->session);
    }

[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)
            ++ret;
    }

    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.

[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.