Connection closed and other problems with last peer

[DarkVoyage]

Nicotine+ version: 3.3.3rc2 and earlier
Operating System/Distribution: Windows 11

I just want to record an issue for discussion. Can't provide better details now.
Problem looks like this - after some update I found that certain peer can cancel connection (or it fails) with status "connection closed" and it happens for all files one after another. And it is impossible to start the connection again, usually it restarts itself after some delay, peer (or download entry) simply ignores start/pause command. But at same time this peer was the last in the list of downloads. Two times I got this status from two different peers. Sometimes the status is different for last peer, like "connection timeout" or "queued", but it also ignores commands. Looks to me like two different problems. So it would be right to start with what status "connection closed" means in first place. Original slsk lacks any such detailed statuses and simply shows only eternal queue, if it can't connect. And I also see "connection timeout" sometimes, which is more often and mostly means difficulties with connection right now.

[mathiascode]

Debug logging would be helpful here. Please enable Connections + Messages + Transfers debug logging while this issue happens: https://nicotine-plus.org/doc/DEVELOPING.html#debug-logging

peer (or download entry) simply ignores start/pause command.

What do you mean by this? Does the download status change, but nothing happens after that? Or is nothing happening at all?

So it would be right to start with what status "connection closed" means in first place.

• Connection closed: an established connection was abruptly closed
• Connection timeout: failed to establish a connection (e.g. if both ports are closed), or an established connection was inactive for 60 seconds

[DarkVoyage]

Does the download status change, but nothing happens after that?

When you normally click Resume/Pause in menu (I use keys R/T), you see that there's a change in status. When you click Resume on active queue, it works like retry and you also see change. When I tried these actions on "connection closed" files, nothing happens, no status change. You can only remove them or leave. But as I said, this might be a different problem, because this ignorance happens only to peer that is currently the last in download list. Status may differ, it can be normally queued too, but Resume/Pause do nothing.

Any connection problem mentioned is on my side mostly because of VPN/NAT limitations. But different peers behave differently. Some connect fine and fast, some become very unstable and connection fails every minute and there are lots of timeouts, but timeout restart fast and may show timeout 100 times more, but suddenly connect and download. And some simply stop and gradually change to connection closed and stay in that status for some time.

The change in something since newer version (or I don't know what) that I've never seen "connection closed" before, for example, last year. But I see it now on a peer that earlier showed "connection timeout" a lot. Timeouts are more often and happen all the time on 50% of peers. Only 2 peers of all I worked with closed connection. Too bad they are rare visitors and as always - very important to be available for download (exclusive content providers).

Curious, can the "last peer in list" problem be connected to #2926.

[DarkVoyage]

By the way, sometimes clicking Resume on peers is the only way to keep them giving the files, as other user said - they stuck in queue status. You click Resume and download starts right away, even is some files show queue of 100-200, it resets to 0. Generally, this is not like it works in classic client. When you click retry, you see no visible change at all, works only for errored downloads. You can use pause/unpause to reset queue, but it never skips only by resume and retry like in N+.