Nicotine+ freezes for minutes at a time

[rgbdx]

3.2.9 • GTK 3.24.38
OS: Void linux, also present on Artix and Devuan

Describe the bug

Nicotine will just be idle on the background doing its thing. After some period of interacting with it (e.g. checking traffic/chatting) the client will freeze for several minutes. Ill have to kill it to get it to work again, but after which newly written data will be gone (trsnsfer statistics/pm's). During the freeze nothing is interactable and sometimes my mouse even disappears (it reappers when switching to other applications)

Expected behavior

To not crash

Steps to reproduce the bug

1. Start nicotine
2. wait
3. freeze

Additional context

Starting nicotine through a terminal reports no errors

[slook]

The 3.2.x branch is no longer maintained. Perhaps there might be somebody attempting to queue a lot of files for you at one time, you might want to enable the Connections log to see what events are happening (please note, the logging view itself does cause serious performance issue - you should disable log categories when not required).

Please compare if the problem is present or not with Nicotine+ 3.3.0.dev6:
https://github.com/nicotine-plus/nicotine-plus/blob/master/doc/TESTING.md

[rgbdx]

i can confirm there are many files being downloaded, but my computer should be easily able to handle that. im currently running 3.3.0.dev6 • Python 3.12.0 • GTK 3.24.38. though it is a little laggy its atleast usable now. ill report back if issues persist again. Thank you

[slook]

You are welcome. Having implemented several new features and large code refactoring, now we are currently working on profiling for performance optimizations and stability.

my computer should be easily able to handle that

It has little to do with your machines performance, since the main thread of Nicotine+ only uses a single CPU core. This means that any bugs in the program can't bring down your entire machine, but it can make the application more prone to hanging in certain situations.

Many scenarios are still yet to be fully tested including real world heavy load use cases. If you are interested in helping us you could help us to identify where improvements are needed.

It involves running Nicotine+ from a Git folder and then using py-spy for profiling to monitor in the terminal console to identify the exact lines of code which are consuming CPU time and memory. With those data maybe we could make some progress on issues like:

• Add separate thread that handles file operations for transfers [3.3.0.dev1] Developer Discussion #1881 (comment)

• Downloading a folder that contains many files from Browse Shares causes the entire application to freeze [3.3.0.dev1] Developer Discussion #1881 (comment)

... in addition to a most important factor of ensuring that the application is not vulnerable to being hung by remote peers (either unintentionally or maliciously).

If you are able and have the time to grab some py-spy output data/screenshots for us, then it would be very much appreciated by everybody who uses N+.

[rgbdx]

I sadly have to inform you that nicotine+ becomes unresponsive very quickly again. im running 3.3.0 through a git folder indeed. ill look into the py-spy thing but it sadly wont be of much use if my client is unresponsive 90% of the time

[slook]

my client is unresponsive 90% of the time

Then in that case, it will be easy to tell which function the hang exists within, run..

pip install py-spy
py-spy top ./nicotine

(press L to toggle line numbers).

... then it will be the top few lines (i.e. the ones showing 90% usage) which we need pasted in here.

[DeathStalker77]

I will see if I can do the same - I am running the nightly build from the 20th.

ok, read your statement above about running it through a Git folder etc - no idea how to do that, as I don't code :( If there is something in the log file itself that can identify this, that would be good. If not currently, then might I suggest adding something, or a separate DEBUG log in order to do this easier and more effectively?

Please remember, that what is "easy" for a coder, is NOT "easy" for a non-coder, and you want to be able to receive as much information/input as possible, in the easiest & most efficient way possible :-)

--- DS

[mathiascode]

I will see if I can do the same - I am running the nightly build from the 20th.

ok, read your statement above about running it through a Git folder etc - no idea how to do that, as I don't code :( If there is something in the log file itself that can identify this, that would be good. If not currently, then might I suggest adding something, or a separate DEBUG log in order to do this easier and more effectively?

Please remember, that what is "easy" for a coder, is NOT "easy" for a non-coder, and you want to be able to receive as much information/input as possible, in the easiest & most efficient way possible :-)

--- DS

Unfortunately, Windows is on the bottom of the list when it comes to accessible testing and profiling of Nicotine+. py-spy doesn't work with Nicotine+ on Windows.

You can set up your own development environment and use Python's own cProfile, but the process is somewhat convoluted and the profiler slows down Nicotine+ considerably. I don't recommend doing this.

The only easy way to profile Nicotine+ is to use Linux, unfortunately.

[DeathStalker77]

Not an option for me, as I say, I don't code. I think someone should be prioritizing Windows - it IS still the most prominently used OS (and Linux is the least).

Respectfully, IMPO, this effort should be driven by usage, not dev personal preferences.

As I've noted before - KISS PRINCIPLE :-)

Additionally, there should be a method to handle these "pauses:/"Not Responding" in a better manner than the current "white screen" which produces the popup for CLOSE THE PROGRAM or WAIT FOR THE PROGRAM TO RESPOND.

*Just a thought - maybe you could have a setting for users to allocate an amount of RAM to the program to help improve performance?

[slook]

This bug isn't platform specific.

When it's fixed then performance will improve on all platforms, since the master build packaging is cross-platform.

The problem is unrelated to RAM.

[DeathStalker77]

Well, it was working "fine" for a while, then I shut it down to try changing ports, now it's back to just hanging after starting :-( It "prepares" the shares, then hangs, but I still get the notifications of Messages & Away/Back statuses, but I can't do anything - the file count in the "frozen" UI never changes, but I can see the JSON file size reducing. This is with the latest 25-OCT build.

Interesting correction - the download.json file does not always get smaller, it seems to ... fluctuate. When I posted this, it was smaller than previously, but when I just checked it now, (about 2hrs later), it was larger. Not sure I completely understand why that would be, since nothing was added to the file, and the UI is still "frozen" (and showing all users as "User logged off").........

[slook]

@rgbdx Apparently the issue you reported is drastically improved since #2709 please can you try the latest master and let us know if you see an improvement, or if something else is needed. Thanks.

https://nicotine-plus.org/doc/TESTING.html

[mathiascode]

I think someone should be prioritizing Windows - it IS still the most prominently used OS

I test the Windows builds from time to time and make sure they're usable, but the Windows version has always been a best-effort port. Linux is the primary development platform for Nicotine+ and has always been so.

If a developer using Windows or macOS as their primary OS wants to ensure all development tools work there, and Nicotine+ is in great shape, I would greatly appreciate that. However, I'm currently the only person working on the Windows and macOS ports in my free time, on old hardware or in slow VMs (thanks Apple), and I'm not interested in spending more time on them than necessary.

@rgbdx Further improvements to file transfer performance have been made. Please try the latest development version of Nicotine+ and let us know if the issue is fixed: https://nicotine-plus.org/doc/TESTING.html

[DeathStalker77]

Sounds like we need to put a "call out" for more Windows devs then! Rough taking it all on by yourself! As I say, MOST users are on Windows - Linux is still FAR in the minority of the public. That may be why so many Orig SLSK users still haven't transitioned over. Maybe we need to look at a more concerted effort to get the word out about ALL the improvements (plus those yet to come!) on N+, and that (at this point) N+ IS the future of SLSK. :-)

[DeathStalker77]

I seem to be getting a LOT more "pauses"/"freezing" with the 17-NOV Nightly Build than I was previously. I also have one user I'm DLing from who seems to be "stuck" in a perpetual "CONNECTION TIMEOUT" status.

[DeathStalker77]

I had to drop back to the 06-NOV build for it to correct itself.

[mathiascode]

I had to drop back to the 06-NOV build for it to correct itself.

The freezing or the "Connection Timeout" status? There was a bug in earlier development builds where downloads would get stuck on the "Queued" status instead of changing to "Connection Timeout" as intended.

[DeathStalker77]

@mathiascode - both! The 17-NOV build froze a LOT more and it also stuck files in the "Connection Timeout" status. It seems "likely" that the sticking of statuses may be related.

[mathiascode]

@mathiascode - both! The 17-NOV build froze a LOT more and it also stuck files in the "Connection Timeout" status. It seems "likely" that the sticking of statuses may be related.

Unless the "Connection Timeout" downloads successfully start in older builds, downloads appearing stuck with that status is not a bug. Could you verify if you're still able to browse the shares or profiles of users sharing these files?

It's possible that frequently retrying these failed downloads (currently every 3 minutes) is causing freezes. I'll look into it.

[mathiascode]

Closing, as this issue should be fixed in the latest development version. Please re-open if it isn't fixed.