DC++

Windows 10 DC++ loses search after a few minutes

Asked by george borton

When I first log into a hub I can search and initiate downloads for a few minutes, at most. I am then no longer able to get search results or have downloads initiate until I have clicked "Detect Now" under automatic connectivity settings. Once I do this, the process starts over again.

 Any suggestions on overcoming this issue would be greatly appreciated.

Question information

Language:
English Edit question
Status:
Answered
For:
DC++ Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
eMTee (realprogger) said : 		#1

Some of your detected network settings are changing rapidly it seems. This is pretty unusual.
Can you copy a Detection log and the output of the /connection chat command twice, once after you start DC++ and then when you have to re-detect?
If you paste them here we might learn about what's changing...

Revision history for this message
george borton (lyinggod) said : 		#2

I am not sure how this would be beneficial. Supposedly, DC++ is seeking ot the "best" connectivity. The 3 ports seem to change randomly each time the detect button is pressed as NAT-PMP or UPnP seem to be reconfiguring the router during each re-detect. The question is what causes the loss between the Detect #1 and Detect #2?

I am including the information requested in the hopes that someone can see something that I don't

Detection Log Before re-detect

IPv4: Port mapping: Successfully created port mappings (Transfers: 55664, Encrypted transfers: 55665, Search: 52394) on the "WAN Device" device with the MiniUPnP interface
IPv6: All IPv6 addresses found are local; disabling connectivity

Detection Log After re-detect
IPv4: Determining the best connectivity settings...
IPv4: Local network with possible NAT detected, trying to map the ports...
IPv6: Determining the best connectivity settings...
IPv6: All IPv6 addresses found are local; disabling connectivity
IPv4: Port mapping: Successfully created port mappings (Transfers: 55931, Encrypted transfers: 55932, Search: 53406) on the "WAN Device" device with the MiniUPnP interface

Can you help with this problem?

Provide an answer of your own, or ask george borton for more information if necessary.

To post a message you must log in.