rtorrent ignores announce interval

[paxter]

If optional "min interval" is send by the announce, rtorrent uses this value instead of the normal "interval" value. For example, if rtorrent gets from announce interval=2000 and min interval=300, rtorrent always use 300 seconds but this is wrong. This can result into an unwanted announce hammering.

[pyroscope]

BTW, if "min interval" is not sent, rTorrent falls back to its default of 600 secs.

[rakshasa]

Does it 'always' use the min interval of 300, or just when the torrent has few peers?

As soon as the number of peers is above the min peers setting for the torrent it should return to normal announce intervals.

The intention of the min interval in BT is basically to tell the client the lower bound of the interval so it doesn't request too often when in need of more peers.

[paxter]

I haven's tested it, but you should remember, that some private trackers doesn't send information about the peers to the client while seeding. That results (in this case) into announce hammering.

[rakshasa]

Then have a lower seeding min peers.

Throttling the requests on specific edge-cases is not a priority issue atm.

[paxter]

Nevertheless, it doesn't make sense to ignore the interval limit while seeding, because you don't need completed peers for this. Other clients haven't any problems with that, only rTorrent.

[scoobynz]

Im having this problem on a couple of the sites I use. It ignores the interval set by the tracker (on completed + seeding torrents only) and defaults to 600s. Ive noticed that while a torrent is downloading or uploading the announce interval from the tracker is interpreted correctly.

Can you please be more specific on how to fix this issue. Ive lowered min peers etc to 1, without effect.

[pyroscope]

The fix is to have those trackers send "min interval" in their announce responses.

[scoobynz]

Hi. Thanks for the response. A bit more information and observations.

1. This is rtorrent 0.9.6/0.13.6.
2. The announce behaviour / timing doesnt default to 600 secs in deluge, i.e. the tracker is sending intervals that are not 600 secs, rather somewhere around 40mins.
3. I ran some logging and can see the output but cannot interpret it. I have attached a picture (passkeys and IP's blanked out) of it as it has characters that I cannot copy and paste. I think what this shows is that the tracker is sending an interval and a min interval but its selecting the min interval? It says that peers are being updated? Im not sure what all the strange characters are and if this constitutes a problem or is normal behaviour?

If the 600secs is not a problem and the announce is updating correctly, the question still remains . . . why is rutorrent not updating?

This appears to be the exact same issue as this https://github.com/rakshasa/rtorrent/issues/72 but this is rtorrent 0.9.6/0.13.6

Any comment appreciated.

[pyroscope]

The min interval IS 600, and so it is used.

[scoobynz]

Thanks for your response.

OK. So this is a good thing, if there is a min interval rtorrent selects this to the benefit of rtorrent users Understood.

However, I have done further testing and can see that rtorrent doesnt update the tracker information. For example, in the below which I have let run for many tracker announces the number of seeds shown on the website increases whilst the number of seeds in rtorrent doesnt increase. This shows that rtorrent is announcing but not receiving and interpreting the announce correctly. This is different issue to the title of this thread, shall I start a new issue?

As per the screenshot above, does there appear to be anything wrong with the announce? What's up with the strange characters? Is this normal?

[pyroscope]

This has nothing to do with announcing, but with scraping, and also seems more like a ruTorrent issue.

[chros73]

@pyroscope: "This has nothing to do with announcing, but with scraping..." Well, I'm not sure: utorrent refreshes correctly these info (using same tracker), but not rtorrent. So it can happen that it affects the announce interval as well.

@scoobynz: you can open a new issue and link to this one.

[scoobynz]

Thanks for the comments. I agree. This doesnt seem like a rutorrent issue, rather a rtorrent issue. As I demonstrated above rtorrent matches rutorrent, its rtorrent that isnt updating the tracker information. Will start a new thread.

[Speeddymon]

If needed, I can open a new issue, as I'm not sure if this is the same bug, but I can confirm that the announce interval is ignored with the following config enabled:

view.sort_current = started,less=d.get_name=
view.sort_new = started,less=d.get_name=
view.sort = started
schedule = sort_started,0,10,view.sort=started

With the above config, the started view is sorted in descending order and re-sorted every 10 seconds. Every time the schedule runs (every 10 seconds) every torrent is announced.
If I change the schedule to a 60 second interval, the announces happen every 60 seconds.

In order to work around this, I've changed the sort to a 300 second interval for now.
This is on rTorrent 0.9.6/0.13.6 running on CentOS7 with rTorrent installed from EPEL.

Name        : rtorrent
Arch        : x86_64
Version     : 0.9.6
Release     : 2.el7
Size        : 1.5 M
Repo        : installed
From repo   : epel

Name        : libtorrent
Arch        : x86_64
Version     : 0.13.6
Release     : 1.el7
Size        : 1.2 M
Repo        : installed
From repo   : epel

[scoobynz]

@Speeddymon Have you reviewed this issue;
https://github.com/rakshasa/rtorrent/issues/413

[Speeddymon]

@scoobynz I'm a user, not a developer.

#413 seems unrelated in that while it also comes from the announce, this issue here is for rtorrent sending announces to the tracker far too often, whereas yours is something to do with rtorrent populating a display in the client based on information it receives back from the tracker via the announce.

[pyroscope]

@Speeddymon how did you figure out that announces arer sent on sorting? via the tracker logging facility? or else…?

[Speeddymon]

@pyroscope Trial and error. I had been tweaking with the config for the past couple of days.

I noticed after adding sorting for a couple of views that I had a warning about hammering one of the trackers I use. Since I sort every 10 seconds, I started watching the main view and sure enough every torrent was announcing every 10 seconds.

Once I commented out the newly added sort entries, the issue disappeared. So I added them back one by one. The only one that causes it for me is sorting of the "started" view. Other views I sort (main and active) don't trigger this issue.

[chros73]

I can confirm the issue, quickly tried out with rtorrent-ps setup using:

# UI/VIEW: SORT the STARTED view (in view #3) by LAST ACTIVE desc
# Items are grouped into incomplete, complete in that order.
# Each group is devided again into subgroups by throttle name (e.g. slowup).
# Within each subgroup, they're sorted by last_active field desc.
branch=pyro.extended=,"view.sort_current = started,\"compare=++-,d.complete=,d.throttle_name=,d.last_active=\"","view.sort_current = started,greater=d.last_active="
schedule = sort_started,12,10,"view.sort=started"

If that schedule command is added rtorrent goes insane, you can clearly see the effect in the right part of status bar: [H 45/99].

Maybe this bug is related somehow? #362 (comment)

[Speeddymon]

Should I open a new issue just in case this one is unrelated to the OP?
Edit: I don't have the means or time to compile the code, but I think the d.state.set,1 in the line below is contributing to the problem, though I don't suspect it's the actual cause. More of a symptom of the issue.

rtorrent/src/main.cc

Line 310 in efc9097

"view.event_added = started,{(view.set_not_visible,stopped),(d.state.set,1),(scheduler.simple.added)}\n"

The reason I suspect this is that when the view.sort triggers, I noticed that the State changed: line in the torrent info screen resets back to 0:00:00 every time.

[pyroscope]

Right now, sorting likely empties the view, and then re-adds the items in the new order. Due to events, this leads to the state toggle from 1 to 0 to 1 again. That should be addressed in its own issue, since it is not really related to announce interval handling.