VPN Dropped, N+ Froze - Now it hangs on Preparing Shares

[DeathStalker77]

Nicotine+ version: Nicotine+-3.3.3rc2-mingw_x86_64 04-13
Operating System/Distribution: Win 10 Ent 22H2 19045.4291

Describe the bug

My VPN dropped & reconnected - to a different Port. This locked up N+ and pretty much my whole system. I was able to kill N+ w/Task Mgr and then installed Nicotine+-3.3.3rc2-mingw_x86_64 04-18 -- same behavior (yes, I did manually change the PORTs in the Config file!)

It's the N+.exe that is hanging and eating up all my load. The "swirl" for Preparing Shares is stopped, but it does register the login.

Also tried running Repair with Nicotine+-3.3.3rc2-mingw_x86_64 04-18 -- even WORSE! Now it won't even log in!
__
Ran Repair again with Nicotine+-3.3.3rc2-mingw_x86_64 04-18 - waited for msiexec.exe to end, then launched N+ again - and it's back to hanging on Preparing Shares, but then it does log in -- however, it remains on hung on Preparing Shares (no movement of the "swirl")

In Task Manager, Power Usage is VERY HIGH, CPU is ~10%, and MEMORY is ~300MB - 0MB/s DISK

I will let it sit for a while and see if there is any change. Also, between crashes, I flipped DEBUG from FALSE to TRUE - maybe that will help.

No, that didn't help - it hung my whole system for ~3+mins - couldn't even move the mouse - before it released. But STILL hung and none of the above settings have changed. AND it hung again TWICE for about the same amount of time as I was typing this !

Expected behavior

No other version has done this.

Steps to reproduce the bug

As described above

Additional context

And msiexec.exe still remains running after install or repair

Here is the DEBUG file info:
2024-04-20 00:45:04 Loading Python 3.11.9
2024-04-20 00:45:04 Loading Nicotine+ 3.3.3rc2
2024-04-20 00:45:04 Faulthandler module could not be enabled. Error: sys.stderr is None
2024-04-20 00:45:04 Loading GTK 4.14.2
2024-04-20 00:45:04 Loading plugin system
2024-04-20 00:45:04 Loaded plugin Nicotine+ Commands
2024-04-20 00:45:04 Loaded plugin Anti SHOUT
2024-04-20 00:45:04 Leech Detector: Require users have a minimum of 1000 files in 50 shared public folders.
2024-04-20 00:45:04 Loaded plugin Leech Detector
2024-04-20 00:45:04 Loaded plugin Multi Paste
2024-04-20 00:45:04 Listening on port: 43643
2024-04-20 00:45:04 Connecting to server.slsknet.org:2416
2024-04-20 00:45:25 Connected to server server.slsknet.org:2416, logging in…
2024-04-20 00:45:25 Rescanning shares…
2024-04-20 00:45:25 2024 privileged users

Contents of this part of the DEBUG file are no different than prior ones - all include:
Faulthandler module could not be enabled. Error: sys.stderr is None

[mathiascode]

If you downgrade to 3.3.2 now, does the issue stop? Does it then start again if you go back to 3.3.3rc2?

[mathiascode]

I tried the latest rc2 on my Windows test machine. Didn't notice anything abnormal on my end compared to previous versions.

[DeathStalker77]

Dropping back to 3.3.2 (Nicotine+-3.3.2-mingw_x86_64 02-26) logs in and gets past Preparing Shares, but hangs on Scanning Shares (and hangs the system periodically). Since it got this far, I'll let it sit a bit and see if it progresses at all on the Scanning.

UPDATE: Ok, so I waited over 5 minutes with no difference. Killed it with Task Manager. Edited the Config file to REMOVE the listed Shares. Installed the latest build (Nicotine+-3.3.3rc2-mingw_x86_64 04-21) and let the msexec.exe close out. Re-launched it - same thing, only it's hanging on nothing - not Scanning Shares of anything - and I don't even have a large queue. It totally locked up my system.

[DeathStalker77]

Ok, so here's where I'm at now. I cleaned out everything, reset ports, all is connecting now, and transferring. Took a lot of messing around :-( Also, interestingly, had to change the SLSK server from 2416 to 2242.

[slook]

2024-04-20 00:45:04 Connecting to server.slsknet.org:2416
interestingly, had to change the SLSK server from 2416 to 2242

Then I think that might mean you we're attempting to connect to the old legacy server, which hasn't been supported by modern clients for over a decade now.

Whilst it would have been interesting to find out exactly why an erroneous server configuration hung the client, this doesn't really need investigating now, since you found the solution.