4.2.5 takes half an hour to load UI

[ned-martin]

qBittorrent version and Operating System

v4.2.5 x64
Windows 10 (running virtualised under Hyper-V)

What is the problem

After updating to 4.2.* versions a few times and finding them to vary between unstable and unusable, I made the mistake of updating again today - this time to 4.2.5 from 4.1.9.1

It takes about half an hour to load the UI. A blank white/grey "qBittorrent v4.2.5 (Not Responding) " window loads up, and then half an hour later (I'm not joking!), starts responding. By the time it's responding, it has built up a commit size of over 12 GB, but only 500MB or so working set.

I'm not really sure what else to check. Process Explorer says it's opened a large amount of connections, so it would appear that it may actually be functioning while the UI is non-responsive. There is very little disk IO.

What is the expected behavior

Program opens a responsive UI in a timely manner and does not use 12 GB RAM.

Steps to reproduce

Upgrade from 4.1.9.1 with many existing torrents and then try to open v4.2.5

Additional Info

• Windows 10 is virtualised using hyper-v
• Network access is via a VPN
• The downloaded files are stored on a network share, which is connected via virtualised 10-GigE. This does not use the VPN
• All the other files are stored in their default locations, %appdata%/qBittorrent etc.
• There does not appear to be any performance bottleneck anywhere that I can find - disk usage/queues on both the local VM and the network storage disks are fine. Network access is fine.

[ned-martin]

When I was using Windows (till couple days ago) I had the same problem. White screen and not loading the UI. The way I always made it show is by pressing 2 times the try icon (close/reopen) and it showed up immediately. :)

Unfortunately, I can confirm that this does not work.

[ned-martin]

qBittorrent had reached 28GB RAM (commit) usage, which hits the limit of the 32GB RAM in the machine it's running in, so I had to close it and re-open it. It's currently non-responsive. In theory, in half an hour or so, it'll become responsive and load the UI.

Point being, that there's also some serious memory issues, along with the serious loading/UI issues.

[ghost]

Faced same issue since 4.2.2. White qBt screen with Not responding in title. Though I didn't face it on startup. Usually it happens after running for some time with lot of download/upload activity going on. There's definitely a memory leak issue.

[xavier2k6]

It may have been due to checking/re-checking torrents too.....

From 4.2.0 onwards!

ATTENTION: This release uses the libtorrent 1.2.x series. It saves fastresumes a bit differently than the 1.1.x series, which are used so far in the previous versions. If you run it and then downgrade to a previous qBittorrent version then your torrents will probably start rechecking.

If you want to try another 4.2.5 build, then you can try #12652 (comment)

This was built with latest libtorrent commit/Boost 1.73 & Qt 5.14.2 at time of compilation.

[FranciscoPombal]

There is in fact a memory leak related to HTTPS tracker connections in libtorrent that affects some people: #12326

But it does not have to do with UI slowdowns (at least that's not been reported as a symptom related to that problem).

So this memory leak you are experiencing is most likely due to something else.

[ghost]

It may have been due to checking/re-checking torrents too.....

From 4.2.0 onwards!

ATTENTION: This release uses the libtorrent 1.2.x series. It saves fastresumes a bit differently than the 1.1.x series, which are used so far in the previous versions. If you run it and then downgrade to a previous qBittorrent version then your torrents will probably start rechecking.

If you want to try another 4.2.5 build, then you can try #12652 (comment)

This was built with latest libtorrent commit/Boost 1.73 & Qt 5.14.2 at time of compilation.

That rechecking happens only on downgrades. You can update without any sort of rechecks.

[xavier2k6]

That rechecking happens only on downgrades. You can update without any sort of rechecks.

I know that but.........

After updating to 4.2.* versions a few times and finding them to vary between unstable and unusable, I made the mistake of updating again today - this time to 4.2.5 from 4.1.9.1

I took that as they they were on 4.2.x series, downgraded to 4.1.9.1 & then went back to 4.2.5.

It's not exactly clear in what kind of time frame this was done......straight away/after a few hours/after a few days etc.

There's a test build in my previous post anyway to try out.

[ned-martin]

I can confirm that no torrents are being rechecked.

I'm finding it difficult to understand how I can be the only one experiencing this problem. I can't see how my situation is different. The only remotely non-standard aspect of my install is that the torrents themselves are stored on a network share, and the machine has local swap disabled (i.e. RAM only - no swapping to disk). The local config, .torrent and .fastresume files, etc. are all stored in their default locations.

I deleted my settings and tried defaults - same problem. Opening qBittorrent results in the UI being non-responsive for around half an hour, and once it responds it's committed about 8GB of RAM, which then slowly builds up to 28GB (the limit it can reach on my machine) over the next several hours.

I have approx 1,800 torrents in the client - is it perhaps just not possible to use qBittorrent anymore unless you only have a handful of torrents?

[FranciscoPombal]

@ned-martin

I can confirm that no torrents are being rechecked.

I'm finding it difficult to understand how I can be the only one experiencing this problem. I can't see how my situation is different. The only remotely non-standard aspect of my install is that the torrents themselves are stored on a network share, and the machine has local swap disabled (i.e. RAM only - no swapping to disk). The local config, .torrent and .fastresume files, etc. are all stored in their default locations.

Have you tried without the network share? It should not be a problem, but your whole situation is quite strange, so might as well try that.

I have approx 1,800 torrents in the client - is it perhaps just not possible to use qBittorrent anymore unless you only have a handful of torrents?

No, qBittorrent can easily handle several thousands of torrents.

[ned-martin]

If you want to try another 4.2.5 build, then you can try #12652 (comment)

This was built with latest libtorrent commit/Boost 1.73 & Qt 5.14.2 at time of compilation.

I can confirm that this version does not appear to be any different, other than making a lot of empty mat-debug-*.log's. It is currently non-responding. I'm guessing in half an hour it'll load the UI.

[ned-martin]

Have you tried without the network share? It should not be a problem, but your whole situation is quite strange, so might as well try that.

Surely using a network share is not a "strange" situation? Either way, no, unfortunately I cannot try without it.

In case it wasn't apparent - with no torrents (i.e. a clean empty install) qBittorrent opens immediately. I haven't bothered downloading anything in it but I imagine it'd work just fine. But with my torrents loaded, it takes half-an-hour-ish to open and exhibits the aforementioned problems.

I can't try with my torrents loaded without using a network share (because that's where the torrents are stored - and it's where the fastresume files point at, so even if I did have the spare storage to somehow copy the torrents across to a local disk, I don't know how to make it do that).

I can try without a network share with no torrents, but then that doesn't seem to be helpful as it's just an empty install at that stage.

For what it's worth, the network share is on a virtual 10-gigE connection, so there's effectively no latency or bottlenecks there. I've looked at disk queues and so forth, both locally and on the network share disks, and nothing seems to be a bottleneck. There doesn't appear to be any excessive use of anything - it's just sitting there very slowly doing "something" until it has loaded 8GB or so and then the UI will become responsive.

Then once it's responsive, it works fine until it uses up all the available RAM, at which point it will eventually crash.

[xavier2k6]

Snippet from #11348

disk cache is set to 64MiB / 60s expiry.

Is this still the case with your current setup?

[ned-martin]

Snippet from #11348

disk cache is set to 64MiB / 60s expiry.

Is this still the case with your current setup?

No, at this stage I have disabled disk cache, and every other form of caching I could find.

However, I have tried with it both enabled, disabled, and random different values, without any noticeable change.

Attached is my current ini file.
qBittorrent.ini.log

[xavier2k6]

Try enabling/setting the following in qBittorrent's advanced settings:

Enable OS Cache -> yes (tick)
Coalesce reads & writes -> yes (tick)
Disk Cache -> -1 (auto)

Is pagefile disabled in your OS?

The logs you say are being created with the build I provided seem to point to a driver issue?!
Anybody else that has used that build have reported no such logs being created.....

[ned-martin]

Try enabling/setting the following in qBittorrent's advanced settings:

Enable OS Cache -> yes (tick)
Coalesce reads & writes -> yes (tick)
Disk Cache -> -1 (auto)

Is pagefile disabled in your OS?

The logs you say are being created with the build I provided seem to point to a driver issue?!
Anybody else that has used that build have reported no such logs being created.....

I have set the settings like you said, however I believe that's probably how they were at the start before I tried changing everything. I tried disabling everything that seemed like it might cause some kind of delay (for example, I turned off resolve DNS etc.)

The log files are empty files named like mat-debug-7952.log, apart from aria-debug-9184.log which contains the following:

2020-05-15 01:32:53.487|00003816| C:\build\aria-cpp-v1\clienttelemetry\src\LogManagerImpl.cpp(626): class Microsoft::Applications::Telemetry::ILogger *__thiscall Microsoft::Applications::Telemetry::LogManagerImpl::Initialize(const class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &,const struct Microsoft::Applications::Telemetry::LogConfiguration &) WARNING: Invalid in-ram queue size (20971520), adjusted to max ram queue size

Yes, pagefile is disabled.

The OS is Windows 10 x64 with 48GB RAM (it was 32GB when I logged the issue but I've increased it - I also tried decreasing it to 16GB in case that was somehow relevant). It is virtualised on Hyper-V, and the downloaded data is stored on a network share. It confuses me that I'm seemingly the only one having this issue, as it's a very normal Windows 10 install. Nothing else installed. The hardware and drivers are as generic as possible - because it's virtualised.

The only non-standard things I can think of are:

• DNS and all external internet access is through a (common brand-name) VPN, which is set as the default route in Windows. DNS, and all other data to external addresses is blocked at a firewall if it does not go through the VPN for some reason
• The data is stored on a network share, rather than a local disk

I imagine they're related, but there seems to be two problems:

1. Why does it take nearly half an hour to load the UI?
2. After running for several hours, qBittorrent is using 501,076K working set, 18.821,520K commit. Windows says 14.3 GB RAM is cached, and only 4.2GB is in-use.

Let me know if there is any data I can give you that may be of use to troubleshoot this.

[FranciscoPombal]

Those aren't fastresume files and those logs do not belong to qBittorrent.

[Phooh]

I'm recently having the same issue here on Windows 7. I had no issues with 4.2.5 until today as I've been using it since it was released. Now I can't even start up qBittorent anymore. The UI just hangs at a white screen and my old laptop will slow down to a crawl.

Don't know what else to show other than this spiking that keeps rising the longer I leave it running.

[ned-martin]

Those aren't fastresume files and those logs do not belong to qBittorrent.

They are either fastresume files or torrents, I can't tell the difference, but when I open them in a text editor, they look the same as fastresume files to me, and contain data about the torrents I'm using. I have jackett installed and used as a search provider for qBittorrent, so maybe it creates them? Either way, not relevant to this issue I guess.

The logs I have no idea about - @xavier2k6 mentioned them so I put a screenshot to confirm that's what he's talking about. If they're not from qBittorent, kind of curious to know where they are from, but I guess not relevant to this issue then.

[xavier2k6]

@Phooh >If you want to try another 4.2.5 build, then you can try #12652 (comment)

This was built with latest libtorrent commit/Boost 1.73 & Qt 5.14.2 at time of compilation.

@ned-martin How is this build & the new settings working out for you now?

I think that having your pagefile disabled could potentially be a problem.

[Phooh]

@xavier2k6 I was able to see the UI but once I told it "Yes" to allow it to associate with torrent files and magnet links, it went back to freezing and having large spikes. So basically nothings changed on my end. I restarted the program and it went back to freezing at a white screen with no UI.

I then tried unzipping the build again to revert back so I can get the option to associate with torrent files and magnet links and this time clicked "No" and then it starting showing my torrents but then ended up freezing and spiking.

[xavier2k6]

@Phooh how many torrents do you have? & how long did you let the test build run before you closed it?

[ned-martin]

@ned-martin How is this build & the new settings working out for you now?

I think that having your pagefile disabled could potentially be a problem.

There has been no noticeable change using this build, or with those settings. Starting qBittorrent results in this (see below) for a considerable amount of time:

Once the "Commit size" column in Task Manager gets to around 8 GB, the UI will start working. My non-technical assumption is that it's finished "loading" all the torrents into RAM at that stage. However, whatever delay is causing it to do this so slowly is not apparent to me - there is no CPU, disk queue or network issues that I can see. As you can see from the below, there's no apparent performance bottlenecks:

Note that during this time while the UI is frozen, qBittorrent is still establishing large numbers of connections to remote addresses, so it appears to be doing something. My assumption is that the only part of the process that can be slow enough to cause this kind of extreme delay during start-up is network connections - it's doing something like waiting on connections to trackers to timeout for every torrent each time it loads the torrent into the UI, or something like that.

After several hours qBittorrent will have consumed all available memory, at which point either it will freeze or crash, or some other part of Windows will crash due to no memory, and the system will often become unstable and need to be rebooted.

I have enabled a pagefile. It has made no noticeable change other perhaps than making the UI a bit slower - I assume it's swapping stuff back to RAM from slower disk. But realistically, no noticeable change. It has definitely not corrected either of the two issues I'm facing - the half hour load of the UI, or the fact that it uses all available RAM in a matter of hours.

[ned-martin]

If I set qBittorrent's affinity to one core (or in this case, virtual CPU), it does use the entire CPU, so it is perhaps CPU bound. When not locked to a single CPU, it does seem to multithread across all 4 just fine without hitting any limits however. Resource Monitor says it's using about 25% CPU, which while perhaps excessive, should be fine.

qBittorrent bound to one CPU core:

qBittorrent allowed to use all cores:

[ned-martin]

It just finished "loading" or whatever it does, so I can confirm it took exactly 37 minutes from starting, to having a non-frozen UI, and is using about 6GB RAM (which will continually go up over time). Note that this is using the beta build linked above, but I don't think there's any difference between that build and the official 4.2.5 build in this regard.

[Phooh]

@xavier2k6 At least 30 something, some of them are magnet links and some are from a torrent files. As for how long I left the test build running, maybe like a couple of minutes. I try not to leave it running for too long due to this laptop I'm using isn't really that good. Its an HP with an Intel Pentium J3710 CPU with some generic Intel GPU, all running on 8GB of RAM.

I could try letting it run for longer but the problem when the test build or qBittorrent is running is, everything starts to slow down for me to where even the music I'm playing is sounding like its tearing up and that kind of worries me because usually if something like this happens, it means my laptop is about to crash.

[xavier2k6]

@ned-martin your network speeds seem a bit low for 10Gbe? (I could be mistaken or was very little network traffic when you took screenshots)

You seem to have edited previous posts with alot more info/screenshots too & unfortunately at this moment in time, I don't have the spare time to review/advise.

[ned-martin]

@ned-martin your network speeds seem a bit low for 10Gbe? (I could be mistaken or was very little network traffic when you took screenshots)

You seem to have edited previous posts with alot more info/screenshots too & unfortunately at this moment in time, I don't have the spare time to review/advise.

I imagine there's not much network activity going on, considering qBittorrent is non-responsive at the time.

The network is virtual 10GbE, it's the link between the network attached disk and the virtual machine, i.e. it's what qBittorrent will be using to store its downloads, using standard Windows file shares / SMB2/SMB3 (SMB1 is not enabled). The network to the internet is via a VPN at a much slower speed than 10Gb.

[bksinn78]

I have the same problem had the freezing during startup for a while but once it got going it was good
now after the initial freeze it works OK then it freezes up again on and off almost unusable I'm on windows server 2016 i have 7900ish torrents

[xavier2k6]

Try this build below:

Windows test build of 4.2.5 with listed libraries:

libtorrent-rasterbar | 1.2.6 +git 2622792
Qt                   | 5.14.2
OpenSSL              | 1.1.1g
zlib                 | 1.2.11
Boost                | 1.73

Download Link

[ghost]

^you cant run qbt from a terminal on windows. Asio debugging won’t help if u can’t print to console.

[xavier2k6]

^you cant run qbt from a terminal on windows. Asio debugging won’t help if u can’t print to console.

ah, well - that's fair enough, thanks for the calrification.

[jagannatharjun]

^you cant run qbt from a terminal on windows. Asio debugging won’t help if u can’t print to console

if you're building with qmake config like qmake "CONFIG += console"

if building with cmake change this to

qBittorrent/src/app/CMakeLists.txt

Line 93 in fd200ac

WIN32_EXECUTABLE True

False

[xavier2k6]

@jagannatharjun building with MSVC 2019......so cmake..... is command #12825 (comment) ok to use along with modifiying the Cmakelists file?

So building windows build "IS" possible with asio-debugging=on??

[jagannatharjun]

is command #12825 (comment) ok to use along with modifiying the Cmakelists file?

yes, I don't see it affecting anything, I use it all time when working with qbittorrent.

[xavier2k6]

is command #12825 (comment) ok to use along with modifiying the Cmakelists file?

yes, I don't see it affecting anything, I use it all time when working with qbittorrent.

Great, does it output to the logs or???

[jagannatharjun]

Great, does it output to the logs or???

I don't know about asio debugging stuff but with these changes it will print everything to console written to stdio and stderr

[xavier2k6]

@jagannatharjun ok, thanks - I'm putting any intended release of builds on hold as may have discovered a possible bug/regression of torrent rechecking loop with latest master qBittorrent & libtorrent. 👎

[arvidn]

@xavier2k6 oh, should I hold off libtorrent-1.2.8?

some comments on your command line:

include="C:\QBITTORRENT\boost_1_73_0" and library-path="C:\QBITTORRENT\boost_1_73_0\stage\lib". Neither of those should be necessary. Since you set BOOST_ROOT, boost should be built and linked as part of the b2 build, and it should figure out where the headers and the build output is. If the build fails if you remove those, something fishy is going on. Perhaps setting BOOST_ROOT like that isn't working in that case.

--toolset=msvc-14.2, I'm a bit surprised to see this work with the -- flag prefix. You can just say toolset=msvc-14.2, or actually, just msvc-14.2.

[ghost]

@arvidn
Read #13206 (comment) and onwards

[xavier2k6]

oh, should I hold off libtorrent-1.2.8?

^
&

Read #13206 (comment) and onwards

I need to do more testing but anything added into qbittorrent now e.g. (from 2.8.'20) will complete 100% & will not need to be rechecked after restart.

Any torrent 100% completed before now will need to be rechecked after every restart due to file size mismatch.
(it will always go back to 100% after rechecking or forced recheck but will still fail withfile size mismatch on startup)

so, seems any pre-existing completed torrents will be re-checked & if starting from scratch....won't need to be.

regarding the toolset commands -> they are mostly from the official way qBittorrent is compiled via the wiki page that @sledgehammer999 uses for official builds?!

[arvidn]

@xavier2k6 the only recent change in this logic (that I can think of) was related to the seed-mode flag. Are any of your torrents added in seed-mode?

[xavier2k6]

@xavier2k6 the only recent change in this logic (that I can think of) was related to the seed-mode flag. Are any of your torrents added in seed-mode?

they weren't added in seed mode, had been added as normal torrents back in 2019 - only downloaded/completed recently........so would only have been seeding for a small period of time then.

have force rechecked my torrents on a few occasions in the past without issue.......problem may actually be a qBittorrent commit in master anyway & not libtorrent, see #13206

In any case, I will take a bit of time & look in to this more on my end & open a new issue in the relevant faulting repo when necessary as to not divert away from the issue in this thread & #13206

[xavier2k6]

@arvidn feel free to release 1.2.8 if you want...

[ghost]

arvidn/libtorrent#4934

Please test it!

The delayed exit issue seem to have been fixed now for the initial queue case.

However I went ahead and added 6 working trackers to 1000 torrents, waited for them to finish the initial announce and then exited the client. It took around a minute to exit.

I don't know if that's too long, but some people might just force close the app when they're shutting down their PC.

So wouldn't it be better to exclude stop events from the queue to facilitate a faster client exit? As I suppose all of them will succeed/timeout within 5 seconds(stop_tracker_timeout) and the client will exit faster. Unless libtorrent still loops around all trackers and allowing each one 5 seconds to timeout before moving onto the next one. I think this logic should at least not apply to stop events.

The use cases are, announcing to all tiers/trackers in a tier with lots of torrents and lots of tracker.
Or when all of your announces succeed in the start announce, but your connection is lost when you're trying to shutdown the client. So all the announces will be waiting in queue for longer due to each taking at least 5 seconds to timeout.

[ghost]

I managed to reproduce the GUI locking issue on qBit 4.2.5 with 1000 torrents, 10 Non working trackers. The issue is 100% reproducible with every start of client.

I saw high CPU usage (25-30%) when the lock happened and memory kept going high like a memory leak. Memory usage returned to normal after the lock ended. Although It kept locking up randomly whenever I tried to click on a torrent.

I also tested a newer build which uses queue announce and I couldn't reproduce the issue. Maybe it's fixed now?

@xavier2k6

Can you provide a windows build with latest RC_1_2 and latest qBt master for @ned-martin to test and confirm?

[xavier2k6]

@xavier2k6

Can you provide a windows build with latest RC_1_2 and latest qBt master for @ned-martin to test and confirm?

Will do.

Although It kept locking up randomly whenever I tried to click on a torrent.

If that's with windows - there's been a freezing issue for the last 2 months or so........affecting steam too among other things....(network shares)

[xavier2k6]

@arvidn @An0n666 unfortuantely, I am still experiencing the recheck loop on completed torrents (had 4 completed, now at 7) ranging in size from 15+GiB to 80+GiB with:

qBittorrent master   | 4.3.0 +git 4d1c5a8
libtorrent-rasterbar | 1.2.8 +git 28f69cc
Qt                   | 5.15.0
OpenSSL              | 1.1.1g
zlib                 | 1.2.11
Boost                | 1.73

I uploaded the build previously to this thread but deleted the post as i didn't want it to have a adversely negative impact.

There's a regression somewhere that needs investigating more alright, but this isn't the issue thread to do so, will open a new issue & ping the two of you.

[glassez]

There's a regression somewhere that needs investigating more alright, but this isn't the issue thread to do so, will open a new issue & ping the two of you.

Since it's probably qBittorrent own issue please ping me too.

[ghost]

@xavier2k6
Now that the recheck loop issue has been resolved, can you please provide a test build?

[xavier2k6]

@ned-martin can you please try below:

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

qBittorrent master   | 4.3.0 +git 4d1c5a8
libtorrent-rasterbar | 1.2.8 +git 6b7b624
Qt                   | 5.15.0
OpenSSL              | 1.1.1g
zlib                 | 1.2.11
Boost                | 1.73

Download Link

[ned-martin]

@ned-martin can you please try below:

What specifically do you want me to try/test?

With "always announce to all trackers in a tier" disabled this version took 1m12s before the frozen white UI becomes responsive and the program works as expected. This is about the same as the previous version, maybe a bit faster but it varied a bit between tests in the past, so I'd say overall no improvement here.

Always announce to all trackers in a tier = disabled
(N) 2020-08-07T17:42:17 - qBittorrent v4.3.0alpha1 started
(N) 2020-08-07T17:43:29 - <last torrent> restored. 
1 min 12 sec

With "always announce to all trackers in a tier" enabled this version took 2m56s before the frozen white UI is replaced with the proper UI, which is a lot faster, however the UI then remains mostly non-responsive for another few minutes - total 6m4s until the program is responsive and working as expected (approx., there's nothing logged when it becomes responsive, so I'm testing by moving the mouse around waiting until the hover effect starts working and I can click on or select anything). This is similar to starting the previous version with all torrents paused, then un-pausing them. This is a better UI experience as at least it's apparent something is happening (it's not just a white screen), and I think it's a bit faster overall than the previous version (I was getting 8 minutes frozen with it, but it did vary a bit) but it's still not a usable program for over 6 minutes.

Always announce to all trackers in a tier = enabled
(N) 2020-08-07T17:52:56 - qBittorrent v4.3.0alpha1 started
(N) 2020-08-07T17:55:52 - <last torrent> restored.
2 min 56 sec - UI now drawn

UI remains drawn but largely frozen / cannot interact until 5:59
6 min 4 seconds

CPU usage remains high after this, with occasional UI freeze-ups. It's been 20 minutes now and CPU usage 
does not seem to have decreased yet. I'll keep an eye on it.

Exiting the program took approx. 3 minutes. This is still very slow, but is a huge improvement (the program did not cleanly exit after 12 hours of waiting with the previous version)

[ghost]

There’s usually a lot of alerts generated at startup.
If you couple that with lots of tracker failure alerts generated from each endpoint, it can actually cause locking issues due to qBt processing all those alerts.

The improvement you’re seeing is basically due to queued announces..less alerts are being generated at a time.

If qBt exposed the queue limits in its settings you could try with even lower limits.

You can also specify your network interface in qBt settings instead of listening on all interfaces. This will reduce the number of alerts generated equivalent to 4.1.x series.

[xavier2k6]

You can also specify your network interface in qBt settings instead of listening on all interfaces. This will reduce the number of alerts generated equivalent to 4.1.x series.

@ned-martin This would be a good option to try out if you can/haven't it already set.

[ned-martin]

You can also specify your network interface in qBt settings instead of listening on all interfaces. This will reduce the number of alerts generated equivalent to 4.1.x series.

After running for around 4 days, the memory usage was still below 1GB. This is a huge improvement.

I then changed it to listen on only the VPN interface.

It took 2m50s to exit.

It took 2m41s to start up (go from white frozen UI to responsive UI)

It's then high-cpu-usage and the UI is "choppy" - however it's usable - the freeze-ups are less than a second long, and seem to be less frequent than before, and after a few minutes the CPU usage is still high but the UI seems to be fine.

Note that I have nothing actually downloading at the moment, so I'm unsure if that makes a difference to the tests. Torrents are seeding however.

[FranciscoPombal]

@ned-martin Thank you for your feedback and your patience. I created #13304 as a follow-up. 3 minutes is clearly still too much for startup, and the UI shouldn't freeze up like that.