Stopped torrents scraping(?)

[someloser]

Hi,

I've noticed that my stopped torrents often have numbers for unconnected peers and seeds (these are torrents that haven't been running since the last restart). They seem to be only for certain trackers, and it seems to happen when I've had another torrent (a started one) on the same tracker. These trackers list as "scrape ok" on the stopped torrents.

Why does this happen? Is utorrent sending a scrape request for the stopped torrents as well as the current ones?

[DreadWingKnight]

do you have the bt.scrape_stopped advanced setting set to true?

[someloser]

No. These torrents shouldn't be scraping of their own accord, as far as I can tell..

[somel0ser]

Nobody? Basically I'd like to know if utorrent is sending the hash to the tracker, or if it's using a passive method to find out the amount of seeds/peers (i.e. tracker would have to be sending all of its current torrent info? not too sure how viable this would be).

[Switeck]

If bt.scrape_stopped is false...I think uTorrent scraps torrents from the same tracker as any of your active torrents.

[DreadWingKnight]

It does assuming the tracker supports multiscrape.

[somel0ser]

Thanks guys. I turned off bt.multiscrape and it seems to have fixed my problem. As I side note, I don't think it should have been happening in the first place. If you don't want to scrape stopped torrents they shouldn't be scraped, multiscrape or no (obviously I'd prefer to have multiscrape on).

Anyway, thanks again for your help.

[DreadWingKnight]

You're wasting a lot of bandwidth disabling multiscrape just for this issue.

[somel0ser]

Actually, I'm not so sure about that. I have hundreds of stopped torrents ( I've never removed them and I have a reason for this ) and only 3-5 running ones.

[DreadWingKnight]

Full HTTP headers + bencoding per torrent. Unless you have enough stopped torrents to counteract the reduced header AND bencoding size reduction, then you are saving bandwidth by multiscraping.

It does take quite a bit to counteract the bandwidth reduction from the request headers and reduced bencoding.

[somel0ser]

There's about 500 of them, however the subset that share trackers would be much smaller. Either way though, individually scraping <5 torrents isn't going to hog much bandwidth, even if viewed from the tracker's POV.

[DreadWingKnight]

The headers and BEncoding on the scrape requests and response do actually add up to quite a bit, and that's not including the additional resources typically required for connection build and teardown.