Network status "Not connected"

[Rohcode]

Describe the problem
Can't connect to network. Stuck on "Not connected".
Is there a way to force attempt connect on a server? Like a 'Connect' button?
Can't seem to force an attempted connection to a server and get more info from logs...

To Reproduce
Steps to reproduce the behavior:

1. Launch ElectrumSV and login
2. See Error: Network status "Not Connected"
3. See Logs

Note: tried no VPN, VPN USA, VPN Australia...
Also tried reinstall latest version...
Still can't connect.

Expected behavior
It connects to a server and works, or if fails, keeps trying to connect until it does.
Typically Server> "Select server automatically" works fine. You login and it works.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• ElectrumSV version: 1.3.16
• OSX 13.3

Additional context
Log:
2023-08-13 13:08:50,259:WARNING:network:('sv.jochen-hoenicke.de', 50002, 's') connection error: [Errno 8] nodename nor servname provided, or not known
2023-08-13 13:08:50,489:WARNING:network:('electrumx-sv.1209k.com', 50002, 's') connection error: [Errno 8] nodename nor servname provided, or not known
2023-08-13 13:08:50,504:WARNING:network:('electrumx.gorillapool.io', 50002, 's') connection error: [Errno 61] Connect call failed ('99.127.49.102', 50002)
2023-08-13 13:08:50,541:WARNING:network:('electrumx.bitcoinsv.io', 50002, 's') connection error: [Errno 61] Connect call failed ('178.128.39.70', 50002)
2023-08-13 13:08:54,432:ERROR:async:async task raised an unhandled exception
Traceback (most recent call last):
File "electrumsv/async_.py", line 94, in _collect
File "concurrent/futures/_base.py", line 439, in result
File "concurrent/futures/_base.py", line 391, in __get_result
File "electrumsv/network.py", line 944, in _main_task
File "aiorpcx/curio.py", line 255, in aexit
File "aiorpcx/curio.py", line 213, in join
File "electrumsv/network.py", line 973, in _maintain_connections
File "aiorpcx/curio.py", line 255, in aexit
File "aiorpcx/curio.py", line 213, in join
File "electrumsv/network.py", line 987, in _maintain_connection
File "electrumsv/network.py", line 266, in connect
File "electrumsv/network.py", line 763, in run
File "electrumsv/network.py", line 463, in _negotiate_protocol
TypeError: cannot unpack non-iterable NoneType object

[AustEcon]

Hi. This has been reproduced and fixed here:
#1132

It's because of a bad ElectrumX server that's not being handled and blacklisted...

This fix won't help you though until it's in the official release.

I'm preoccupied right now with social events but when I'm next free I'll look at whether it's possible for you to perhaps blacklist the bad server manually in the config.json file by manually inputting a blacklist timestamp.

[Rohcode]

Thanks for the update.
Weird that it crashes even manual connection. Are there better ways to design the redundancy so that if auto breaks we can still connect manually since with manual down I've no way to move any funds – other than exporting seed to another wallet? Still new and learning but was also wondering if future versions might allow us to run our own lite client / monitoring services in the background like CSW mentions in his Masterclass rather than calling out to TTP servers that you run at your cost.
Thank you

[rt121212121]

If you are experiencing connectivity problems with ElectrumSV, it is likely because a bad actor has put up a fake server and the error they cause on connection was chosen to make this happen. Go to network settings, turn off autoselect server and pick a good one.

[Rohcode]

Thanks for the suggestion.
Was unable to turn off autoselect and pick a good one because clicking or double clicking any Host in the list didn't seem to update (Server: field didn't update and if checking logs, no new connect attempts) but your solution here worked https://roger-taylor.medium.com/blocking-a-bad-electrumsserver-c7f85c25d2a3
Thanks!

[AustEcon]

Glad that fix worked for you @Rohcode. Roger's medium article is the same idea I was referring to of manually blacklisting the bad server with a blacklist timestamp.