Tracker Information Not Updating Peers/Seeds/Last Updated.

[scoobynz]

Hello,

This was initially discussed here;
https://github.com/rakshasa/rtorrent/issues/386

This is with rtorrent 0.9.6/0.13.6 on debian. It only happens with specific trackers, perhaps only those that send a min interval which rtorrent selects?

The announce seems to happen but the tracker information is not synced into rtorrent. I can demonstrate below;
The tracker information from the site;

The tracker information in both rtorrent and rutorrent, note that they are in sync and rutorrent has a long period since last update;

Lastly, here is the information from the log for the announce;

Assistance and comments appreciated. At present it appears that rtorrent isnt updating tracker information for some sites.

[scoobynz]

OK. As an update on this, I downloaded and installed the standalone version of rtorrent-PS, 0.9.4 for debian Wheezy. I installed this by the .deb file on my system. I trialed a torrent file and get the exact same behavior as above.

Trying to zone in on the issue then. Does the installed ,.deb of rtorrent-PS use the version of xmlrpc-c that I compiled when installing the standalone version of 0.9.6 on my system?

[pyroscope]

ldd /opt/rtorrent/bin/rtorrent

[scoobynz]

Of course! drrr. This shows the rtorrent-PS uses its own standalone version of xmlprc, libcurl and libtorrent. Will keep thinking what else it may be then.

[chros73]

I found out how it works: I just restarted rtorrent 2 days ago and I noticed that it updated this info! After that I checked what happens at startup and it fires this request for every torrent (even stopped one) only once (with a 30 sec delay):

rtorrent/src/main.cc

Line 265 in 9abcea8

"method.set_key = event.download.inserted, 1_send_scrape, ((d.tracker.send_scrape,30))\n"

First of all, it "just" a cosmetic issue, it won't affect how rtorrent works at all. Other clients use this info to manage their auto queuing feature (rtorrent behaves differently by default).

Solution:
You can try out the update with this command (after pressing CTRL+X):
d.multicall2=main,d.tracker.send_scrape=0

The easy fix would be adding something like this into our rtorrent config (to fire it up in every 3 hours for all the torrents):
schedule = last_scrape_s, 10830, 10800, "d.multicall2=main,d.tracker.send_scrape=0"

Instead of this I implemented a better solution: chros73/rtorrent-ps-ch_setup@d16ffc5

I've also updated the corresponding wiki page: https://github.com/rakshasa/rtorrent/wiki/User-Guide#the-tracker-list-screen

Enjoy!

[scoobynz]

Thanks chros73! I too had come to the conclusion also that this was a cosmetic issue only, rtorrent was obviously finding new peers and uploading etc even if it wasnt showing this in these columns. I added the line;
schedule = last_scrape_s, 10830, 10800, "d.multicall2=main,d.tracker.send_scrape=0"
into my .rtorrent.rc problem and now I am getting some updates, which is good enough for me at present.

Thanks for getting some resolution and clarification on this. Not sure if this is something that can be fixed in the base code in time or not?

[chros73]

I'm pretty sure it won't happen any time soon (and probably never): multiscraping isn't even implemented in libtorrent (and it's not a 1 hour job to do).
So, currently if you use the one liner above that means rtorrent fires up all the requests at the same time: if you have 2000 torrents that means 2000 requests. :)

So I suggest to use something similar to this (you can just copy paste that block): https://github.com/chros73/rtorrent-ps_setup/blob/master/ubuntu-14.04/home/chros73/.rtorrent.rc#L236
(And you can close this issue.)

[scoobynz]

Thanks. Updated my .rtorrent.rc with the suggested block and all working OK. Thanks for your assistance with this.