Re: [libtorrent] force_reannounce() doesn't seem to do anything

[Arvid N. <arv...@gm...>]

On Thu, Sep 21, 2017 at 5:25 PM, Murray S. Kucherawy <sup...@gm...>
wrote:

> On Sat, Sep 16, 2017 at 2:05 PM, Arvid Norberg <arv...@gm...>
> wrote:
> >[...]
> > There are a few obvious things that can make libtorrent ignore the call
> to
> > force a tracker announce:
> >
> > 1. If the torrent is paused it will silently ignore it
> > 2. If the tracker index is not -1 but still out of bounds in the tracker
> > list.
> > 3. if the time you specify in the call is invalid and refers to a time
> far
> > into the future
> >
>
> None of these appear to be the case.  We just call
> torrent_handle.force_reannounce() with no arguments, so the tracker index
> is -1 (the default) and the time specified is 0 ("now", the default).
>
> To get a hint about what's going on, I would recommend querying the tracker
> > list periodically to see their status. The announce_entry includes the
> time
> > the next announce is scheduled for. Immediately after a force_announce
> > (with a time stamp of now or in the past) should be set to 1 second from
> > now.
>
> At the time we request a reannounce, I captured the information in the
> tracker list from the torrent handle.  Here's what it had in the first
> entry:
>
> TRACKER: trackerid  message None last_error None next_announce 617283339194
> min_announce 617283339194 scrape_incomplete 0 scrape_complete 1
> scrape_downloaded -1 tier 0 fail_limit 0 fails 0 updating False source 1
> verified True start_sent True complete_sent True send_stats True
>

Did "next_announce" change after the force announce?

You may want to look at all trackers, not just the first one. If they are
in the same tier, some other tracker may be the one used.

Did those time stamps count down? They seem to be set quite far into the
future. Was that true for all trackers?

>
> "trackerid" appears to be an empty string.  I don't know if those are
> legitimate timestamps or not.  They sure don't look like epoch times, but
> internally they are boost::posix_time objects so maybe the internal
> implementation does something interesting with them.  We're pulling these
> through python bindings.  On the other hand if they're supposed to be
> typical epoch times, it's obvious why the reannounces aren't happening
> because those are way bigger than the current epoch time.
>

The timestamps are supposed to be converted to posix time in the bindings.

-- 
Arvid Norberg