libtorrent 1.1.{7,8,9} + Deluge 1.3.15, connecting only to small fraction of peers over dozens and only on certain trackers

[quarreldazzle]

Please provide the following information

libtorrent version (or branch):

• 1.1.7
• 1.1.8
• 1.1.9

platform/architecture: Debian GNU/Linux 9, x86_64

compiler and compiler version:

gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516

please describe what symptom you see, what you would expect to see instead and
how to reproduce it.

This issue was originally posted on Reddit r/seedboxes. I am summarizing it here.

Deluge with the 1.1 branch of libtorrent (confirmed on .7, .8, and .9).
Snatching torrents with autodl irssi on IPT and TL trackers.

After seeing the first Announce OK message (not related to the unregistered torrent issue in #315; workaround on that works fine), Deluge connects to only a small fraction of peers. Usually 2 to 5 over confirmed swarms of dozens (also 60+). Often, the uploader does not seem to be included in the swarm, or the uploader is not shown on Deluge because of the bug itself. Download and upload start and performance is (of course) terrible.

There are no other trackers that seem affected by the issue.

Pausing and resuming a torrent mid-race "fixes" the issue. From 2-5 peers, Deluge starts seeing the entire swarm. Most of which are finished already. Download goes to the max, upload is almost none as most of them are at 100% already.

A catch: the issue happens most of the times, but not all the times.

Downgrading to libtorrent 1.0.11.0 fixes the issue completely.

Somebody on Reddit suggested disabling UTP, but it does not solve the issue.

[arvidn]

is it possible that the main reason pausing and resuming solves the problem is because of re-announcing with the tracker?

could you try just re-announcing to the tracker instead of a full pause?

Do you have access to the connect_candidates counter for the torrent? I would expect it to either be 0 or libtorrent to attempt more connections.

[arvidn]

is it possible that the main reason pausing and resuming solves the problem is because of re-announcing with the tracker?

could you try just re-announcing to the tracker instead of a full pause?

Do you have access to the connect_candidates counter for the torrent? I would expect it to either be 0 or libtorrent to attempt more connections.

[quarreldazzle]

is it possible that the main reason pausing and resuming solves the problem is because of re-announcing with the tracker?

Pause/resume fixes the issue, update tracker does not. Unless you want me to try something else?

Do you have access to the connect_candidates counter for the torrent?

How do I access the counter? I have root access and deluge-console is installed, if it helps.

Happy to try anything you want! It is also weird that the issue is not here with 1.0.11.0.

[quarreldazzle]

is it possible that the main reason pausing and resuming solves the problem is because of re-announcing with the tracker?

Pause/resume fixes the issue, update tracker does not. Unless you want me to try something else?

Do you have access to the connect_candidates counter for the torrent?

How do I access the counter? I have root access and deluge-console is installed, if it helps.

Happy to try anything you want! It is also weird that the issue is not here with 1.0.11.0.

[arvidn]

I don't know how Deluge prints torrent states. it's part of the torrent_status type, as connection_candidates. It's the number of peers in the peer list that are eligible to be connected to.

What about the max peer connection limit? is it set low?
libtorrent won't ever exceed the connection count, which means the margin between the connection count limit, and the number of peers you're already connected will limit the rate at which you can try new peers.

[arvidn]

I don't know how Deluge prints torrent states. it's part of the torrent_status type, as connection_candidates. It's the number of peers in the peer list that are eligible to be connected to.

What about the max peer connection limit? is it set low?
libtorrent won't ever exceed the connection count, which means the margin between the connection count limit, and the number of peers you're already connected will limit the rate at which you can try new peers.

[arvidn]

try to bump the connection_speed setting. I believe the default value was lowered for libtorrent 1.1.

If you set it to 50 or maybe even 100, I would expect peers to be connected to more quickly. One problem some people have is that too high connect speed causes (low quality) routers to crash.

In Deluge you may need the ltconfig plugin to access this setting.

[arvidn]

try to bump the connection_speed setting. I believe the default value was lowered for libtorrent 1.1.

If you set it to 50 or maybe even 100, I would expect peers to be connected to more quickly. One problem some people have is that too high connect speed causes (low quality) routers to crash.

In Deluge you may need the ltconfig plugin to access this setting.

[arvidn]

could you try this patch to see if it improves things? #3231

[arvidn]

could you try this patch to see if it improves things? #3231

[quarreldazzle]

I could unfortunately not find any connection_candidates anywhere. I also tried the info command for deluge-console, but there is nothing related.

Regarding max peer connection, it is set to -1 in the settings.

connection_speed in ltconfig is set to 500.

I will try the patch ASAP and report back to you.

[quarreldazzle]

I could unfortunately not find any connection_candidates anywhere. I also tried the info command for deluge-console, but there is nothing related.

Regarding max peer connection, it is set to -1 in the settings.

connection_speed in ltconfig is set to 500.

I will try the patch ASAP and report back to you.

[quarreldazzle]

Ok @arvidn, I have tried the patch. No luck.

I confirm the following:

1. Announce OK.
2. 2 over 4 peers connected. Uploader was not among them (or not shown).
   No download or upload activity for the next 5 minutes or so. I then notice one of the two peers is progressing.
3. update tracker a couple times
   Nothing happens
4. pause/resume
5. 18 peers are shown immediately, most have finished downloading. Download starts.

[quarreldazzle]

Ok @arvidn, I have tried the patch. No luck.

I confirm the following:

1. Announce OK.
2. 2 over 4 peers connected. Uploader was not among them (or not shown).
   No download or upload activity for the next 5 minutes or so. I then notice one of the two peers is progressing.
3. update tracker a couple times
   Nothing happens
4. pause/resume
5. 18 peers are shown immediately, most have finished downloading. Download starts.

[quarreldazzle]

The patch seems to make connecting to the initial swarm faster with the other trackers, however. I would not discharge it :-)

[quarreldazzle]

The patch seems to make connecting to the initial swarm faster with the other trackers, however. I would not discharge it :-)

[arvidn]

I updated the patch to also affect peers received from peer-exchange. would you mind testing it again? (I made a force-push, so you may have to reset your branch)

[arvidn]

I updated the patch to also affect peers received from peer-exchange. would you mind testing it again? (I made a force-push, so you may have to reset your branch)

[quarreldazzle]

Done. Still nothing, unfortunately. Only pause/resume seems to work. Is there anything that comes to your mind that could have introduced it in the last few minor releases in 1.1.x? I cannot tell if the bug was there in <1.1.6, but it is not there in 1.0.x/

I really appreciate how you have been reactive to this issue!

[quarreldazzle]

Done. Still nothing, unfortunately. Only pause/resume seems to work. Is there anything that comes to your mind that could have introduced it in the last few minor releases in 1.1.x? I cannot tell if the bug was there in <1.1.6, but it is not there in 1.0.x/

I really appreciate how you have been reactive to this issue!

[arvidn]

it's been several years since 1.0.x, it would be quite a lot of code to go through

[arvidn]

it's been several years since 1.0.x, it would be quite a lot of code to go through

[arvidn]

would it be possible to get a log from when this happens? I would be interested in seeing the tracker announce, and the log about how many peers it receives. PEX messages would also be interesting to look at, as I imagine most peers will arrive via PEX if you're really early onto a swarm.

Ideally a log would also include the pause-resume step to demonstrate the case where it works.

[arvidn]

would it be possible to get a log from when this happens? I would be interested in seeing the tracker announce, and the log about how many peers it receives. PEX messages would also be interesting to look at, as I imagine most peers will arrive via PEX if you're really early onto a swarm.

Ideally a log would also include the pause-resume step to demonstrate the case where it works.

[Seeker2]

Tracker announces and PEX messages may not tell the whole story.
In a public torrent swarm, a LOT of the peers+seeds may be firewalled so until they connect to you (their outgoing connection/an incoming connection from your point-of-view) ...you may never connect to them.

Any problems with qBitTorrent/libtorrent accepting incoming connections will make this worse.

I am seeding a large torrent shared on 2 computers on 2 different internet connections -- 1 using qBT4.1.1 32bit, the other uTorrent.
The uTorrent one connects to 20 peers despite not making outgoing uTP connections, using a large ip blocklist, running in initial seeding (super seeding) mode, and even blocking peers that use certain listening ports.
The qBT one connects to 14 "peers" -- it claims 1 or 2 of those are "seeds" despite not showing any at 100%. It's allowing uTP connections both ways, is port forwarded correctly...but is almost always connected to considerably fewer peers. Most of the peers are incoming connections. I am not using super seeding on qBT. If anything, qBT should be connected to equal or more peers than uTorrent!

[Seeker2]

Tracker announces and PEX messages may not tell the whole story.
In a public torrent swarm, a LOT of the peers+seeds may be firewalled so until they connect to you (their outgoing connection/an incoming connection from your point-of-view) ...you may never connect to them.

Any problems with qBitTorrent/libtorrent accepting incoming connections will make this worse.

I am seeding a large torrent shared on 2 computers on 2 different internet connections -- 1 using qBT4.1.1 32bit, the other uTorrent.
The uTorrent one connects to 20 peers despite not making outgoing uTP connections, using a large ip blocklist, running in initial seeding (super seeding) mode, and even blocking peers that use certain listening ports.
The qBT one connects to 14 "peers" -- it claims 1 or 2 of those are "seeds" despite not showing any at 100%. It's allowing uTP connections both ways, is port forwarded correctly...but is almost always connected to considerably fewer peers. Most of the peers are incoming connections. I am not using super seeding on qBT. If anything, qBT should be connected to equal or more peers than uTorrent!

[quarreldazzle]

@arvidn I will attempt to log as much as possible, but I would rather send it privately. Are you ok with you @libtorrent.org e-mail address?

[quarreldazzle]

@arvidn I will attempt to log as much as possible, but I would rather send it privately. Are you ok with you @libtorrent.org e-mail address?

[arvidn]

yes, that works great

[arvidn]

yes, that works great

[quarreldazzle]

Done and sent. Object of the e-mail is the title of this issue. Let me know!

[quarreldazzle]

Done and sent. Object of the e-mail is the title of this issue. Let me know!

[arvidn]

this log isn't quite as detailed as I was hoping. Perhaps Deluge doesn't support enabling full logging. However, I made one interesting observation. Grepping for the tracker announces (I redacted the actual URLs):

[DEBUG   ] 15:37:33 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-1>) (200) tracker sent a failure message "unregistered torrent" (0) [unregistered torrent]
[DEBUG   ] 15:37:33 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-2>) (200) tracker sent a failure message "unregistered torrent" (0) [unregistered torrent]
[DEBUG   ] 15:37:33 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-3>) (200) tracker sent a failure message "unregistered torrent" (1) [unregistered torrent]
[DEBUG   ] 15:38:06 torrentmanager:1073 Tracker Error Alert:  -  (<tracker-1>) (200) tracker sent a failure message "unregistered torrent" (1) [unregistered torrent]
[DEBUG   ] 15:38:06 torrentmanager:1073 Tracker Error Alert:  -  (<tracker-3>) (200) tracker sent a failure message "unregistered torrent" (2) [unregistered torrent]
[DEBUG   ] 15:38:06 torrentmanager:1073 Tracker Error Alert:  -  (<tracker-2>) (200) tracker sent a failure message "unregistered torrent" (2) [unregistered torrent]
[DEBUG   ] 15:38:11 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-2>) (200) tracker sent a failure message "unregistered torrent" (1) [unregistered torrent]
[DEBUG   ] 15:38:11 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-1>) (200) tracker sent a failure message "unregistered torrent" (1) [unregistered torrent]
[DEBUG   ] 15:38:11 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-3>) (200) tracker sent a failure message "unregistered torrent" (2) [unregistered torrent]
[DEBUG   ] 15:38:18 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-1>) (200) tracker sent a failure message "unregistered torrent" (2) [unregistered torrent]
[DEBUG   ] 15:38:18 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-2>) (200) tracker sent a failure message "unregistered torrent" (2) [unregistered torrent]
[DEBUG   ] 15:38:18 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-3>) (200) tracker sent a failure message "unregistered torrent" (3) [unregistered torrent]

[DEBUG   ] 15:38:34 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-1>) received peers: 0
[DEBUG   ] 15:38:34 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-2>) received peers: 7
[DEBUG   ] 15:38:34 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-3>) received peers: 0

[DEBUG   ] 15:43:14 core:403 Pausing
[DEBUG   ] 15:43:14 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-3>) received peers: 0

[DEBUG   ] 15:43:15 core:439 Resuming
[DEBUG   ] 15:43:15 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-3>) received peers: 90

[DEBUG   ] 15:52:47 torrentmanager:952 on_alert_torrent_finished
[DEBUG   ] 15:52:47 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-3>) received peers: 68

There are 3 trackers, we see that all 3 keep failing with "unregistered torrent" the first few announces (as we expect). Then at 15:38:34, tracker-2 returns 7 peers, the two other ones return 0. Presumably this causes the re-announce script to stop, since we got some peers. However, 7 peers aren't that many. A few minutes later, at 15:43:14, the torrent is stopped. This time we announce to the trackers with event=stopped and (as we would expect) we don't get any peers back.

A second later the torrent is resumed, at 15:43:15. This time we get lots of peers.

At 15:52:47 the torrent finishes and we announce with event=finished and, again, we get a bunch of peers.

From what I gather, this is still fundamentally the same problem as #315 just with the twist that there are multiple trackers, and the one with very few peers happens to become responsive first.

I believe this also explains why it doesn't always happen. If would be the first one to return peers, presumably everything would be fine.

[arvidn]

this log isn't quite as detailed as I was hoping. Perhaps Deluge doesn't support enabling full logging. However, I made one interesting observation. Grepping for the tracker announces (I redacted the actual URLs):

[DEBUG   ] 15:37:33 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-1>) (200) tracker sent a failure message "unregistered torrent" (0) [unregistered torrent]
[DEBUG   ] 15:37:33 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-2>) (200) tracker sent a failure message "unregistered torrent" (0) [unregistered torrent]
[DEBUG   ] 15:37:33 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-3>) (200) tracker sent a failure message "unregistered torrent" (1) [unregistered torrent]
[DEBUG   ] 15:38:06 torrentmanager:1073 Tracker Error Alert:  -  (<tracker-1>) (200) tracker sent a failure message "unregistered torrent" (1) [unregistered torrent]
[DEBUG   ] 15:38:06 torrentmanager:1073 Tracker Error Alert:  -  (<tracker-3>) (200) tracker sent a failure message "unregistered torrent" (2) [unregistered torrent]
[DEBUG   ] 15:38:06 torrentmanager:1073 Tracker Error Alert:  -  (<tracker-2>) (200) tracker sent a failure message "unregistered torrent" (2) [unregistered torrent]
[DEBUG   ] 15:38:11 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-2>) (200) tracker sent a failure message "unregistered torrent" (1) [unregistered torrent]
[DEBUG   ] 15:38:11 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-1>) (200) tracker sent a failure message "unregistered torrent" (1) [unregistered torrent]
[DEBUG   ] 15:38:11 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-3>) (200) tracker sent a failure message "unregistered torrent" (2) [unregistered torrent]
[DEBUG   ] 15:38:18 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-1>) (200) tracker sent a failure message "unregistered torrent" (2) [unregistered torrent]
[DEBUG   ] 15:38:18 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-2>) (200) tracker sent a failure message "unregistered torrent" (2) [unregistered torrent]
[DEBUG   ] 15:38:18 torrentmanager:1073 Tracker Error Alert: TORRENT_FOR_TESTING (<tracker-3>) (200) tracker sent a failure message "unregistered torrent" (3) [unregistered torrent]

[DEBUG   ] 15:38:34 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-1>) received peers: 0
[DEBUG   ] 15:38:34 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-2>) received peers: 7
[DEBUG   ] 15:38:34 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-3>) received peers: 0

[DEBUG   ] 15:43:14 core:403 Pausing
[DEBUG   ] 15:43:14 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-3>) received peers: 0

[DEBUG   ] 15:43:15 core:439 Resuming
[DEBUG   ] 15:43:15 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-3>) received peers: 90

[DEBUG   ] 15:52:47 torrentmanager:952 on_alert_torrent_finished
[DEBUG   ] 15:52:47 torrentmanager:1030 on_alert_tracker_reply: TORRENT_FOR_TESTING (<tracker-3>) received peers: 68

There are 3 trackers, we see that all 3 keep failing with "unregistered torrent" the first few announces (as we expect). Then at 15:38:34, tracker-2 returns 7 peers, the two other ones return 0. Presumably this causes the re-announce script to stop, since we got some peers. However, 7 peers aren't that many. A few minutes later, at 15:43:14, the torrent is stopped. This time we announce to the trackers with event=stopped and (as we would expect) we don't get any peers back.

A second later the torrent is resumed, at 15:43:15. This time we get lots of peers.

At 15:52:47 the torrent finishes and we announce with event=finished and, again, we get a bunch of peers.

From what I gather, this is still fundamentally the same problem as #315 just with the twist that there are multiple trackers, and the one with very few peers happens to become responsive first.

I believe this also explains why it doesn't always happen. If would be the first one to return peers, presumably everything would be fine.

[arvidn]

however, it does not explain why simply re-announcing to the trackers wouldn't help. You didn't do that in this session, right?

[arvidn]

however, it does not explain why simply re-announcing to the trackers wouldn't help. You didn't do that in this session, right?

[quarreldazzle]

You are right, I didn't trigger any re-announce after the first "announce: OK.". I will repeat the test, perhaps with the other tracker I suspect is also having the same issue. That one has only one domain, though.

[quarreldazzle]

You are right, I didn't trigger any re-announce after the first "announce: OK.". I will repeat the test, perhaps with the other tracker I suspect is also having the same issue. That one has only one domain, though.

[quarreldazzle]

As promised, I sent you another Deluge log with the same tracker as before.

This time I made sure I updated the tracker several times before using the pause/resume thing. Please note I am not using any script for the announce issue here. I am doing everything manually to keep things polished.

Once again, there were not enough peers up to the pause/resume, and the uploader was not connected.

• 11:02 Torrent snatched, various update tracker up to announce OK
• 11:03 Announce OK, 0(0) Seeders,  1(2) Peers, no download, no upload
• 11:04 update tracker, nothing happens
• 11:05 update tracker, nothing happens
• 11:06 update tracker, nothing happens
• 11:07 update tracker, nothing happens
• 11:07 pause/resume, 0(1) Seeders,  28(35) Peers, download starts
• 11:09 seeding

With this tracker, it is almost never possible to get connected to the uploader, besides of the issue of not enough peers connected from the start. Both these issues are not present with the 1.0 branch.

[quarreldazzle]

As promised, I sent you another Deluge log with the same tracker as before.

This time I made sure I updated the tracker several times before using the pause/resume thing. Please note I am not using any script for the announce issue here. I am doing everything manually to keep things polished.

Once again, there were not enough peers up to the pause/resume, and the uploader was not connected.

• 11:02 Torrent snatched, various update tracker up to announce OK
• 11:03 Announce OK, 0(0) Seeders,  1(2) Peers, no download, no upload
• 11:04 update tracker, nothing happens
• 11:05 update tracker, nothing happens
• 11:06 update tracker, nothing happens
• 11:07 update tracker, nothing happens
• 11:07 pause/resume, 0(1) Seeders,  28(35) Peers, download starts
• 11:09 seeding

With this tracker, it is almost never possible to get connected to the uploader, besides of the issue of not enough peers connected from the start. Both these issues are not present with the 1.0 branch.

[Seeker2]

Are these 28(35) some/mostly/entirely incoming peers? (meaning -- is qBT acting like it's firewalled?)
Also are they all uTP or regular TCP peer connections?

The reason I ask is after all those tracker updates, the tracker should be giving out your ip:port address to other peers so they can connect to you (well, your qBT ip:port) even if the tracker doesn't give you a peer/seed ip:port list.

But I guess you'd need to wait 15-60 minutes to rule out peers just being slow to respond, since they'd have to do a tracker update after your first or the tracker would not register your ip as on the torrent to hand out to other peers yet.

[Seeker2]

Are these 28(35) some/mostly/entirely incoming peers? (meaning -- is qBT acting like it's firewalled?)
Also are they all uTP or regular TCP peer connections?

The reason I ask is after all those tracker updates, the tracker should be giving out your ip:port address to other peers so they can connect to you (well, your qBT ip:port) even if the tracker doesn't give you a peer/seed ip:port list.

But I guess you'd need to wait 15-60 minutes to rule out peers just being slow to respond, since they'd have to do a tracker update after your first or the tracker would not register your ip as on the torrent to hand out to other peers yet.

[quarreldazzle]

@Seeker2, I am sorry, I do not know how qBT work. This issue I am having is with Deluge. Anyway, 28(35) means that Deluge is connecting to 28 over 35 available peers.

15-60 minutes is usually too late in the racing situations I am describing. Also, this issue is not present in the 1.0 branch of libtorrent. I have recently sent another log to @arvidn where the issue is present despite repeated announce commands I am sending during the race.

[quarreldazzle]

@Seeker2, I am sorry, I do not know how qBT work. This issue I am having is with Deluge. Anyway, 28(35) means that Deluge is connecting to 28 over 35 available peers.

15-60 minutes is usually too late in the racing situations I am describing. Also, this issue is not present in the 1.0 branch of libtorrent. I have recently sent another log to @arvidn where the issue is present despite repeated announce commands I am sending during the race.

[Seeker2]

The issues I brought up should be identical with Deluge, as these are common features of any BitTorrent client.

Private trackers (which block PEX, LSD, and DHT) can make these problems a lot worse.

[Seeker2]

The issues I brought up should be identical with Deluge, as these are common features of any BitTorrent client.

Private trackers (which block PEX, LSD, and DHT) can make these problems a lot worse.

[arvidn]

I will look into what the distinction may be between the first announce and subsequent ones. would it be possible to enable more detailed logging in deluge? I'm not familiar with the details of how Deluge logs, but you may need ltconfig plugin to set the alert_mask to include all kinds of alerts, but you may have to do something else to have deluge actually print all libtorrent alerts to the deluge log as well. @cas-- is there a way to get more logging?

Alternatively, you could capture the tracker traffic in wireshark, but if the tracker is running over HTTPS, that might be tricky as well.

It may be that the tracker penalises early re-announces by not returning any more peers (and event=started is what makes it return peers). There could also be an issue in libtorrent where it accidentally sends num_want=0 or something.

I will experiment locally, but I don't have very high hopes of being able to reproduce this

[arvidn]

I will look into what the distinction may be between the first announce and subsequent ones. would it be possible to enable more detailed logging in deluge? I'm not familiar with the details of how Deluge logs, but you may need ltconfig plugin to set the alert_mask to include all kinds of alerts, but you may have to do something else to have deluge actually print all libtorrent alerts to the deluge log as well. @cas-- is there a way to get more logging?

Alternatively, you could capture the tracker traffic in wireshark, but if the tracker is running over HTTPS, that might be tricky as well.

It may be that the tracker penalises early re-announces by not returning any more peers (and event=started is what makes it return peers). There could also be an issue in libtorrent where it accidentally sends num_want=0 or something.

I will experiment locally, but I don't have very high hopes of being able to reproduce this

[arvidn]

actually, it looks like all the force-reannounce you issue are scheduled, but never executed. This is most likely because the tracker responded with a min-interval that's longer than the time from the first response to you pausing and stopping the torrent.

Is it possible that perhaps libtorrent-1.0 did not correctly honor min-interval?

[arvidn]

actually, it looks like all the force-reannounce you issue are scheduled, but never executed. This is most likely because the tracker responded with a min-interval that's longer than the time from the first response to you pausing and stopping the torrent.

Is it possible that perhaps libtorrent-1.0 did not correctly honor min-interval?

[arvidn]

@quarreldazzle would you mind testing this patch? #3250
it adds an option to ignore min-interval from trackers, and enables it by default (in the python binding, to make it easier to test).

[arvidn]

@quarreldazzle would you mind testing this patch? #3250
it adds an option to ignore min-interval from trackers, and enables it by default (in the python binding, to make it easier to test).

[arvidn]

I feel pretty confident that patch at least solves one problem causing this issue (if not resolving the whole issue). @quarreldazzle when you have a moment, please test it! I would like to have some confirmation before I land it and declare victory.

[arvidn]

I feel pretty confident that patch at least solves one problem causing this issue (if not resolving the whole issue). @quarreldazzle when you have a moment, please test it! I would like to have some confirmation before I land it and declare victory.

[quarreldazzle]

@arvidn I will try it by the end of the week, thanks!

[quarreldazzle]

@arvidn I will try it by the end of the week, thanks!

[X-Coder264]

@arvidn Why would you add on purpose an option to ignore something that the tracker told the client? If the tracker gives a min interval property in the response then that is there for a reason. If that interval is set to e.g. 5 minutes, then clicking like crazy on "force re-announce" in the client a thousand times in a couple of seconds and the client not sending all those requests to the tracker is the expected/proper behavior. Having the option to ignore on purpose the min interval seems like the opposite of an improvement to me. If there was a proper reason for this I'd understand, but it seems to me that the only reason for this is ratio whoring on some private trackers because they get only a fraction of the peers on the first announce (which is actually worth looking into why does that happen if there are obviously a lot more peers there). Not honoring the min interval (instead of looking into that issue) doesn't feel like a proper fix at all, it just seems to conveniently avoid the problem at hand.

[X-Coder264]

@arvidn Why would you add on purpose an option to ignore something that the tracker told the client? If the tracker gives a min interval property in the response then that is there for a reason. If that interval is set to e.g. 5 minutes, then clicking like crazy on "force re-announce" in the client a thousand times in a couple of seconds and the client not sending all those requests to the tracker is the expected/proper behavior. Having the option to ignore on purpose the min interval seems like the opposite of an improvement to me. If there was a proper reason for this I'd understand, but it seems to me that the only reason for this is ratio whoring on some private trackers because they get only a fraction of the peers on the first announce (which is actually worth looking into why does that happen if there are obviously a lot more peers there). Not honoring the min interval (instead of looking into that issue) doesn't feel like a proper fix at all, it just seems to conveniently avoid the problem at hand.

[Seeker2]

Tracker updates only hand out 50-200 (or fewer!) "random" ip addresses.
If private trackers aren't set up properly, they'll be handing out seed ips to seeds.
If there's 500 seeds and 5 peers, the odds of any peer ips even being in the list handed out isn't very good.
This is also much of the reason people use high half-open connection limits because their seeds have to try 100's of seed ips to find 1 peer ip.

[Seeker2]

Tracker updates only hand out 50-200 (or fewer!) "random" ip addresses.
If private trackers aren't set up properly, they'll be handing out seed ips to seeds.
If there's 500 seeds and 5 peers, the odds of any peer ips even being in the list handed out isn't very good.
This is also much of the reason people use high half-open connection limits because their seeds have to try 100's of seed ips to find 1 peer ip.

[arvidn]

@quarreldazzle judging from those logs, it still looks like the announce is being suppressed. I can see the attempt to force-reannounce, but I don't see any actual announce nor response.

I will take a closer look if there's a problem with my patch. Are you running on windows, or would steven's patch to deluge be possible for you? (it would be easier to understand what's going on if I could see all alerts).

[arvidn]

@quarreldazzle judging from those logs, it still looks like the announce is being suppressed. I can see the attempt to force-reannounce, but I don't see any actual announce nor response.

I will take a closer look if there's a problem with my patch. Are you running on windows, or would steven's patch to deluge be possible for you? (it would be easier to understand what's going on if I could see all alerts).

[khnielsen]

@quarreldazzle while the build runs better im seeing a ton of random crashes, are you facing the same thing? Deluge just randomly stops running and I cannot really see why.

[khnielsen]

@quarreldazzle while the build runs better im seeing a ton of random crashes, are you facing the same thing? Deluge just randomly stops running and I cannot really see why.

[arvidn]

@quarreldazzle I updated the patch with a few fixes, please test again! (and sorry about force-pushing, you may need to reset your branch)

[arvidn]

@quarreldazzle I updated the patch with a few fixes, please test again! (and sorry about force-pushing, you may need to reset your branch)

[khnielsen]

@arvidn Im going to follow the directions that quarrel dumped above and test it aswell, I am seeing that it for some reason do not wish to connect to the same amount of peers as 1.0.11 does, not entirely sure why but even forcing an update to the tracker has no effect, even on a tracker that I know are coded to not reject tracker updates, an update is simply not processed, even in situations where on 1.0.11 connects to 100 peers (Tracker sends 100 max), 1.1.9 will never connect to more than half of that.

Edit; This is what im seeing when it is running, shutting down deluge and installing 1.0.11 will instantly connect to all of the peers, close it and start it up again and you will see about the same peers again, with a ton missing even though the tracker sends more back.

Im not sure how to debug this for you, would you need a "debug" log from deluge to look into this?

Worth noting here, is that this only appears to effect linux, on windows with the same "setup" it will connect to all peers, which makes it even more tricky imo.

Edit 2: I noticed that even after letting a torrent run for 30 minutes and then clicking "Force tracker update", then the timer inside deluge never resets back to the normal update interval of 30 minutes, this is on 1.1.9 with the patch - Doing the same on 1.0.11 will reset the timer back to 30 minutes indicating that it actually updates the tracker, letting the time run out it will update the tracker and connect to more peers - So it is as if the updates are simply not happening.

[khnielsen]

@arvidn Im going to follow the directions that quarrel dumped above and test it aswell, I am seeing that it for some reason do not wish to connect to the same amount of peers as 1.0.11 does, not entirely sure why but even forcing an update to the tracker has no effect, even on a tracker that I know are coded to not reject tracker updates, an update is simply not processed, even in situations where on 1.0.11 connects to 100 peers (Tracker sends 100 max), 1.1.9 will never connect to more than half of that.

Edit; This is what im seeing when it is running, shutting down deluge and installing 1.0.11 will instantly connect to all of the peers, close it and start it up again and you will see about the same peers again, with a ton missing even though the tracker sends more back.

Im not sure how to debug this for you, would you need a "debug" log from deluge to look into this?

Worth noting here, is that this only appears to effect linux, on windows with the same "setup" it will connect to all peers, which makes it even more tricky imo.

Edit 2: I noticed that even after letting a torrent run for 30 minutes and then clicking "Force tracker update", then the timer inside deluge never resets back to the normal update interval of 30 minutes, this is on 1.1.9 with the patch - Doing the same on 1.0.11 will reset the timer back to 30 minutes indicating that it actually updates the tracker, letting the time run out it will update the tracker and connect to more peers - So it is as if the updates are simply not happening.

[arvidn]

note that I updated the patch around the time you posted, so you probably tested the previous version. I discovered some issues with my first patch that were fixed

[arvidn]

note that I updated the patch around the time you posted, so you probably tested the previous version. I discovered some issues with my first patch that were fixed

[khnielsen]

Did you update it after your post? I just build it entirely fresh after your latest post, just to be safe imgoing to build it again tonight with a completely fresh one again.

[khnielsen]

Did you update it after your post? I just build it entirely fresh after your latest post, just to be safe imgoing to build it again tonight with a completely fresh one again.

[quarreldazzle]

@arvidn thank you, I will test the updated patch in the next days

[quarreldazzle]

@arvidn thank you, I will test the updated patch in the next days

[khnielsen]

@arvidn Alright, so I ran the build again as per the above instructions, and guess what, im seeing the timer go back to the "normal" interval and also update the "peers" available in the () in deluge, so that part at least appears to have resolved things.
Im still seeing it connect to much less peers though than 1.0.11 -

1.0.11 will instantly connect to all of them, im not sure where to look for this, it might be an entirely different issue.

[khnielsen]

@arvidn Alright, so I ran the build again as per the above instructions, and guess what, im seeing the timer go back to the "normal" interval and also update the "peers" available in the () in deluge, so that part at least appears to have resolved things.
Im still seeing it connect to much less peers though than 1.0.11 -

1.0.11 will instantly connect to all of them, im not sure where to look for this, it might be an entirely different issue.

[quarreldazzle]

@khnielsen when you see less peers than expected (as I am also seeing), can you try a pause/resume to see if you also immediately receive tons of more peers?

[quarreldazzle]

@khnielsen when you see less peers than expected (as I am also seeing), can you try a pause/resume to see if you also immediately receive tons of more peers?

[khnielsen]

@quarreldazzle - Im not seeing any difference on that, judging from what you have stated im actually fairly certain that you are seeing a different issue than me, the patch provided by arvid works perfectly here. What I did discover is that I have half open connection set to -1, when I have that it will not connect properly to all the peers available, if I set it to something fixed like 100 it will connect properly, although quite a bit slower than 1.0.11 but it will eventually get a hold of all peers the tracker send and often more as PEX works its wonders.
The issue you are seeing @quarreldazzle are more likely to be a tracker problem, seeing as you have an "OK" announce but in that announce you are so quick to connect to the tracker that no other peers are actually there, as im loading torrents with a 60 second delay im not seeing that as others have announced - But with the patch I can properly "Force announce" all torrents.
What I am seeing @arvidn is that peers can connect just fine on 1.1.9 - Like upload a torrent and wait for it to get 40-50 peers, I can then start the torrent, I get the announce and it connects to all of them right away, it will then drop them off one by one until about half are connected and then from there starting accepting it again - It might be something im doing here, but I have tried nearly everything I can think of. This does not happen on 1.0.11.

[khnielsen]

@quarreldazzle - Im not seeing any difference on that, judging from what you have stated im actually fairly certain that you are seeing a different issue than me, the patch provided by arvid works perfectly here. What I did discover is that I have half open connection set to -1, when I have that it will not connect properly to all the peers available, if I set it to something fixed like 100 it will connect properly, although quite a bit slower than 1.0.11 but it will eventually get a hold of all peers the tracker send and often more as PEX works its wonders.
The issue you are seeing @quarreldazzle are more likely to be a tracker problem, seeing as you have an "OK" announce but in that announce you are so quick to connect to the tracker that no other peers are actually there, as im loading torrents with a 60 second delay im not seeing that as others have announced - But with the patch I can properly "Force announce" all torrents.
What I am seeing @arvidn is that peers can connect just fine on 1.1.9 - Like upload a torrent and wait for it to get 40-50 peers, I can then start the torrent, I get the announce and it connects to all of them right away, it will then drop them off one by one until about half are connected and then from there starting accepting it again - It might be something im doing here, but I have tried nearly everything I can think of. This does not happen on 1.0.11.

[quarreldazzle]

@arvidn when testing the revised patch in #3250 (is it updated if it shows infos from 1 week ago btw.?), I simply repeat the process I described here. Hope this is ok!

[quarreldazzle]

@arvidn when testing the revised patch in #3250 (is it updated if it shows infos from 1 week ago btw.?), I simply repeat the process I described here. Hope this is ok!

[quarreldazzle]

@arvidn yes, this one is a great improvement! I will send you the log file after sending this comment, but the revised patch in #3250 works when hitting update tracker.

Deluge was not able to retrieve andy seeder initially and also just a few peers, but hitting "update tracker" made me receive more peers first, and seeders then. No need to pause/resume anymore.

Now, for both cases I am sending you, Deluge/libtorrent starts to see seeders at a point but do not connect to them and prefer connecting to peers/leechers. This is still a different behavior from 1.0.X. But perhaps this is a tracker issue at this point.

Maybe @khnielsen can test this one, too?

[quarreldazzle]

@arvidn yes, this one is a great improvement! I will send you the log file after sending this comment, but the revised patch in #3250 works when hitting update tracker.

Deluge was not able to retrieve andy seeder initially and also just a few peers, but hitting "update tracker" made me receive more peers first, and seeders then. No need to pause/resume anymore.

Now, for both cases I am sending you, Deluge/libtorrent starts to see seeders at a point but do not connect to them and prefer connecting to peers/leechers. This is still a different behavior from 1.0.X. But perhaps this is a tracker issue at this point.

Maybe @khnielsen can test this one, too?

[khnielsen]

@quarreldazzle - I am seeing the same thing, but I cannot really debug it as there's no real indication as to where it goes wrong.
For now I have been forced to drop back to another build as deluge keeps crashing when using 1.1.9 even without the patch, not entirely sure why as even the highest logging level has no indication as to why it crashes, I prefer stability over the last 10% performance :)

[khnielsen]

@quarreldazzle - I am seeing the same thing, but I cannot really debug it as there's no real indication as to where it goes wrong.
For now I have been forced to drop back to another build as deluge keeps crashing when using 1.1.9 even without the patch, not entirely sure why as even the highest logging level has no indication as to why it crashes, I prefer stability over the last 10% performance :)

[quarreldazzle]

@khnielsen weird, both this and the previous patch as well as 1.1.9 before I submitted this issue report were stable to me. Sorry to hear!

[quarreldazzle]

@khnielsen weird, both this and the previous patch as well as 1.1.9 before I submitted this issue report were stable to me. Sorry to hear!

[khnielsen]

It is indeed odd, I found some indications of crashes with deluge on the qbittorrent part with another bug im looking into for that client.
But I cannot reproduce it, I can leave it running and come back 4 hours later, 50% of the time it has crashed without logging anything which is no good for me.

[khnielsen]

It is indeed odd, I found some indications of crashes with deluge on the qbittorrent part with another bug im looking into for that client.
But I cannot reproduce it, I can leave it running and come back 4 hours later, 50% of the time it has crashed without logging anything which is no good for me.

[Rootax]

Hello,

I'm sorry I don't want to hijack this thread, but I don't get the full impact of the related commit Option to ignore min interval #3250.

So, ok, with this, If I force a re announce, it will do it, even if the tracker sent a higher number, right ?

But, what about the situation, on a lot of private tracker, when you download a torrent via rss or auto-dl, but at first it sends a error like "torrent is not registered", or 0 peers 0 seeds. In that cas, utorrent or rtorrent "hammer" the tracker until it's working (like every seconds).

Will this commit allow this behaviour too ? I've read the code, my gut says "no", but I'm not sure.

Right now, qbittorent (based on 1.1.9) will wait around 1 hour to retry... which is a dead sentence on some private tracker.

Thx.

[Rootax]

Hello,

I'm sorry I don't want to hijack this thread, but I don't get the full impact of the related commit Option to ignore min interval #3250.

So, ok, with this, If I force a re announce, it will do it, even if the tracker sent a higher number, right ?

But, what about the situation, on a lot of private tracker, when you download a torrent via rss or auto-dl, but at first it sends a error like "torrent is not registered", or 0 peers 0 seeds. In that cas, utorrent or rtorrent "hammer" the tracker until it's working (like every seconds).

Will this commit allow this behaviour too ? I've read the code, my gut says "no", but I'm not sure.

Right now, qbittorent (based on 1.1.9) will wait around 1 hour to retry... which is a dead sentence on some private tracker.

Thx.

[arvidn]

So, ok, with this, If I force a re announce, it will do it, even if the tracker sent a higher number, right ?

yes, if "a higher number" means the tracker sent a higher min-interval.

But, what about the situation, on a lot of private tracker, when you download a torrent via rss or auto-dl, but at first it sends a error like "torrent is not registered", or 0 peers 0 seeds. In that cas, utorrent or rtorrent "hammer" the tracker until it's working (like every seconds).

Right, that is my understanding as well. libtorrent does not do that. I've suggested a few times that perhaps it should. The counter-arguments are that it violate the specification and that the problem really should be fixed at the tracker (for instance by doing what I suggested here)

Will this commit allow this behaviour too ? I've read the code, my gut says "no", but I'm not sure.

It does not. It doesn't implement that behavior, but with this flag, it allows a client to implement this behaviour.

Right now, qbittorent (based on 1.1.9) will wait around 1 hour to retry... which is a dead sentence on some private tracker.

I would have expected 30 minutes (as that's typically the default announce interval). In the case of it taking 60 minutes, is that on trackers that have 60 minute announce intervals?

[arvidn]

So, ok, with this, If I force a re announce, it will do it, even if the tracker sent a higher number, right ?

yes, if "a higher number" means the tracker sent a higher min-interval.

But, what about the situation, on a lot of private tracker, when you download a torrent via rss or auto-dl, but at first it sends a error like "torrent is not registered", or 0 peers 0 seeds. In that cas, utorrent or rtorrent "hammer" the tracker until it's working (like every seconds).

Right, that is my understanding as well. libtorrent does not do that. I've suggested a few times that perhaps it should. The counter-arguments are that it violate the specification and that the problem really should be fixed at the tracker (for instance by doing what I suggested here)

Will this commit allow this behaviour too ? I've read the code, my gut says "no", but I'm not sure.

It does not. It doesn't implement that behavior, but with this flag, it allows a client to implement this behaviour.

Right now, qbittorent (based on 1.1.9) will wait around 1 hour to retry... which is a dead sentence on some private tracker.

I would have expected 30 minutes (as that's typically the default announce interval). In the case of it taking 60 minutes, is that on trackers that have 60 minute announce intervals?

[Rootax]

All right, thx for the answer.

Another question about

It doesn't implement that behavior, but with this flag, it allows a client to implement this behaviour.

What value (and where) do I need to change to havec the utorrent / rtorrent behaviour ?

For the hour delay, I've only this problem with 1 tracker, so I guess that's theirs settings.

[Rootax]

All right, thx for the answer.

Another question about

It doesn't implement that behavior, but with this flag, it allows a client to implement this behaviour.

What value (and where) do I need to change to havec the utorrent / rtorrent behaviour ?

For the hour delay, I've only this problem with 1 tracker, so I guess that's theirs settings.

[arvidn]

What value (and where) do I need to change to havec the utorrent / rtorrent behaviour ?

it's not as simple as just changing a setting. there would have to be some logic on tracker failure alerts, recognising that the torrent hasn't been registered yet. Probably via some heuristic of looking for the string "registered" or something along those lines. And then force re-announce (by calling torrent_handle::force_reannounce()).

Also in the case of a successful announce, but where the number of peers returned is < 5 (or something), it should re-announce.

On top of it all, there should be a limit on the number of times either of those cases trigger.

[arvidn]

What value (and where) do I need to change to havec the utorrent / rtorrent behaviour ?

it's not as simple as just changing a setting. there would have to be some logic on tracker failure alerts, recognising that the torrent hasn't been registered yet. Probably via some heuristic of looking for the string "registered" or something along those lines. And then force re-announce (by calling torrent_handle::force_reannounce()).

Also in the case of a successful announce, but where the number of peers returned is < 5 (or something), it should re-announce.

On top of it all, there should be a limit on the number of times either of those cases trigger.

[darthShadow]

I have written a script according to the above comments for Deluge.

Link : https://pastebin.com/Hr9eZJB4

[darthShadow]

I have written a script according to the above comments for Deluge.

Link : https://pastebin.com/Hr9eZJB4

[Rootax]

it's not as simple as just changing a setting...

Thx for the explanation. I thought it could be managed at the libtorrent level, but I get why letting each app deciding this behavior is maybe better. Now, If Qbittorent could look at this too... @sledgehammer999

[Rootax]

it's not as simple as just changing a setting...

Thx for the explanation. I thought it could be managed at the libtorrent level, but I get why letting each app deciding this behavior is maybe better. Now, If Qbittorent could look at this too... @sledgehammer999

[quarreldazzle]

I am using basically the same approach as @darthShadow and it works great with the patch. I have added a couple more update requests after seeing connected peers, too, for getting most of the swarm.

[quarreldazzle]

I am using basically the same approach as @darthShadow and it works great with the patch. I have added a couple more update requests after seeing connected peers, too, for getting most of the swarm.

[arvidn]

I've landed the patch, but note that the flag to ignore min-interval is not set by default now (that was just to simplify testing).

[arvidn]

I've landed the patch, but note that the flag to ignore min-interval is not set by default now (that was just to simplify testing).

[darthShadow]

Little confused here, as per the RC_1_1 branch the flag ignore_min_interval is still set to 1. Should the value be 0 instead?

[darthShadow]

Little confused here, as per the RC_1_1 branch the flag ignore_min_interval is still set to 1. Should the value be 0 instead?

[quarreldazzle]

@arvidn thank you so much for your prompt response to all our inputs! To sum it up (please correct me if I am wrong), the following will land to libtorrent 1.1.9 1.1.10 as a result of this issue report:

• improved torrent_connect_boost setting, now with 80 as default value and 255 as max value, which attempts to maximize the number of firstly connected peers to the number given
• new ignore_min_interval setting, with 0 as default, for ignoring the minimum interval by trackers for force announces. Settings this to 1 requires an implementation on the client side of some logic to handle the case, like the script provided here. Only relevant to Deluge: this requires a manual install of the update-tracker console command [root required].

[quarreldazzle]

@arvidn thank you so much for your prompt response to all our inputs! To sum it up (please correct me if I am wrong), the following will land to libtorrent 1.1.9 1.1.10 as a result of this issue report:

• improved torrent_connect_boost setting, now with 80 as default value and 255 as max value, which attempts to maximize the number of firstly connected peers to the number given
• new ignore_min_interval setting, with 0 as default, for ignoring the minimum interval by trackers for force announces. Settings this to 1 requires an implementation on the client side of some logic to handle the case, like the script provided here. Only relevant to Deluge: this requires a manual install of the update-tracker console command [root required].

[arvidn]

@darthShadow This is what I was referring to. i.e. the call to force_reannounce() won't ignore min-interval, unless you explicitly specify the flag to do so.

[arvidn]

@darthShadow This is what I was referring to. i.e. the call to force_reannounce() won't ignore min-interval, unless you explicitly specify the flag to do so.

[arvidn]

@quarreldazzle sounds right. The update-tracker.py should probably test for which libtorrent version, and if it's > 1.1.9 it can pass in the flag to force_reannounce().

The patch has landed in the RC_1_1 branch in libtorrent, which is the stable branch for the 1.1.x releases. The next release this will make it into will be 1.1.10.

[arvidn]

@quarreldazzle sounds right. The update-tracker.py should probably test for which libtorrent version, and if it's > 1.1.9 it can pass in the flag to force_reannounce().

The patch has landed in the RC_1_1 branch in libtorrent, which is the stable branch for the 1.1.x releases. The next release this will make it into will be 1.1.10.

[quarreldazzle]

I consider the issue closed, but I leave it to you in case you have any pending related tasks. Thanks again!

@arvidn I see the revised patch now.

Do I get it right that ignore_min_interval is now not part of the options that libtorrent enables us to set with ltconfig (for Deluge), but it is now an argument to the function force_reannounce()?

[quarreldazzle]

I consider the issue closed, but I leave it to you in case you have any pending related tasks. Thanks again!

@arvidn I see the revised patch now.

Do I get it right that ignore_min_interval is now not part of the options that libtorrent enables us to set with ltconfig (for Deluge), but it is now an argument to the function force_reannounce()?

[arvidn]

There is no option to disable it client-wide, just the flag to be passed in to force_reannounce()

[arvidn]

There is no option to disable it client-wide, just the flag to be passed in to force_reannounce()