SOCKS5 proxy disconnect issue due to insufficient retries

[FranciscoPombal]

EDIT: for users having trouble with this, use the test build linked here: https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-619298534, it should be able to re-establish connection after disconnect errors.

Follow up to https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-615831521 @arvidn for your convenience.

[arvidn]

@condoghost is this a regression? does it work in any earlier version? It sounds like torrents are starting before the SOCKS connection has been established, and the announces fail. Presumably the next announce would work, but that might be a few minutes later, when it's retrying.

Is that consistent with your observation?

[casnewydd]

4.3.0 Alpha1 has not solved the problem for me. Still stuck at 'Retrieving metadata'

[arvidn]

@casnewydd is it a regression?

[casnewydd]

@casnewydd is it a regression?

Sorry, not very tech savvy when it comes to this.

[arvidn]

did it used to work in an earlier version? and are the symptoms you see what's described in the ticket or are they different?

[xavier2k6]

4.3.0 Alpha1 has not solved the problem for me. Still stuck at 'Retrieving metadata'

Did you compile the build yourself or are you using a build from here & if yes - which one?

[casnewydd]

I've just tried using a different client and am having the same problem with that.

[casnewydd]

I manged to get it working by ticking 'Use different port on each startup' in Connection .

Can someone else try it and see if it works for them?

[condoghost]

@condoghost is this a regression? does it work in any earlier version? It sounds like torrents are starting before the SOCKS connection has been established, and the announces fail. Presumably the next announce would work, but that might be a few minutes later, when it's retrying.

Is that consistent with your observation?

@condoghost is this a regression? in what sense? the sense that this version runs okay for days on end then 'suddenly issues with udp trackers but none with the NordVPN SOCKS server having checked countless times that indeed the server is working no issues. @condoghost does it work in any earlier version? Yes it appeared to work fine with 4.1.9.9 It works in this beta version much much better than with 4.2.5, 4.2.4 and 4.2.3 but not consistently and as I mentioned, when it does start churning out Socks5 Errors we simply don't know when it successfully reconnects because we don't have that message in our logs. All I know is that udp trackers stop working, sometimes force reannounce does the trick, other times not, and a clinet shutdown/restart is the only recourse to take. Sometimes no issues with that restart, sometimes preloaded udp torrents start downloading whilst reading Not Working, sometimes force reannounce fixes that other times not. It sounds like torrents are starting before the SOCKS connection has been established, and the announces fail. Presumably the next announce would work, but that might be a few minutes later, when it's retrying? It may well be, however, often the ONLY recourse is to 'Force announce' before we see udp trackers Working. It could well be that udp trackers are Working and the client isn't recording that! It's a 'mystery'. Client is stable for hours/days, the moment shut it down and restart it can go one of two ways. Either 'stable for days and days' or 'unstable having to constantly check to 'Force reannounce'. What I can confirm is that just now I shut the client - not a deliberate action on my part, oops - and restarted. I clearly see in the execution log torrents restored, 8 Socks5 errors 05/06/2020 18:42 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: and then 05/06/2020 18:43 - Detected external IP: in the one udp torrent loaded previously the two trackers Working with no manual force from me - that wasn't the case with the restart yesterday - then 14 more SOCKS5 errors. Anyway, enough from me. Stay healthy and stay safe.

[xavier2k6]

@RabidWolf

@xavier2k6 What's new with this 1?

ref: https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-636340386

It has the fix from the previous build I supplied for Socks5 issues as per https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-619298534

but also all the latest fixes created from both qbittorrent & libtorrent.

EDIT: Oh, it also has a newer version of the Boost library. 1.73 vs previous 1.72

see ref:

qBittorrent commits

libtorrent commits

Feel free to ask me anything else or if you need any further clarity.

[condoghost]

Windows 7 qBittorrent Test Build #12583 (comment) "qBittorrent master commit 480e732 with libtorrent patch 4579" No change - still using Connection Proxy Server SOCKS5 Host NordVPN

qBittorent v4.3.0alpha1 (64-bit) is not stable sufficiently to just 'let it run in the background with our fingers crossed hoping for the best'

Client has been running continuously since 07/06/2020 18:32.

I have one incomplete udp torrent with trackers Working and one complete udp torrent with trackers Working Seeding. I have 17 http torrents with trackers Working Seeding.

There have been 2,212 SOCKS5 proxy errors since 07/06/2020 18:32 and 08/06/2020 08:55: 2,210 are Message: SOCKS5 error. op: sock_read ec: End of file ep:IP address:1080 At 07/06/2020 23:29 there is a SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep:same IP address:1080 At 08/06/2020 04:41 there is a SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: same IP address:1080

08/06/2020 08:55 I load a new udp torrent with trackers Not Working; torrent starts downloading indicating Seeds 0(0) Peers 3(5) There are a further 10 SOCKS5 proxy errors. Message: SOCKS5 error. op: sock_read ec: End of file ep:same IP address:1080 08/06/2020 08:58 I load a second new udp torrent with trackers Not Working; it too starts downloading indicating Seeds 0(0) Peers 6(7)

08/06/2020 09:02 new udp torrents, trackers still Not Working; I 'Force announce' and wait'

08/06/2020 09/07 new udp torrents, trackers are now Working and of course 'still downloading'.

08/06/2020 10:41 there have been no further SOCKS5 proxy errors since loading that second udp torrent at 08:58.

I don't know if the client is truly connected to the NordVPN server during this time period 07/06/2020 18:32 and 08/06/2020 08:55 or the client is 'bypassing' the NordVPN server.

There isn't a message in the client to advise me and only when using the NordVPN App from outside the client can I 'guarantee' the client is auto-disconnected from the network when the NordVPN server is down. However, there are no indications anywhere that the NordVPN server went down and came back up again during this time and when checking with NordVPN they came back advising this specific server has not been down during this time.

ipleak Torrent Address detection reliably informs me EVERYTIME that indeed the NordVPN server is connected to the client, however, ipleak Torrent Address detection tracker is http and as far as I know there aren't issues with http trackers.

I'm not aware of a Torrent Address detection with a udp tracker.

I will look for one but in the meantime I truly fear the client could be 'exposed' at times should udp trackers or http trackers at any time not actually be connected to the SOCKS5 NordVPN server, and activity continues 'blindly' connecting with our true IP-address.

This is a serious concern given this is a very similar issue with using uTorrent where it is CLEAR that using SOCKS5 within that client - for both udp trackers http trackers - is NOT WORKING and probably never has: ipleak Torrent Address detection http reports connection to our true IP-address EVERY TIME when using uTorrent which is why I switched some years back to qBittorrent.

Without a Torrent Address detection udp to verify the situation with qBittorent and udp trackers, there has to be a 'lingering doubt' - no matter how miniscule - with udp trackers.

Perhaps I'm being too 'over cautious' and the 'chance' of http trackers being connected to the SOCKS5 NordVPN server and the udp trackers being connected directly to our true IP-address is simply 'not possible'. But in this day and age we simply cannot take 'not possible' for granted. It has to be 'proven' not to be the case but I guess I can take 'reassurance' this IS not the case given all my http torrents are monitored from the website they were downloaded and that isn't reporting a 'Change of IP address' which it does if I switch NordVPN SOCKS5 servers.

It is indeed too 'complex' for this old brain to fathom the logic that a client can be connected to SOCKS5 server for http torrents showing http trackers Working but not be connected to that same SOCKS5 server for udp torrents showing udp trackers Not Working. Given these same udp torrents with udp trackers Not Working can clearly be seen to be 'downloading' for an age before the client advises us the udp trackers are indeed Working, it drives us to suppose 'It is indeed a 'mystery'' :)

Thank-you for your time and consideration and apologies for 'waffling on'

Please everyone 'Stay Healthy Stay Safe' as many of us continue to be in 100% Total Lockdown for our own safety during these unprecedented times.

[xavier2k6]

@condoghost please try the build from https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-635505117

[condoghost]

@condoghost please try the build from #12583 (comment)

Will do thank-you Give me 48-hours thank-you

[condoghost]

@condoghost please try the build from #12583 (comment)

Will do thank-you Give me 48-hours thank-you

The situation continues with this build also. Hours of 'all okay' then hundreds of SOCKS5 proxy errors. Message: SOCKS5 error. op: sock_read ec: End of file ep: IP address:1080. New udp torrents loaded start downloading even though client is reporting the udp trackers Not Working. Today for example between 09:36 and 14:59 986 SOCKS5 proxy errors. UDP torrents already loaded in client the trackers are showing Not Working. A new UDP torrent loaded to client the trackers are showing Not Working yet the torrent starts downloading and completes the download 9-minutes later and udp trackers are still showing in the client Not Working. Sometimes have to Force announce for newly loaded udp torrent trackers to show Working and the torrent to start downloading. Other times as in the case just mentioned, udp torrent starts downloading and even completes before udp trackers in the client show Working. As I have said before 'It's a 'Mystery''. Thank-you for your perseverance with this. I'll await an update and test that before making comment again. Stay healthy Stay safe.

[arvidn]

yet the torrent starts downloading and completes the download 9-minutes later and udp trackers are still showing in the client Not Working.

Do I understand correctly that everything essentially works as expected except trackers say "Not Working" and you get SOCKS5 errors in the log?

(The SOCKS5 errors are actually expected to happen, and can come in bursts if the provider has an issue where one needs to fail over for instance).

I think the "not working" comes from libtorrent reporting tracker status for each individual listen socket, and qbittorrent expecting just one announce per tracker. I suspect at least that if one listen socket failing to announce (which is expected to happen) "clobbers" the tracker status even though another listen socket succeeds in announcing.

[condoghost]

yet the torrent starts downloading and completes the download 9-minutes later and udp trackers are still showing in the client Not Working.

Do I understand correctly that everything essentially works as expected except trackers say "Not Working" and you get SOCKS5 errors in the log?

Some times 'everything essentially works as expected apart from tracker status', other times not. As I post this comment I loaded a new udp torrent 15/06/2020 20:26. Trackers listed Not Working, Seeds 0(0) Peers 0(0). Force announce trackers still Not Working, udp torrent still not downloading, existing http torrents are Working and Seeding. Ping indicates proxy server is working. ipleak iTorrent address detection ndicates proxy server is working. Client reports a total of 1,592 SOCKS5 proxy errors since client was restarted 15/06/2020 10:29 having switched NordVPN server. Between 15/06/2020 10:34 and 15/06/2020: 1,588 SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: IP address:1080 3 SOCKS5 proxy errors 15/06/2020 10:36, 15/06/2020 10:39 and 15/06/2020 10:43 Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: IP address :1080 1 SOCKS5 proxy error 15/06/2020 18:35 Message: SOCKS5 error. op: handshake ec: The semaphore timeout period has expired ep: IP address:1080 Since loading udp torrent at 15/06/2020 20:26, between 15/06/2020 20:29 and 15/06/2020 20:51 there are a further 97 SOCKS5 proxy errors. Message: SOCKS5 error. op: sock_read ec: End of file ep IP address:1080 either 3 or 4 errors reported each minute. 15/06/2020 20:51 udp torrent starts downloading - 25 minutes after loading; udp trackers Working. 15/06/2020 21:05 SOCKS5 proxy errors Message: SOCKS5 error. op: sock_read ec: End of file ep: reporting again. Between 15/06/2020 21:05 and 15/06/2020 21:35 76 further SOCKS5 proxy errors Message: SOCKS5 error. op: sock_read ec: End of file ep: Client continues to list them 4 a minute.

[condoghost]

And simply to 'confirm' that 'no everything is not essentially working as expected' today I loaded 3 new udp torrents. udp trackers Not Working Seeds 0(0) Peers 0(0) and simply would not start downloading regardles Forced reannounce, Pause or anything else I could think. I Set SOCKS5 Proxy No and closed client. I reopened client and all 3 udp torrents started downloading immediately and udp trackers Working. I Set Socks5 Proxy Yes with Authentication and close client. 10 minutes later I loaded a new udp torrent which of course opens the client. The 3 previously loaded udp torrents immediately show Seeds and Peers and start downloading even though udp trackers are showing Not Working in the client and we have 9 SOCKS5 proxy errors. Message: SOCKS5 error. op: sock_read ec: End of file ep: IP address:1080 and at 16/06/2020 09:07 1 SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: IP address:1080. No further SOCKS5 proxy errors since and 16/06/2020 09:22 the new udp torrent loaded to open the client? the udp trackers are still Not Working, Seeds are still 0(0), Peers are still 0(0) and this udp torrent is still not downloading. I close the client. 5-minutes later I reopen the client. the 3 previous udp torrents and the new udp torrent immediately have Seeds and Peers and start downloading. Each udp torrent has ONE udp tracker Working and ONE udp tracker Not Working. I check the Detected external IP address with IP Find Check and IP Find Location and confirm it is the NordVPN server. The no SOCKS5 proxy errors will likely start logging again once these udp torrents are complete and no longer being seeded as appears to be the case time and again with this situation. I confirm there are no further SOCKS5 proxy errors reported at this time. UPDATE: udp trackers in all 4 udp torrents are now Working. UPDATE and as I 'suspected would happen', 11-minutes after all 4 udp torrents have completed downloading and are 'paused' 'Seeding', the SOCKS5 proxy errors. Message: SOCKS5 error. op: sock_read ec: End of file ep: IP address:1080 start listing in the log again even though there are no udp trackers of any udp torrents looking to connect as previous paused udp torrents the udp trackers are Not Contacted Yet and these 4 paused udp torrents the udp trackers are Not Working. Perhaps all udp trackers for all udp torrents must be Not Contacted Yet for this never ending loop of SOCKS5 proxy errors to stop. OF course Resuming these 4 udp torrents the status is still Not Working and may well likely remain the case until the client is closed and restarted but then 'I'm no expert'. It's all a 'Mystery' and like traffic congestion will likely never know the 'cause' once it all frees up or returns time and again. The most important thing right now? 'Stay healthy Stay safe' as always. Thank-you.

[galacticboy2009]

It's all a 'Mystery' and like traffic congestion will likely never know the 'cause' once it all frees up or returns time and again. The most important thing right now? 'Stay healthy Stay safe' as always. Thank-you.

I downloaded that latest 4.3.0 test build just for fun and it doesn't seem to make any difference at all for me, compared to the official 4.2.5 release. Which supports condoghost's experience.

Starting the client gives about 12 errors after all the torrents load in. Usually a mix of these 3 variants:

6/19/2020 9:11 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: XX.XXX.XX.XXX:1080

6/19/2020 9:08 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: XX.XXX.XX.XXX:1080

6/19/2020 9:07 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: XX.XXX.XX.XXX:1080

Then a glorious blue success message showing the detected IP. A few minutes of decent downloading even though 95% of trackers say "Not working" (Usually 1 or 2 trackers will show Working if it's on a torrent with a 20+ to choose from)

Then some more SOCKS5 errors.

Leaving the client running for days on end does eventually complete torrents, but most of the time opening the client shows 0 bits down / 0 bits up and a mess of SOCKS5 errors. (though occasionallyyy it'll be downloading away with almost problem, despite the errors.. maybe that's related to the specific torrent being downloaded though)

Reannouncing to all trackers doesn't make them work any better as far as I can tell, sadly.

[xavier2k6]

Windows test build of 4.3.0(Alpha1) with listed libraries:

qBittorrent master   | 4.3.0 +git 9dfeeb9
libtorrent-rasterbar | 1.2.7 +git 89419b1
Qt                   | 5.15.0
OpenSSL              | 1.1.1g
zlib                 | 1.2.11
Boost                | 1.73

"Windows Test Build" download link below: qBittorrent master +git 9dfeeb9 with Boost 1.73 + Qt 5.15 + libtorrent 1.2.7 +git 89419b1

[condoghost]

"Windows Test Build" download link below: qBittorrent master +git 9dfeeb9 with Boost 1.73 + Qt 5.15 + libtorrent 1.2.7 +git 89419b1 Thank-you. Downloaded and using now. There's a 2-second delay between loading everything and then Detected external IP: address. During those 2-seconds 5 SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: IP address. udp torrents already loaded start downloading though status of udp trackers Not Working for 3-4-5-6-minutes Loaded three new udp torrents, trackers instantly 'Working' and all started to download. No further OCKS5 proxy errors at this time. I'll leave it running but will have to do something with every other line 'white' 'grey', this combination causes me 'eyesight issues' as I scroll up scroll down the page - horrible. But hey, least of any issue right now as we look to Stay Healthy Stay Safe.

[stromdriver]

came over from uTorrent because it ceased functioning no matter what i did ver 4.2.5, win 10, centurylink gig fiber servce, Nordvpn service using US p2p specific server address, udp trackers have never worked, even with 'force announce' most http trackers (but not all) work, and no udp's work, here's relevant section of the log torrents work randomly, up or down, and node count varies wildly, sometimes in mid-low double digits, sometimes in the few hundreds

`6/28/2020 13:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 184.170.240.102:1080

6/28/2020 13:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:35 - Detected external IP: 184.170.240.103

6/28/2020 13:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:34 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080`

[xavier2k6]

@stromdriver please try the build in this https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-646988383

[stromdriver]

@stromdriver please try the build in this #12583 (comment)

pretty much same results, all udp trackers show as 'not working', mid double digit nodes

6/28/2020 17:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:13 - Detected external IP: 184.170.240.103 6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080 6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

[xavier2k6]

@stromdriver are your network drivers up-to-date?

@arvidn still seems to be an issue with UDP?

[stromdriver]

@stromdriver are your network drivers up-to-date?

@arvidn still seems to be an issue with UDP?

as far as i know? my surface pro just did a couple sizable updates lately and shows as up to date

[arvidn]

Is there any way of telling whether the udp tracker is delivering peers, regardless of whether it says “not working”? I have a feeling qbt attribute A failure for any Endpoint to the whole tracker

[condoghost]

"Windows Test Build" download link below: qBittorrent master +git 9dfeeb9 with Boost 1.73 + Qt 5.15 + libtorrent 1.2.7 +git 89419b1

Now 14-days. SOCKS5 Errors listing again after 3-days. Same issues as before already loaded udp torrents start downloading every time even though status is Not Working; new udp torrents sometimes status will eventually change on some udp trackers but not all after 4-5-minutes and torrent starts downloading, other times need to 'Force announce' and eventually status changes and torrent starts downloading. Sometimes that 'Force announce' updates all trackers Working, other times not. When it becomes 'impossible' with very slow download, no download, reams of SOCKS5 Errors I shut down client, clear all cache, wait 4-5-minutes, then restart. Did this three-four times over last 10-days. All seems okay for 24-48-hours then SOCKS5 Errors return, then 'issues' with new udp torrents trackers Not Working. Same again, sometimes just leaving them for 2-3-4-minutes some trackers start working but not all, sometimes 'Force announce' 'instantly' results all udp trackers working, sometimes 'nothing' until 2-3-minutes later it 'springs to life'. Most times already loaded udp torrents automatically start to download even though status is still Not Working'; that status will eventually change to 'Working' even though no SOCKS5 Errors reporting beforehand. To summarize: 24-48-72-hours no SOCKS5 Errors, no issues. Once SOCKS5 Errors start listing it all becomes 'hit and miss'; sometimes the client 'settles', errors stop listing, and all is okay with status and downloading, othertimes no matter what we do, SOCKS5 Errors keep listing, new udp torrents don't start downloading, udp trackers status remains Not Working, 'Force announce' has no effect whatsoever, and best to shut down client, clear cache of temp files, and restart client. Sometimes that settles the client for another 24-48-72-hours, other times the client returns to an unstable condition straight away, within an hour, two-hours. One possibility is that having just one udp tracker Not Working on just a single udp torrent where other udp trackers are Working, and all other udp trackers in udp torrents are Working, may be causing the client to fall into this never ending 'loop' where it becomes 'fixated 'on that 'one tracker', new udp torrents with their udp trackers remain queued for 'attention' until the client is 'freed' to attend them - similar to what we would see for example if we have too many things going on with our PC such as mkvmerge, mkvextract, copy paste files, deleting files, scanning files, whilst StaxRip is running at at 98% CPU, everything slows to 'nothingness' until it 'magically' works it all out. One 'lives with it' but most times when this starts it won't 'sort itself out' without a manual client restart same as sometimes we may be forced to do with our PC in the scenario outlined. Just my 'thinking' always wanting 'logical reasoning'. Thank-you for your continued efforts. It 'is what it is', a 'magical mystery [tour]' of sorts :) Stay healthy stay safe.

[FranciscoPombal]

@condoghost thanks for the info.

Here is a new build on top of latest master with:

• logging of all tracker announce error alerts
• a little more verbosity on the SOCKS5 alert (not sure if it will help)

<removed inactive link to build, it was a build of 83f1028ff7ef198ea937dde87fb3f288c0139c48 with the following patch on top>:

diff --git a/src/base/bittorrent/session.cpp b/src/base/bittorrent/session.cpp
index af6df18ae..c1a36ce1f 100644
--- a/src/base/bittorrent/session.cpp
+++ b/src/base/bittorrent/session.cpp
@@ -4718,7 +4718,7 @@ void Session::handleStateUpdateAlert(const lt::state_update_alert *p)
 void Session::handleSocks5Alert(const lt::socks5_alert *p) const
 {
     if (p->error) {
-        LogMsg(tr("SOCKS5 proxy error. Message: %1").arg(QString::fromStdString(p->message()))
+        LogMsg(tr("SOCKS5 proxy error. Message: %1 | error.message(): %2").arg(QString::fromStdString(p->message()), QString::fromStdString (p->error.mess      16 age()))
             , Log::WARNING);
     }
 }

diff --git a/src/base/bittorrent/torrenthandleimpl.cpp b/src/base/bittorrent/torrenthandleimpl.cpp
index 062ec56a7..09ddee2da 100644
--- a/src/base/bittorrent/torrenthandleimpl.cpp
+++ b/src/base/bittorrent/torrenthandleimpl.cpp
@@ -1417,6 +1417,9 @@ void TorrentHandleImpl::handleTrackerErrorAlert(const lt::tracker_error_alert *p

     m_trackerInfos[trackerUrl].lastMessage = message;

+    LogMsg(tr("<tracker_error_alert> error: %1 | failure reason: %2")
+        .arg(QString::fromStdString(p->error.message()), p->error_message()), Log::WARNING);
+
     // Starting with libtorrent 1.2.x each tracker has multiple local endpoints from which
     // an announce is attempted. Some endpoints might succeed while others might fail.
     // Emit the signal only if all endpoints have failed.

(any of the 4 builds will do, you can just select the one with latest Qt version and libtorrent RC_1_2 head)

If you can post logs with these alerts, that would be great. Also, please clarify if you're still able to connect and get peers despite the errors shown in the GUI and logs.

[ghost]

No offence but why do people use socks? It doesn’t provide any sort of encryption...at best you’re hiding your IP from other peers. But your ISP can still detect torrent traffic.

[douglasparker]

For when you don't want all services on a specific server behind a VPN.

I believe socks5 proxies have better performance too.

Douglas Parker

On Sat, Jul 11, 2020, 7:53 PM An0n notifications@github.com wrote:

No offence but why do people use socks? It doesn’t provide any sort of encryption...at best you’re hiding your IP from other peers. But your ISP can still detect torrent traffic.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-657166316, or unsubscribe https://github.com/notifications/unsubscribe-auth/AELEDLVMWUSD27DBSCJSAVDR3EQTHANCNFSM4MOTQNUQ .

[condoghost]

No offence but why do people use socks? It doesn’t provide any sort of encryption...at best you’re hiding your IP from other peers. But your ISP can still detect torrent traffic.

Of course the 'best solution' is to use an external VPN App but for 'many reasons', as I outline below, this is not the 'ideal' and definitely impacts your browsing experience where some websites and most payment systems specifically will not 'work' with a VPN. Also with two-step verification now becoming more and more 'common', a 'change of IP address' from that used last time triggers a 'red flag' in this scenario especially with Google accounts for example.

Using SOCKS5 VPN Server? own ISP doesn't detect the specifics of the 'traffic' only that there is 'traffic'; and bear in mind it's all about the traffic 'back to you''

As an example, 'ipleak' IDs Your IP addresses, Your IP addresses WebRTC detection, DNS Address, Torrent Address detection, Geolocation detection. Do this without VPN and a browser set 'Connections Settings' 'Configure Proxies to Access the Internet' 'No proxy' you will see your specific IP-address and your ISP information and all the other 'specifics' with your ISP. More detail can be seen 'checkmyip' and 'iplocation'. Configure browser 'Manual proxy configuration HTTP Proxy' with VPN US server, for example, and 'tick' Use this proxy for all protocols - SSL Proxy, FTP Proxy, SOCKS5 - all URL traffic is now directed through VPN US server. Add specific websites in 'No proxy for', a 'White List' if you like, that 'traffic' is 'direct, ISP can identify that traffic 'specifically', but all traffic through 'Manual proxy' is just 'traffic' for want of writing a 'non-technical explanation'. Run qBittorrent client, whatever client, with no proxy configuration and activate Torrent Address detection ipleak, you see DNS Address is ISP DNS. Set the 'client' with SOCKS5 proxy and 'hopefully' the DNS Address is now VPN server. Unfortunately uTorrent still 'leaked' when I was using that a few years back which is 'why' I now use qBittorrent client. Torrent Address detection will now list torrent address but unfortunately this ipleak check is only for http trackers. I've yet to come across a Torrent Address detection for udp trackers. Using a number of browsers with a different SOCKS5 VPN Server for each, eg browser SOCKS5 US VPN Server and another browser SOCKS5 UK VPN Server, you have the 'freedom' of watching US-specific content on one and UK-specific content on the other. Some content providers are wiser to this these days and look to 'block' VPN traffic. VPN providers are constantly looking to better this and so this continues back and forth. Simple things like YouTube country specific content is not so much an 'issue' as Streaming services content is. Setting a torrent client SOCKS5 VPN specific country server now fits this set-up of using a number of applications across multiple country VPN all from the single PC, laptop, pad, whatever. Of course an external VPN App is 'better' however 'all traffic' is directed through that 'single country specific VPN server' setting regardless of browser settings, regardless browser 'No proxy for' settings, no matter torrent client settings. Same issue with browser VPN Add-on - all browser traffic is directed through that 'single country specific VPN server' setting. Using SOCKS5 is not ideal but it does free you up to connect multiple applications to multiple country VPN servers.

The ideal? VPN App where we get to list applications such as Waterfox browser, Chrome browser, Pale Moon browser, SeaMonkey browser, whatever browser, qBittorrent client, whatever client. Against each we specify the VPN country, server type, security protocol and 'White List' where applicable. Now when we start our PC all is handled automatically in the background, auto-switch to alternate server whenever a server goes down with auto-application 'pause (kill-switch) to prevent any 'traffic leakage'.

We can dream. I keep badgering my VPN service every month or so, I guess I'm 'on a mission'.

Stay healthy, stay safe.

[condoghost]

@condoghost thanks for the info.

Here is a new build on top of latest master with:

* logging of all tracker announce error alerts

* a little more verbosity on the SOCKS5 alert (not sure if it will help)

<EDIT (FranciscoPombal): removed inactive build link> (any of the 4 builds will do, you can just select the one with latest Qt version and libtorrent RC_1_2 head)

If you can post logs with these alerts, that would be great. Also, please clarify if you're still able to connect and get peers despite the errors shown in the GUI and logs.

Okay, I've grabbed this and will start later today, run it this week and get back to you. I'll also clarify if I'm still able to connect and get peersdespite the errors shown in the GUI and logs. I'll get back sooner if I'm 'forced' to shut down the client and restart which has been the only 'answer' at times with 'new' torrents refusing to start. Stay healthy, stay safe.

[arvidn]

The errors in the log are expected to happen every now and then, as the SOCKS connection time out for instance. They aren't expected to spam the log continuously though. But those messages are mostly helpful if nothing works. Then they might indicate what's failing.

[condoghost]

The errors in the log are expected to happen every now and then, as the SOCKS connection time out for instance. They aren't expected to spam the log continuously though. But those messages are mostly helpful if nothing works. Then they might indicate what's failing.

UPDATE Client running since 19 July 2020 16:37. Attachments 2020-07-20-execution-log.xlsx and 2020-07-20-observations-actions.txt sent to the email address in your profile arvidn. Thank-you. Stay healthy, stay safe.

UPDATE It is worth mentioning all torrent trackers are http from 20/07/2020 15:48 onwards having deleted all udp torrents at this time.

[FranciscoPombal]

@condoghost mind uploading the files here, as attachments?

[condoghost]

@condoghost mind uploading the files here, as attachments?

The information is too public uploaded here as 'attachments'. I don't see an email address in your profile?

[FranciscoPombal]

The information is too public uploaded here as 'attachments'. I don't see an email address in your profile?

The point is to make the data more easily accessible to anyone interested. You can easily redact the sensitive information in the logs/settings.

[condoghost]

The information is too public uploaded here as 'attachments'. I don't see an email address in your profile?

The point is to make the data more easily accessible to anyone interested. You can easily redact the sensitive information in the logs/settings.

"The point is to make the data more easily accessible to anyone interested" Really? What is there to say. If you believe it is 'okay' to post data in this way for it to be more easily accessible to anyone interested then go ahead and post your data in this way. You can easily include an email address in your profile to have received this data but there we go - you chose not to provide one. Are you a 'developer'? Are you 'working on fixing this'? Somehow I don't think so.

"You can easily redact the sensitive information in the logs/settings" Really? I'm still pondering a polite answer to your 'suggestion' given my earlier posts it is pretty obvious I already know that and have done so in the past. I have chosen not to remove the 'sensitive information' this time because it is clear that some messages are specific and without the 'sensitive information' it would not be clear what was specific to what.

[xavier2k6]

@condoghost YES @FranciscoPombal is part of the qBittorrent team & YES he "IS" working on fixing this & so is the developer/owner of the libtorrent library @arvidn

There are users like myself & "for clarity" - ("NO, I AM NOT A DEVELOPER") who are also focused on fixing this issue even if we don't experience the issue(s) as outlined in this thread in order to benefit the qBittorrent & even libtorrent user community at large.

"You can't make scrambled eggs without breaking some eggs"...............but first somebody needs to supply those eggs.

Issue can't really be fixed, if not all info is supplied is what I am getting at (all parties involved need to look at the info, fresh pair of eyes/different thought(s)/views etc.)

Some people don't readily supply an email address as bots can pic it up for spam etc.

It is not an unreasonable request to post the redacted info here, but if you decline - that's ok.

Help us, to help you.

[condoghost]

The errors in the log are expected to happen every now and then, as the SOCKS connection time out for instance. They aren't expected to spam the log continuously though. But those messages are mostly helpful if nothing works. Then they might indicate what's failing.

Having run this since 14-days now and not had any 'feedback' as to 'where we are at' after submitting logs and observations July 20 I can but update you on my 'experience' since then. I was under the impression this was primarily a proxy issue with udp trackers but having deleted all udp torrents and running the client since 20/07/2020 15:48 with torrents having only http trackers it highlights to me how unstable the SOCKS5 proxy is. The client remained fairly stable for 3-4-5 days then became 'unstable' and these last three days has become very 'unpredictable' constantly advising http trackers Not Working requiring many attempts to Pause and Resume. Sometimes Pause http trackers immediately switching to Working, other times not and when Resumed immediately switching to Working or sometimes not. 'bad gateway' constantly coming up across a number of http trackers. Today it simply has become 'impossible'. I have switched proxy servers 4-times and have lists of " error: An existing connection was forcibly closed by the remote host | failure reason:" and " error: End of file | failure reason:" with any number of http trackers Not Working. On three restarts the client would not return a Detected external IP message and on two restarts the client returned a Detected external IP of 0.0.0.0! ipleak.net torrent address detection reported the correct IP address on each occasion. On the udp tracker front I had to set the client to 'No proxy', close and restart before any of udp trackers on newly loaded udp torrents were Working and for udp torrents to have Seeds, Peers, Down Speed, Up Speed. I have restarted the client with SOCKS5 proxy server. all 7 udp torrents have Seeds, Peers, Down Speed, Up Speed and all udp trackers are Working. What is 'interesting' is now when the torrent is 'complete' and 'Seeding' and I Pause? udp trackers 'Working' 'update' and then 'Not Working'. This was not happening for many days before today. But then, what can I say, I now see that this does not happen every time, sometimes, sometimes 'not'. I don't see any point in trackers 'working' when the torrent is 'paused' but there we go. Each of the 15 http torents have the same 3 http trackers. 8 http torrents have all 3 same http trackers working, 3 have one same http tracker Not Working, and 3 have two same http trackers Not Working.

Is there a new build I can grab to continue? Thank-you. Stay healthy, stay safe.

[xavier2k6]

Is there a new build I can grab to continue?

Not until we have more info/possible patch from @arvidn to go on. (If needed)

[condoghost]

@condoghost YES @FranciscoPombal is part of the qBittorrent team & YES he "IS" working on fixing this & so is the developer/owner of the libtorrent library @arvidn

There are users like myself & "for clarity" - ("NO, I AM NOT A DEVELOPER") who are also focused on fixing this issue even if we don't experience the issue(s) as outlined in this thread in order to benefit the qBittorrent & even libtorrent user community at large.

"You can't make scrambled eggs without breaking some eggs"...............but first somebody needs to supply those eggs.

Issue can't really be fixed, if not all info is supplied is what I am getting at (all parties involved need to look at the info, fresh pair of eyes/different thought(s)/views etc.)

Some people don't readily supply an email address as bots can pic it up for spam etc.

It is not an unreasonable request to post the redacted info here, but if you decline - that's ok.

Help us, to help you.

xavier2k6 you make an very interesting point. First you go on about 'Issue can't really be fixed, if not all info is supplied' and then you mention 'Some people don't readily supply an email address as bots can pic it up for spam etc'. Well, what can I say ... 1) all info has been supplied. It is not for me, a 'user', to work out how this is distributed among 'interested' parties; 2) if @arvidn can provide an email address in 'profile' then so can everyone else who has an interest; 3) your case of an email address being picked-up by bots doesn't wash with me. I use a specific email address for all forums, I don't store others email addresses, I don't save emails sent. This ensures the 'risk' of 'spam' is restricted only to my specific email address which - seriously - is never an issue when one never opens emails that aren't clearly 'specific' and 'known'; 4) 'Eggs' have been supplied, 'live with it'; 5) I'm not saying it's not a reasonable request to post redacted info here, I'm saying some important 'unredacted info' is pretty 'worthless' when presented in 'redacted' form and if you really think it is so 'straight forward' then I suggest you be seen to be doing so yourself before asking others to do. My current log is already 600 lines and client has been running for less than two-hours. Simplicity is in the eye of the beholder; 6) I've not requested your 'opinion' My post was directed to @FranciscoPomba; and 7) 'Help us, to help you.'? I take exception to that given I appear to be only one of perhaps two? three at most? who have actually 'bothered' to provide info regularly since this issue came up months ago. I don't see others providing this much detail here in this topic so I suggest you be grateful for the help I am providing!

[condoghost]

Is there a new build I can grab to continue?

xavier2k6 Not until we have more info/possible patch from @arvidn to go on. (If needed)

More info? What 'more info' is needed? 'Redacted' info which is pretty 'worthless' in real terms given 'the devil is in the detail'? How much 'more info'? I'm astounded at the lack of courtesy shown here. Apart from 'what does this relate to?' from @arvidn? nothing. No 'feedback', no 'status', no 'progress', nothing. Time for me to 'move on'. I post 'info' and all I get is 'why can'y you post redacted data?' from others who haven't posted any data whatsoever and then yourself looking to 'justify reasoning' for 'why' I should do something 'more'. Unbelievable.

[xavier2k6]

I've not requested your 'opinion' My post was directed to @FranciscoPomba

ok, then - I take exception to that

'Help us, to help you.'? I take exception to that given I appear to be only one of perhaps two? three at most? who have actually >'bothered' to provide info regularly since this issue came up months ago. I don't see others providing this much detail here in >this topic so I suggest you be grateful for the help I am providing!

so I suggest you be grateful for the help I am providing!

Ok, first of all - read the OP https://github.com/qbittorrent/qBittorrent/issues/12583#issue-605150325

There has been more than one issue thread about proxies etc There has been more than one person giving info/help wherever & whenever needed (as much as needed/requested)

If you read through this issue or any other tracker - you will see that I have helped with providing test builds or linked to other builds that @FranciscoPombal built , which you have used.

This is a project that is handled by volunteers in their own personal time!

and to quote you again.

so I suggest you be grateful for the help I am providing!

[xavier2k6]

Is there a new build I can grab to continue?

xavier2k6 Not until we have more info/possible patch from @arvidn to go on. (If needed)

More info? What 'more info' is needed? 'Redacted' info which is pretty 'worthless' in real terms given 'the devil is in the detail'? How much 'more info'? I'm astounded at the lack of courtesy shown here. Apart from 'what does this relate to?' from @arvidn? nothing. No 'feedback', no 'status', no 'progress', nothing. Time for me to 'move on'. I post 'info' and all I get is 'why can'y you post redacted data?' from others who haven't posted any data whatsoever and then yourself looking to 'justify reasoning' for 'why' I should do something 'more'. Unbelievable.

and I am done, to other users experiencing this issue, my apologies but at this time - I am no longer interested in spending my valuable spare time with regard to this, going to spend my time more wisely with my wife & kids.

[xavier2k6]

@FranciscoPombal @arvidn please respond to @condoghost when you get a chance & help him ASAP!!!! with his requests/demands - self entitlement or whatever else anyone wants to call it, I'M DONE!.

[arvidn]

More info? What 'more info' is needed? 'Redacted' info which is pretty 'worthless' in real terms given 'the devil is in the detail'? How much 'more info'?

@condoghost The most important information that I would be interested in is some evidence that something in libtorrent is not working as intended. So far I haven't seen anything. If you think that there is a problem in libtorrent, please describe it as clearly and succinctly as possible (ideally in complete sentences and no quoted nebulous words like "stable", explain what you mean instead).

Keep in mind that your proxy disconnecting you, or your internet connection failing, does not indicate a problem in libtorrent. Now, I'm not saying it's your proxy or your internet connection that's causing the issue you experience, I'm saying that I haven't seen anything to suggest it isn't. Ruling out other likely causes of issues would be very useful.

So far, the most prominent description of the problem is that trackers says "Not working" in the qBT UI. This is not actionable information. I don't know the exact conditions of when qBT displays that message, but I'm pretty sure it does it under all kinds of different failures (and in fact, I'm pretty sure it displays that message when trackers are working sometimes too).

Any report based around "qBT says my tracker isn't working" carries extremely little weight in my book, as I'm pretty sure that's not an indication of it not working. Something like "I've turned off DHT, LSD and incoming connections and removed all trackers but this one, and I'm not getting any peers from it via a proxy, but I do get peers when I don't go through a proxy". That would be much more useful information. Because it reports the actual problem.

Obviously it's also a good bug report to say something like: "my tracker is working, but the UI still says it's not working". That should be fixed, and maybe it needs to be fixed before we can get any clarity on the reports in this ticket. But, it's different enough from the topic here that it should be reported separately.

Either way, I think all of the reports in this ticket are different from the title. The title of this ticket was addressed and fixed a long time ago.

@condoghost to round up, I received your logs, but I still don't know what to look for in them, because I don't know what issue you're experiencing. Just pointing to this ticket isn't good enough, because this ticket is about "SOCKS5 proxy disconnect issue due to insufficient retries" and that's not the issue you're experiencing.

[condoghost]

arvidn

@condoghost to round up, I received your logs, but I still don't know what to look for in them, because I don't know what issue you're experiencing. Just pointing to this ticket isn't good enough, because this ticket is about "SOCKS5 proxy disconnect issue due to insufficient retries" and that's not the issue you're experiencing.

Your telling me you now 'weeks later' that you can't tell the issues being experienced?

I'm just a 'simple minded user' who reported a problem with SOCKS5 and ended up being re-directed here as a result of 'original threads' being 'closed' and here you see the 'WHY' as Cunningcory commented on Apr 23 I just love every year or so having to re-follow a new thread on basically the same issue since the others keep getting closed without being fixed. SOCKS5 has never worked for me, and I've always tried newer builds without any difference, including the next to last one posted on the most recent closed discussion. I'm in the middle of testing the current build and was going to give feedback, but the thread was closed. And FranciscoPombal commented on Apr 23 Umm, yes? Did you read #11735 (comment)? This issue report was opened specifically to track this disconnect issue, which is the important thing now. The other thread was already filled with unrelated information. It is easier to track this single issue with a clean slate. And as Cunningcory then commented on Apr 24 @arvidn Xavier is correct, that's the error. This is why I don't understand why the other thread was locked down as the discussion was troubleshooting "proxies and UDB issues". I guess this is just to get more specific to SOCKS5? It just feels like having to start from scratch with the troubleshooting. For me and seems most people this has always been the issue for years. You start qbittorrent and everything is working fine with SOCKS5. Then you return later and it isn't working. You then restart the Qbit (maybe several times) and then it works again for a brief amount of time. This is the problem I have always had, so I guess I'm confused as to what other issues have been fixed. As to ...

This is why I don't understand why the other thread was locked down as the discussion was troubleshooting "proxies and UDB issues". I guess this is just to get more specific to SOCKS5? It just feels like having to start from scratch with the troubleshooting.

FranciscoPombal replied on Apr 24

The other issue was closed because it was an "umbrella issue" for many different problems, most of which have been fixed. The notable exception is this one SOCKS5 issue. So this issue was opened to:

* deal _specifically_ with this SOCKS5 problem, without having to sift through huge amounts of unrelated information in between

* clearly indicate that everything else is fixed

Of course, some things have to be copy-pasted back here, but it's not much in this case (anyone can copy-paste 2 log lines), so I think it's worth it.

When in FACT the ORIGINAL ISSUE WAS and STILL IS EXACTLY AS WAS RAISED in the FIRST place!

And you arvidn on Apr 23 the best thing to do, for someone experiencing socks5 not working and wanting it to be fixed, is to post a wireshark dump of the UDP ASSOCIATE socks5 connection. Ideally just that TCP stream, to keep the noise down. It probably won't get fixed unless it breaks (or is demonstrated breaking) for someone able to fix it.

Do you really think us 'users' have a clue what you are talking about? I for one certainly don't.

And now you are telling me "this ticket is about "SOCKS5 proxy disconnect issue due to insufficient retries" and that's not the issue you're experiencing."???

I set SOCKS5 and we are on a wing and a prayer if trackers actually work or not, if torrents actually show Seeds, Peers and start downloading uploading or not. Sometimes the client starts out 'okay' and then goes into a never ending death-dive until we restart and go through the same thing over and over again yet YOU tell me YOU can't tell anything from what is being said?

Seems to me this is a simple case of 'not me guv' 'pass the buck back and forth'.

I set No Proxy and client runs as smooth as silk forever and ever EXCEPT without the proxy the detail of our activity is EXPOSED.

And isn't it interesting, as has been reported time and time again, we can run the client with a proxy with a proxy app running outside the client and we get FULL SECURITY, no leakage, with the client working smoothly no probs yet the moment we set Proxy Server SOCKS5 within the client we're on a wing and a prayer and we get this back and forth qbittorrent client? libtorrent?

I don't know, I'm just a 'user' but between all you 'developers' you should be able to work out this out to some extent!

[condoghost]

xavier2k6 @FranciscoPombal @arvidn please respond to @condoghost when you get a chance & help him ASAP!!!! with his requests/demands - self entitlement or whatever else anyone wants to call it, I'M DONE!.

I'm so pleased you are DONE xavier2k6 because you are OUT-OF-ORDER here going on about 'demands' 'self entitlement' 'whatever else anyone wants to call it'!!!

Outrageous that you respond in this fashion. No wonder so many here simply 'give up' and 'move on' with a different client with attitudes like this.

[condoghost]

I've not requested your 'opinion' My post was directed to @FranciscoPomba

ok, then - I take exception to that

'Help us, to help you.'? I take exception to that given I appear to be only one of perhaps two? three at most? who have actually >'bothered' to provide info regularly since this issue came up months ago. I don't see others providing this much detail here in >this topic so I suggest you be grateful for the help I am providing!

so I suggest you be grateful for the help I am providing!

xavier2k6 Ok, first of all - read the OP #12583 (comment)

There has been more than one issue thread about proxies etc There has been more than one person giving info/help wherever & whenever needed (as much as needed/requested)

If you read through this issue or any other tracker - you will see that I have helped with providing test builds or linked to other builds that @FranciscoPombal built , which you have used.

This is a project that is handled by volunteers in their own personal time!

and to quote you again.

so I suggest you be grateful for the help I am providing!

"read the OP [#12583"? Do you really think we haven't read every OP out there on this issue and posted on them too? Of course we have. As for 'There has been more than one issue thread about proxies', read my reply above to arvidn where I have included Cunningcory commented on Apr 23 and the 'response' FranciscoPombal commented on Apr 23.

This issue of SOCKS5 where the client shows trackers working and torrents with seeds, peers downloading and uploading suddenly deciding it 'doesn't want to play' with trackers not working and new torrents sat there doing 'nothing', sometimes 'starting', sometimes 'not', to such a point we close the client, clear our cache, temp files, whatever. And when we restart the client, often as not, those torrents 'doing nothing' spring to life showing seeds and peers, downloading and uploading yet trackers showing 'not working', and as likely as not, new torrents then loaded either 'sit there forever doing nothing' with 'trackers not working' or immediately 'spring into life' with trackers immediately working and torrents immediately having seeds, peers, downloading and uploading.

If this is NOT an ISSUE then pardon me for even existing. Is it a qbittorrrent issue or a libtorrent issue? I don't know but for sure it looks like 'no one knows'.

And with arvidn now saying "I think all of the reports in this ticket are different from the title. The title of this ticket was addressed and fixed a long time ago." I and many others with this 'issue' no longer have a clue what is going on if indeed this 'issue' is or has ever been looked at in real terms!

And as for your "and to quote you again.

so I suggest you be grateful for the help I am providing!

You haven't provided any help on this at all except to gripe that I wasn't prepared to post a meaningless redacted file here nor a non-redacted file containing sensitive information!