Freezing & Not Responding

[MrxHellsing]

qBittorrent & operating system versions

qBittorrent: 4.4.4 x64
Operating System: Windows 10 Pro 21H2 (OS Build 19044.1889) x64 (10.0.19044)
Using qBittorrent from the official site.

What is the problem?

I was running v4.3.6, even though that was a little bit unstable compared to v4.2.1. But only was forced to upgrade because of some private tracker sites enforcing upgrade rules. I went through multiple versions after v4.2.1 and back then v4.3.6 wasn't available so had to downgrade back to v4.2.1 for the time being. Then again updated after months, and found v4.3.6 stable enough. The issue with qbittorrent is it feels like the app is pulling a 50 ton weight every time I start it or even when it is running as well. Even in the versions that I found stable and did not go all freeze up and non-responsive, opening the app, pausing or starting the torrent seemed like the app was fighting for its life. It is that sluggish. Currently, I had about 54-60 torrents running in qbittorrent and it was still behaving as I stated. This constant issue of not responding and freezing up is really a hassle. Yesterday, I updated to v4.4.4 thinking maybe after so many versions this might have been fixed but the same issue all over again, I waited for a good amount of time but the app only gave me a white screen. I tried a few versions below like v4.4.3.1, and a few ones below that but the same issue. I even posted my experience on qbforum to check if I was the only one facing this issue and one user confirmed that he/she was facing the same issue. Another user posted about the same experience and I commented on that as well.
.
As for v4.2.1 & v4.3.6, after adding about 30 torrents (IIRC) , when the app is minimized, if I click on the icon on the taskbar and try to maximize it, it will stay non-responsive for about 30-50 seconds and then it will return to normal state.
.
This freezing issue needs a permanent fix. Because of this freezing issue I am always concerned about whether or not I should update the app.

Steps to reproduce

1. Start qBittorrent [For the new updated version and some of the ones that I mentioned]
2. For previous versions that I found stable which is v4.2.1 & v4.3.6 (afaik), add about 30-60 torrents and try to maximize it, it will stay non-responsive for about 30s - 2/3 mins and return to normal. This number may vary, I am including what I observed.

Additional context

https://qbforums.shiki.hu/viewtopic.php?p=34251#p34251
https://qbforums.shiki.hu/viewtopic.php?p=34348#p34348

Log(s) & preferences file(s)

Preference folder had bunch of stuff like shown in the image,

.
so attaching the .ini file thinking this maybe important and log file. .ini file isn't supported so copy pasting what was inside, although redacted some info from save directory, save directory history and redacted some torrent name from log file. Other than that everything is untouched.
.

Click to see config

[Application]
FileLogger\DeleteOld=true
FileLogger\Path=D:/Software Installed/qBittorrent/Logs
FileLogger\Backup=true
FileLogger\AgeType=1
FileLogger\MaxSizeBytes=66560
FileLogger\Age=1
FileLogger\Enabled=true

[TrackerEntriesDialog]
Dimension=@SiZe(478 472)
Size=@SiZe(506 500)

[Meta]
MigrationVersion=3

[Preferences]
MailNotification\enabled=false
Advanced\EnableIconsInMenus=true
Downloads\SavePath=D:/Download/Video/Stars/
MailNotification\username=
State\size=@SiZe(819 558)
Downloads\FinishedTorrentExportDir=D:/Doc/Torrent/Finished Torrents
MailNotification\sender=[email protected]
MailNotification\smtp_server=smtp.changeme.com
General\MinimizeToTray=false
General\CloseToTrayNotified=true
Scheduler\end_time=@variant(\0\0\0\xf\x4J\xa2\0)
General\CustomUIThemePath=D:/Software/Portable Apps/Torrent App/qBittorrentDarktheme-Rev10/ICEBERG.qbtheme
Connection\ResolvePeerCountries=true
Queueing\QueueingEnabled=false
Advanced\RecheckOnCompletion=false
WebUI\Enabled=false
Win32\NeverCheckFileAssocation=true
Bittorrent\MaxUploadsPerTorrent=50
Connection\ResolvePeerHostNames=false
Queueing\MaxActiveUploads=400
Downloads\TorrentExportDir=D:/Doc/Torrent/Temp
Downloads\DblClOnTorDl=0
Queueing\MaxActiveDownloads=400
Connection\PortRangeMin=56727
MailNotification\req_ssl=false
Advanced\AnnounceToAllTrackers=true
General\NoSplashScreen=true
Advanced\confirmRemoveAllTags=true
Downloads\NewAdditionDialogFront=true
General\AlternatingRowColors=true
Bittorrent\MaxUploads=100
General\SystrayEnabled=true
Connection\GlobalUPLimitAlt=0
Connection\GlobalDLLimit=0
Downloads\DblClOnTorFn=1
Connection\GlobalDLLimitAlt=0
Advanced\updateCheck=false
Queueing\MaxActiveTorrents=400
General\Locale=en
Downloads\DiskWriteCacheSize=4096
General\CloseToTray=false
Bittorrent\MaxConnecsPerTorrent=2000
General\StartMinimized=false
Advanced\TrayIconStyle=Normal
Advanced\confirmTorrentRecheck=true
Connection\GlobalUPLimit=0
General\HideZeroComboValues=0
General\UseCustomUITheme=true
Scheduler\start_time=@variant(\0\0\0\xf\x1\xb7t\0)
State\hSplitterSizes=124, 668
MailNotification\password=
Advanced\DisableRecursiveDownload=false
General\PreventFromSuspendWhenSeeding=true
Downloads\PreAllocation=true
General\PreventFromSuspendWhenDownloading=true
MailNotification\email=
MailNotification\req_auth=false
Advanced\confirmTorrentDeletion=true
Scheduler\days=EveryDay
General\ExitConfirm=true
Bittorrent\MaxConnecs=2000
Downloads\NewAdditionDialog=true
Search\SearchEnabled=true
General\HideZeroValues=false
Advanced\AnonymousMode=false
Advanced\trackerPort=9000

[SpeedWidget]
graph_enable_2=false
graph_enable_0=true
graph_enable_3=false
graph_enable_5=false
graph_enable_7=false
graph_enable_6=false
Enabled=true
period=1
graph_enable_4=false
graph_enable_1=true
graph_enable_9=false
graph_enable_8=false

[BitTorrent]
Session\AnnounceToAllTrackers=true
Session\AlternativeGlobalDLSpeedLimit=0
Session\GlobalDLSpeedLimit=0
Session\MaxUploadsPerTorrent=50
Session\MaxActiveDownloads=400
Session\AnonymousModeEnabled=false
Session\GlobalUPSpeedLimit=0
Session\TorrentExportDirectory=D:/Doc/Torrent/Temp
Session\DiskCacheSize=4096
Session\SendBufferLowWatermark=1024
Session\CheckingMemUsageSize=1024
Session\AlternativeGlobalUPSpeedLimit=0
Session\Preallocation=true
Session\MaxConnectionsPerTorrent=2000
Session\FilePoolSize=500
Session\MaxConnections=2000
Session\SendBufferWatermark=3072
Session\FinishedTorrentExportDirectory=D:/Doc/Torrent/Finished Torrents
Session\MaxActiveTorrents=400
Session\QueueingSystemEnabled=false
Session\AsyncIOThreadsCount=24
Session\MaxActiveUploads=400
Session\MaxUploads=100
Session\Port=56727
Session\DefaultSavePath=D:/Download/

[Core]
AutoDeleteAddedTorrentFile=Never

[AddNewTorrentDialog]
RememberLastSavePath=true
SavePathHistory=D:/ANIME/Wotakoi - Love Is Hard for Otaku (2018-19)
TopLevel=true
qt5\treeHeaderState=@bytearray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x6\x34\0\0\0\x3\0\0\0\x2\0\0\0\x64\0\0\0\x5\0\0\0\x64\0\0\0\x4\0\0\0\x64\0\0\x2\xef\0\0\0\x6\x1\x1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\x6\0\0\x2\x11\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0z\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\x3\xe8\0\xff\xff\xff\xff)
TreeHeaderState=@bytearray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x6\x34\0\0\0\x3\0\0\0\x2\0\0\0\x64\0\0\0\x5\0\0\0\x64\0\0\0\x4\0\0\0\x64\0\0\x2\xef\0\0\0\x6\x1\x1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\x6\0\0\x2\x11\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0z\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\x3\xe8\0\xff\xff\xff\xff)
SplitterState=@bytearray(\0\0\0\xff\0\0\0\x1\0\0\0\x2\0\0\x1N\0\0\x1\0\0\xff\xff\xff\xff\x1\0\0\0\x1\0)
Enabled=true
DialogSize=@SiZe(1077 586)

[DownloadFromURLDialog]
Size=@SiZe(501 220)

[AutoRun]
program=
ConsoleEnabled=false
enabled=false

[TorrentProperties]
SplitterSizes="288,191"
Visible=true
Trackers\qt5\TrackerListState=@bytearray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x6\xbb\0\0\0\b\x1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\b\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\x1\xe4\0\0\0\x1\0\0\0\0\0\0\0\xa2\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\x2\x41\0\0\0\x1\0\0\0\0\0\0\x3\xe8\0\0\0\0\x64)
qt5\FilesListState="@bytearray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x5\xce\0\0\0\x6\x1\x1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\x6\0\0\x3\xe\0\0\0\x1\0\0\0\0\0\0\0O\0\0\0\x1\0\0\0\0\0\0\x1;\0\0\0\x1\0\0\0\0\0\0\0n\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\x3\xe8\0\xff\xff\xff\xff)"
Peers\qt5\PeerListState="@bytearray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\x1\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\xe\0 \0\0\0\x1\0\0\0\r\0\0\0\x64\0\0\x6\xe9\0\0\0\xe\x1\x1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\xe\0\0\0\x64\0\0\0\x1\0\0\0\0\0\0\0\xe2\0\0\0\x1\0\0\0\0\0\0\0\x31\0\0\0\x1\0\0\0\0\0\0\0Q\0\0\0\x1\0\0\0\0\0\0\0\x43\0\0\0\x1\0\0\0\0\0\0\0\xc8\0\0\0\x1\0\0\0\0\0\0\0;\0\0\0\x1\0\0\0\0\0\0\0L\0\0\0\x1\0\0\0\0\0\0\0\x46\0\0\0\x1\0\0\0\0\0\0\0P\0\0\0\x1\0\0\0\0\0\0\0\x41\0\0\0\x1\0\0\0\0\0\0\0?\0\0\0\x1\0\0\0\0\0\0\x2y\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\x3\xe8\0\xff\xff\xff\xff)"
CurrentTab=2

[GUI]
Notifications\Enabled=true
DownloadTrackerFavicon=false
Notifications\TorrentAdded=false
Log\Enabled=false

[MainWindow]
qt5\vsplitterState=@bytearray(\0\0\0\xff\0\0\0\x1\0\0\0\x2\0\0\0\xa5\0\0\x6\xc4\x1\xff\xff\xff\xff\x1\0\0\0\x1\0)
geometry=@bytearray(\x1\xd9\xd0\xcb\0\x3\0\0\xff\xff\xff\xff\xff\xff\xff\xf8\0\0\a\x80\0\0\x4\x10\0\0\x2\xef\0\0\x1K\0\0\x6\x80\0\0\x3}\0\0\0\0\x2\0\0\0\a\x80\0\0\0\0\0\0\0\x17\0\0\a\x7f\0\0\x4\xf)

[TransferListFilters]
trackerFilterState=false
CategoryFilterState=true
TagFilterState=false
statusFilterState=true
selectedFilterIndex=1

[OptionsDialog]
Size=@SiZe(1173 591)
HorizontalSplitterSizes=181, 965

[TorrentAdditionDlg]
save_path_history=D:/Movie/HINDI/Jodhaa Akbar (2008), D:/ANIME/Wotakoi - Love Is Hard for Otaku (2018-19)

[ShutdownConfirmDlg]
DontConfirmAutoExit=false

[RSS]
AutoDownloader\DownloadRepacks=true
AutoDownloader\SmartEpisodeFilter=s(\d+)e(\d+), (\d+)x(\d+), "(\d{4}[.\-]\d{1,2}[.\-]\d{1,2})", "(\d{1,2}[.\-]\d{1,2}[.\-]\d{4})"

[LegalNotice]
Accepted=true

[TransferList]
qt5\HeaderState="@bytearray(\0\0\0\xff\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\x1\x1\0\0\0\0\0\0\0\0\0\0\0\x1f\t\xc0\xff?\0\0\0\x12\0\0\0\x12\0\0\0\x64\0\0\0\x13\0\0\0\x64\0\0\0\x10\0\0\0\x64\0\0\0\x11\0\0\0\x64\0\0\0\x16\0\0\0\x64\0\0\0\x17\0\0\0\x64\0\0\0\x14\0\0\0\x64\0\0\0\x15\0\0\0\x64\0\0\0\x1a\0\0\0\x64\0\0\0\x1b\0\0\0\x64\0\0\0\x18\0\0\0\x64\0\0\0\x19\0\0\0\x64\0\0\0\x1c\0\0\0\x64\0\0\0\x1d\0\0\0\x64\0\0\0\x3\0\0\0\x64\0\0\0\0\0\0\0'\0\0\0\xe\0\0\0\x64\0\0\0\xf\0\0\0\x64\0\0\x6\x99\0\0\0\x1f\x1\x1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\x64\xff\xff\xff\xff\0\0\0\x81\0\0\0\0\0\0\0\x1f\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\x2\x44\0\0\0\x1\0\0\0\0\0\0\0\x42\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\x1N\0\0\0\x1\0\0\0\0\0\0\0\x86\0\0\0\x1\0\0\0\0\0\0\0H\0\0\0\x1\0\0\0\0\0\0\0<\0\0\0\x1\0\0\0\0\0\0\0Y\0\0\0\x1\0\0\0\0\0\0\0O\0\0\0\x1\0\0\0\0\0\0\0?\0\0\0\x1\0\0\0\0\0\0\0)\0\0\0\x1\0\0\0\0\0\0\0;\0\0\0\x1\0\0\0\0\0\0\0(\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0\0\0\0\0\x1\0\0\0\0\0\0\0H\0\0\0\x1\0\0\0\0\0\0\x3\xe8\0\0\0\0\x64)"

[TorrentOptionsDialog]
Size=@SiZe(390 450)

[General]
MainWindowLastDir=D:/Doc/Torrent/TBD

.

qbittorrent.log

[ghost]

Does your problem get fixed if you use the RC_1_2 build?
Here's the link to RC_1_2 build https://www.fosshub.com/qBittorrent.html?dwl=qbittorrent_4.4.4_RC_1_2_qt5_x64_setup.exe

[tristanleboss]

@MrxHellsing If you can, it would be interesting to know the real memory of your qbittorrent.exe process when the GUI hangs (the value from the task manager is not the correct one). To do so, use the freeware "Process Hacker" ( https://processhacker.sourceforge.io/ ), find your "qbittorrent.exe" in the list (you can use the search filter at the top right of the window), right click on it and click the bold "Properties" item. On the "Performance" tab, you will get the "Private Bytes" value which is the one that may be of interest. Also, go the the "Statistics" tab, click the "Details" button in the "Other" group and get the "File" handles count which may help us pinpoint the problem.

Another value to collect at the time of freeze is the usage percentage of your pagination file drive (should be the drive where windows is installed). To get this information, go to the "Performance" tab of the Windows task manager and look on the left for your drive: the percentage is there.

Also please tells us the amount of physical memory in your PC.

[tristanleboss]

@MrxHellsing and the others with freezes. You should try this special version made by a contributor and report if it works. It uses the new libtorrent v2 but with the old way of accessing files: #17545 (comment)

[MrxHellsing]

Does your problem get fixed if you use the RC_1_2 build? Here's the link to RC_1_2 build https://www.fosshub.com/qBittorrent.html?dwl=qbittorrent_4.4.4_RC_1_2_qt5_x64_setup.exe

Tried it. However, this time it is a little bit different. It starts and gives me a white screen for about 3 mins, then the image below comes,

.
it is still in a not responding state, but I can see the torrents now, and after waiting for a total of about 10 mins, it became stable again

which is way later than the stable ones I have used so far, which are v4.2.1 & v4.3.6. Also, just trying to pause or resume torrents sends the app into a freezing state again.

Needless to say, I'll be downgrading to earlier versions. I tried 4.3.3, my friend suggested it as he used it. But for me it didn't work, so will install 4.3.6 again.
.
@tristanleboss , I went through and read all the comments in the thread #17545 & #17605, including your observations and franciscofjs pretty much confirmed your tests I guess. Also, because of my busy schedule, I won't be able to confirm your theory myself by testing, so I apologize for that. However, I will state my config though maybe it will be useful,
CPU: AMD Ryzen 7 3700X
RAM: 16GB (3200MHz) x 2 = 32 GB. Based on the comments on the mentioned issues, that should suffice.

[tristanleboss]

Thanks guys. I'm done with this problem for now. I stick with 4.4.4 RC_1_2 which works amazingly well (download speed is crazy, responsiveness is almost perfect, ...). I will probably try the 4.5.0 test version at some point.

For me, the memory mapped files thing is not (yet) mature enough. It was probably a good idea on paper but, by reading the issues in libtorrent tracker, it seems to be hard to tweak and dependant on the OS implementation. When you change something, it has to benefit everyone: if it just works for a few use cases, it's not a good change. As I said earlier, I prefer a program using 1.8gb of memory than one hogging 8gb. Memory is not an unlimited ressource and if all programs start do go this way, we will need 512gb in our computers.

It's a good thing to try new things and you can't always be sure of the outcome without trying it in the first place. And I do understand they are working on it and doing their best so maybe, at some point, it will be worth it but not now.

[MrxHellsing]

@summerqb I tried the 4.5.0 Alpha, the difference that I found between Alpha and v4.3.6 is, v4.3.6 starts and takes a bit of time for GUI to be responsive and simple tasks like maximizing the window, pausing or resuming torrents, adding trackers- these doesn't make it that unresponsive. Alpha version starts really fast and instantly displays GUI, torrent list comparing to v4.3.6's speed, but then stays unresponsive for a very long time and simple tasks make it unresponsive. In short, Alpha starts and loads faster than v4.3.6 and possibly other versions but everything else is sluggish. v4.3.6 starts late and takes time to be responsive but everything else is a bit more stable than Alpha.

[ghost]

@MrxHellsing I noticed some supicious values in your configuration files. Could you test latest qBt master built against libtorrent 1.2.17 from github actions? Here's the link to that-> https://github.com/qbittorrent/qBittorrent/suites/8062802978/artifacts/347287971

I would also request you to take a backup of your configuration file and then delete/rename(while qBt is not running) it to test with a fresh config.

[tristanleboss]

@summerqb I tried the version. There is a nice loader. It hanged maybe a minute when it reached 100%. Then the GUI showed up but froze.
But, I discovered something really interesting. There was a lot of "Successfully listening" and "Detected external IP" lines in the log file. It was strange to me because I only have one network adapter enabled on my computer and qBt is set to only use this one (Session\Interface).
I discovered these addresses were listed in the details of my network adapter as "Temporary IPV6 address" and also as "IPv6 default gateway".

To find out if it's my root cause of the freeze. I would like to try to limit it to listening on only one IP. How to do it? There is an "Optional IP address to bind to" setting but no explanation on what it does in the documentation https://github.com/qbittorrent/qBittorrent/wiki/Explanation-of-Options-in-qBittorrent#Advanced ("Optional IP address to bind to — (default: All addresses) TBA").

[ghost]

You can select a specific IP address to listen to from that settings. You can set it to all IPv4 addresses to avoid listening on IPv6.

[tristanleboss]

@summerqb Oh, my god. That's it. That's the reason why my qBt RC_1_2 freeze to death at startup sometime (because sometime I restart it when my computer has been on for a few days already and getting a lot of those temporary IPv6 addresses) and slowdown to a crawl after a few days of use (because I get a new temporary IPv6 address everyday).

I set it to use IPv4 addresses only (I have only one) and it doesn't freeze. But, why is it listening at all those addresses? And why listening to the IPv6 gateway address? It's probably something specific to IPv6, I imagine.

When I start my computer, I have 1 IPv6 and either 1 or 0 of those temporary IPv6 address (I just have one right now after disabling/enabling my netword adapter). From my qBt log files, it seems I get one more temporary IPv6 addresses every day arround noon (I get two "Successfully listening" lines every day at noon). I am at one of the top 3 French ISP.

It explains why when I started it 5 days ago, it worked like a charm: I restarted my computer just before. It only used 1.38gb of memory at that time (like now). But, when I killed it on sunday afer 6 days of use, the memory was reaching 5gb... and was growing everyday. Does the number of listening IPs impact memory?

[ghost]

@summerqb Oh, my god. That's it. That's the reason why my qBt RC_1_2 freeze to death at startup sometime (because sometime I restart it when my computer has been on for a few days already and getting a lot of those temporary IPv6 addresses) and slowdown to a crawl after a few days of use (because I get a new temporary IPv6 address everyday).

I set it to use IPv4 addresses only (I have only one) and it doesn't freeze. But, why is it listening at all those addresses? And why listening to the IPv6 gateway address? It's probably something specific to IPv6, I imagine.

When I start my computer, I have 1 IPv6 and either 1 or 0 of those temporary IPv6 address (I just have one right now after disabling/enabling my netword adapter). From my qBt log files, it seems I get one more temporary IPv6 addresses every day arround noon (I get two "Successfully listening" lines every day at noon). I am at one of the top 3 French ISP.

It explains why when I started it 5 days ago, it worked like a charm: I restarted my computer just before. It only used 1.38gb of memory at that time (like now). But, when I killed it on sunday afer 6 days of use, the memory was reaching 5gb... and was growing everyday. Does the number of listening IPs impact memory?

@arvidn should libtorrent listen on all temporary IPv6 addresses? Afaik the aim of temporary address is to provide privacy? So I don’t understand the logic to listen on all of them and result in performance degradation as well as privacy issues.

[lucasmz-dev]

If you have a bunch of temporary addresses, usually for me just taking off and putting the Ethernet port fixed it.
My router / switch has a problem on where the router restarts but the computer keeps thinking its connected because my switch stays turned on. As a result, IPv6 breaks. It keeps using the past IP which isn't valid anymore until I disconnect Ethernet and put it back on again.

Trust me you do not wanna disable IPv6. If you can, just make sure your router doesn't auto-restart, and you should be fine. AFAIK, even though temporary addresses switch out everyday, I've left my computer turned on for days & days and it would always switch and not even be showing up anymore when I do ipconfig.

However, qbittorrent does not support temporary addresses properly, which may be the reason behind these crashes.

Anyhow, I ask that you please don't stop announcing on IPv6. People are on CGNAT IPv4 now a days and can't connect to everyone properly. You will get more seeds with IPv6 as those users on CGNAT can now connect to you.

By the way, it's really weird that sometimes you don't get a temporary IPv6 address. Are you on DHCPv6? Or SLAAC? (Usually you can tell by checking if the second part of the address uses 4, or just 1 segment.) I believe your IPv6 is unproperly set up, probably should look into that.

@summerqb @tristanleboss

[tristanleboss]

At least, I'm happy because, for me, all qBt versions were freezing at some point. So, at least, I think I know why even RC_1_2 was sometime freezing hard.

I would love to keep using IPv6 but qBt is currently unable to deal with my IPv6 setup. I will see if I can disable/enable my adapter everyday. But, even if I do that, that's 3 IPv6 to listen (the fixed one, the temporary one and the gateway) and it seems to be too much for my qBt (It's probably related to some user setup like the number of torrents in each state). I just need to find the time to retry RC_2_0 with the actual settings of only using the unique IPv4 address: just to see if at least it works.

If it does it for me, there is probably more people with the same issue and unaware of it. It's probably worth it to take this number of listening IPs into consideration. Especially, if it can imply high memory usage. Because, if you combine this factor with the higher memory usage of libtorrent RC_2_0, you can end up in a pretty bad situation.

My router is the one made and provided by my ISP and my Windows network settings are the default ones. From what I found on forums, with my ISP, we get a temporary IPv6 every 24 hours.

[MrxHellsing]

@MrxHellsing I noticed some supicious values in your configuration files. Could you test latest qBt master built against libtorrent 1.2.17 from github actions? Here's the link to that-> https://github.com/qbittorrent/qBittorrent/suites/8062802978/artifacts/347287971

I would also request you to take a backup of your configuration file and then delete/rename(while qBt is not running) it to test with a fresh config.

@summerqb I tried what you suggested and took backup of my config files. I'm seeing huge improvements. The response has gotten almost close to utorrent's speed. The freezing is there but the duration has reduced greatly. The starting speed is same as before, resuming the torrents make the GUI freeze for about 5-9 seconds, pausing has the same freeze duration. Force announcing trackers cause the GUI freeze for about 5-7 seconds. I'd say a 4 times improvement over 4.3.6. You mentioned about suspicious values, if it is possible, an elaboration would be appreciated. Exactly what caused this in my case, which settings that I had changed caused this etc.

[arvidn]

@tristanleboss
I'm really curious to understand what's causing the freezes. I suppose your operating system is listing all interfaces/IP addresses you've had since startup. I take it this is specific to IPv6, since normally IPs on local networks don't change regularly.

So, your external IPv6 address is changed and libtorrent doesn't notice? Or does it notice and adds the new IP to the list of existing IPs it's already listening on?

You say you're configured to only listen to one interface, I suppose this interface has multiple IPs, or there's some issue where it changing IP is Interpreted as it gaining an additional IP.

Does ifconfig look normal to you, under these circumstances?

Or does it list a lot of IPs or a lot of interfaces?

[MrxHellsing]

@MrxHellsing I noticed some supicious values in your configuration files. Could you test latest qBt master built against libtorrent 1.2.17 from github actions? Here's the link to that-> https://github.com/qbittorrent/qBittorrent/suites/8062802978/artifacts/347287971
I would also request you to take a backup of your configuration file and then delete/rename(while qBt is not running) it to test with a fresh config.

@summerqb I tried what you suggested and took backup of my config files. I'm seeing huge improvements. The response has gotten almost close to utorrent's speed. The freezing is there but the duration has reduced greatly. The starting speed is same as before, resuming the torrents make the GUI freeze for about 5-9 seconds, pausing has the same freeze duration. Force announcing trackers cause the GUI freeze for about 5-7 seconds. I'd say a 4 times improvement over 4.3.6. You mentioned about suspicious values, if it is possible, an elaboration would be appreciated. Exactly what caused this in my case, which settings that I had changed caused this etc.

@summerqb So, I set my config to how it was before in previous versions in this new one and the performance seems to be the same, with no downgrades. From this, I can say that there was seemingly nothing wrong with my config, at least from my tests, I can conclude this. This new version that you sent me through the link had something modified or changed which made qbittorrent perform better this time. I'll be sticking to this for now, it is better than v4.3.6.

[tristanleboss]

Update after few days. For me, the problem is indeed the number of listened IPs. The "Optional IP address to bind to" setting is not usefull because once I get a new temporary IPv6 address, qBittorrent detects it and start listening to it... even if I choose my fixed IPv6 address in the select dropdown. It seems the setting just works at startup.

Because of this bug or feature, there is unfortunately no real solution. Once I got a new temporary IPv6, I disable my network adapter to bring back the GUI and exit qBt. Then, I re-enable the adapter and restarts qBt.

I used a program called WinApiOverride to find out what qBt was doing when the GUI is frozen and, to no surprise, what it does is announcing to trackers. Once this step is done, the GUI comes back to life. It explains why it freezes at startup and when it starts listening to a new IP.

[MrxHellsing]

@tristanleboss the version that was suggested to me was 4.5.0alpha1. I noticed these qt6 files

Personally I don't know what qt6 is and noticed some installers in fosshub that had qt5 and qt6 in their names. If you know or can point me to any wiki on info where I could learn about this that would be great.

[arvidn]

@tristanleboss

For me, the problem is indeed the number of listened IPs. The "Optional IP address to bind to" setting is not usefull because once I get a new temporary IPv6 address, qBittorrent detects it and start listening to it... even if I choose my fixed IPv6 address in the select dropdown. It seems the setting just works at startup.

do you see any messages in the log about re-opening listen sockets or detecting a new external IP?

[tristanleboss]

@arvidn Yes, I do. And seconds later, qBt is frozen for hours.

(I) 2022-09-02T19:53:03 - Successfully listening on IP: (temporary ipv6 address), port: TCP/39621
(I) 2022-09-02T19:53:03 - Successfully listening on IP: (temporary ipv6 address), port: UDP/39621
(I) 2022-09-02T19:54:37 - Detected external IP: (temporary ipv6 address)
(N) 2022-09-02T22:52:56 - Enqueued to move ..."

I have a lot of torrents (and a lof of "Downloading metadata..." torrents). I discovered each tracker is on different level and the default of qBt is to connect to tracker of every levels but to not connect to each trackers of each levels. So, I created a program to edit the fastresume files and put all trackers on the same level (0) but it was still frozen at startup doing lot of announce even if it connected to only 3/4 trackers (out of 20, always the same ones) for each torrent.

I don't understand why it freeze. Especially, since the setting "Reannounce to all trackers when IP or port change" is unchecked. So nothing should happen. And the new IPv6 is just a temporary one: the main IPv6 never change.

[tristanleboss]

@MrxHellsing Qt is the library used to build the GUI. Qt6 is obviously the latest version.
I have no idea if the freezing problem is Qt related. Especially, it's hard to know if the freezing problem have the same root causes for each of us.

[ghost]

@tristanleboss in 4.5.0 it will not reannounce to trackers on interface change notifications.
So please try 4.5.0 alpha and see if you still get freezes when qBt listens on a new IPv6 address.
Also 4.5.0 tries to avoid blocking calls when updating tracker statuses. So that should alleiviate some of the problems.

[tristanleboss]

@summerqb Yes, I will.
@summerqb @arvidn So the $1k question, why does the announce code freezes qBittorrent? I imagine it should be a background task using aynchronous functions.
Would be interesting to craft a fastresume file with lot of trackers and lot of levels and see what happens.

Indeed, my previous test is successfull with 4.4.5 RC_1_2. Granted, it's not the solution but, at least, it helps find the root cause.

I parsed my fastresume files and computed some stats:

• Before, I had 105,398 tracker(s) (351 distinct trackers including 71 tracker(s) whose domain names are not resolving at all) on 48,980 level(s) for 3,944 non-paused torrent(s). There was also 2 empty trackers ("0:" in bencoded fastresume file) and 2 erroneous URL "udp4tracker.openbittorrent.com:80/announce" and "- Tracker .+" (2D 20 54 72 61 63 6B 65 72 20 2E 2B).

• Now, I have 78,880 tracker(s) (20 distinct trackers) on 3,944 level(s) for 3,944 non-paused torrent(s). (1 torrent = 1 level = 20 trackers on this unique level)

Of course, with this setup, the GUI didn't freeze when the new temporary ipv6 address was detected and qBt started way faster.

It can be painfull to find the root cause of a problem:

1. I went here because 4.4.3 RC_2_0 was burning huge amount of memory and qBt startup was painfull and froze a lot after a while.

2. Using RC_1_2, the memory usage was under control but loading was still super slow and freezes still happened after a few days. The huge memory usage was due to memory mapped files.

3. I discovered this ipv6 temporary addresses thing that added up days after days and rendered qBt irresponsive after a few days.

4. Finally, I discovered the real culprit is the trackers announcing system.

[ghost]

The "Optional IP address to bind to" setting is not usefull because once I get a new temporary IPv6 address, qBittorrent detects it and start listening to it... even if I choose my fixed IPv6 address in the select dropdown. It seems the setting just works at startup.

If you select a specific IP then libtorrent should not automatically update the IP to the new one. This is probably a bug on the libtorrent side since qBt only configures the interface once.

[arvidn]

libtorrent subscribes to updates to the network interfaces using a NETLINK_ROUTE socket. libtorrent has (until a day ago) assumed that it only receives updates when something actually changes. But I've experienced a VPN provider that seem to be producing updates quite regularly.

libtorrent does not look carefully at these notifications, but just close and re-open all listen sockets whenever they are received.

This was addressed in arvidn/libtorrent#7058 where all notifications are ignored unless the IP address of an interface changes (or a new interface appears).

I think there's a good chance this fixes the underlying cause of libtorrent closing and reopening listen sockets.

[arvidn]

So the $1k question, why does the announce code freezes qBittorrent? I imagine it should be a background task using aynchronous functions.
Would be interesting to craft a fastresume file with lot of trackers and lot of levels and see what happens.

If qBT freezes, it's most likely stuck in a blocking call into libtorrent, and libtorrent's main thread is very busy. Perhaps there are a large number of blocking calls happening one after the other.

There's a chance qbt is requesting information about a lot of trackers in blocking calls.

libtorrent has had issues when it comes to announcing to a very large number of trackers (where it would initiate them all in parallel). It's been quite a while since this was improved by queuing announces though.

[gothicserpent]

I have quite a few trackers for about 4k torrents, and I personally only experience minor freezes when qBit first launches which i understand and accept and when I try to right click a listing and "set location..." to move folders. Other than this the freezes never happens for me. The only other potential delays might be when the torrents have to be rechecked.

I think that some of this might be related to local issues people might be having with their internet, such as router related or VPN related perhaps, something related to their system.

Of course, if the issue is in fact related to blocking calls then perhaps it can be tested, but I personally haven't experienced these symptoms with libtorrent 2.x

I do hope that libtorrent 2.x can be implemented again in the base version of qbit at some point (i use chocolatey to update qbit and it always downloads the base default verson). Until then I'll be on qbit 4.4.4.

[glassez]

I do hope that libtorrent 2.x can be implemented again in the base version of qbit at some point (i use chocolatey to update qbit and it always downloads the base default verson). Until then I'll be on qbit 4.4.4.

It is still here. We switched back to use libtorrent-1.2 by default, but libtorrent-2.0 builds are also available.

[gothicserpent]

Yeah I'm having difficulty telling my downloader, chocolatey, to select the libtorrent 2.0 builds in the update command line. So it's a little tricky for me unless i manually download the exe.

I use choco upgrade all -y and it upgrades qbit (and my other software) all automatically for me to the current base version, and if I was to use the libtorrent 2.0 build the chocolately install/upgrade config might not recognize it and think it's on a previous version than it really is, so I always rely on the base builds.

[MrxHellsing]

@summerqb I'm thinking of trying the latest stable version, now the alpha version that you suggested to me had some extra files compared to v4.4.5. Can I just extract it over the existing alpha version or do I need to delete those extra files before extracting it?

[MrxHellsing]

An update on my tests, @summerqb , I tried extracting v4.4.5 (both qt6 and non qt6 installer) over the existing alpha version 1st and then tried it by deleting those extra files that were in the alpha version. In all cases, the GUI stayed frozen. I observed for 15 mins, and after that, I shut the app down since there were no signs of the GUI stabilizing. So, still using the alpha version. In my case, the latest version (4.4.5) is unstable.

[microka]

I am using qb_4.4.5_qt6_x64 on Windows 11 22H2, occur the Freezing & Not Responding problem too.

[lynzrand]

Switched from 4.4.5 to 4.5.0 beta1 (libtorrent 2), I can confirm that the big freeze isn't there anymore.

Running in Windows 11 with 140+ torrents. Was freezing for 10+ minutes at initial load.

[ghost]

I am using now the 4.5.0 beta1 libtorrent 2.0.8 version

Freezing and very high CPU usage after i push the "force reannounce" button (1500+ torrents running same time)

my CPU is i7-4790K, i have 16GB RAM and I am using only SSD-s (870EVO Samsung 1TB for system and 4TB for download/seed torents)

Why do you post these without sharing your config? What number are you using for concurrent announces? Are you announcing to all trackers in a tier/all tiers? How are we suppose to deduce those without a configuration file?

[arvidn]

Freezing and very high CPU usage after i push the "force reannounce" button (1500+ torrents running same time)

Is that unreasonable? How many HTTPS connections are made? (torrents may have many trackers each)

[glassez]

@arvidn
I believe this is due to the fact that not all problems with blocking calls have been solved yet. I'm working on it. It's a pity that in most cases I have to use workarounds.

[ghost]

Freezing and very high CPU usage after i push the "force reannounce" button (1500+ torrents running same time)

Is that unreasonable? How many HTTPS connections are made? (torrents may have many trackers each)

Most people here expect a startup time of 5 seconds with 5000 torrents, a client that never ever freezes, and uses only 0.001% of installed RAM.

[arvidn]

Most people here expect a startup time of 5 seconds with 5000 torrents, a client that never ever freezes, and uses only 0.001% of installed RAM.

But we were talking about announcing to at least 1500 trackers, but probably 10 or 100 times more (depending on the number of trackers per torrent). It's not reasonable to expect 15000 HTTPS connections to use 0.001% CPU and just take a few seconds. The SSL handshake is not exactly light weight.

[ghost]

Most people here expect a startup time of 5 seconds with 5000 torrents, a client that never ever freezes, and uses only 0.001% of installed RAM.

But we were talking about announcing to at least 1500 trackers, but probably 10 or 100 times more (depending on the number of trackers per torrent). It's not reasonable to expect 15000 HTTPS connections to use 0.001% CPU and just take a few seconds. The SSL handshake is not exactly light weight.

You can easily find people claiming that utorrent has that level of stability and never bogs down the system.

[fanjing-whu]

I have the same issue with 'Validate HTTP tracker certificates' enabled.
Maybe, you can try this.
Disable 'Validate HTTP tracker certificates'
#15623

[AvangionQ]

GUI takes about ten minutes to start being responsive, then freezes to white screen after a few minutes later. I have over 8,000 torrents, so that's probably the reason why, but still, shouldn't be this buggy. Whenever I want to add a new torrent, typically wait for my network to go relatively idle, close & restart Qbittorrent. I don't know what the specific issue is, but this problem is common among all versions of the program. I've tried upgrading, downgrading, then back to newest 4.5.2 version again. My drivers and all other software are up to date, thanks IObit, so there's got to be a setting that's causing the not responding lag. Suggestions would be appreciated.

[crackwitz]

Whenever I want to add a new torrent, [...] close & restart Qbittorrent

you can add a new torrent without restarting qbittorrent

no, it's not a bug, it's just an issue of you having 8000 torrents, which take a while to load. did you know, 8000 torrents divided by 10 minutes means 13 torrents a second, which sounds suspiciously close to the expected access time of a HDD. I'll assume that you aren't running your torrenting entirely off SSDs.

[arvidn]

no, it's not a bug, it's just an issue of you having 8000 torrents, which take a while to load. did you know, 8000 torrents divided by 10 minutes means 13 torrents a second, which sounds suspiciously close to the expected access time of a HDD.

So, are .torrent files loaded from disk in the GUI thread?

[crackwitz]

Probably :D can't think of another explanation either

[AvangionQ]

My main drive is an SSD, I have three other internal hard drives and seven external hard drives. My computer has 16GB RAM and I allow Qbittorent up to 8GB of that RAM in advanced settings, though 2GB is typical RAM usage.

…

On Thu, May 25, 2023 at 2:10 AM Christoph Rackwitz ***@***.***> wrote: Whenever I want to add a new torrent, [...] close & restart Qbittorrent you can add a new torrent without restarting qbittorrent no, it's not a bug, it's just issue of you having 8000 torrents, which take a while to load. did you know, 8000 torrents divided by 10 minutes means 13 torrents a second, which sounds suspiciously familiar to the expected access time of a HDD. I'll assume that you aren't running your torrenting entirely off SSDs. — Reply to this email directly, view it on GitHub <#17603 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF2RA6ESNYMIXNQQDR2UBJLXH3ZVHANCNFSM57OLHBSQ> . You are receiving this because you commented.Message ID: ***@***.***>

[klepp0906]

just chiming in, having some gnarly freezing too (on windows)
I'm not your typical use case though. ~60tb seeding and ~17k torrents. Startup as you can imagine is more of a leave-it-alone for a moment type thing.

Then it (best i can tell so far) randomly stops responding. I've tried high async i/o, low async i/o, giving it a metric ton of disk cache (16gb) and so far no good.

I certainly dont expect it to start instantly, nor close instantly. I just want to not have it randomly stop responding.

I am seeding off of 4 18tb exos but have a 16 thread cpu and 64gb of memory so i'd like to think some combination of what I noted would have bore fruit.

I did try lib 2 builds as well, but those are a non starter as no matter how much i raise the physical ram limit, it doesnt seem to want to cache writes whatsoever and i cant download, like at all. it just write cache overloads to death.

dont let me digress.

[glassez]

Could you try v4.6 beta build?

[klepp0906]

Could you try v4.6 beta build?

id love to, am eager to in fact (i'm one of THOSE lol) but i exclusively use private trackers and I imagine zero of them have whitelisted 4.6 yet so no torrents would work anyhow.

if there were meaningful changes to the gui's ability to not hang in 4.6 i'll have to be optimistic and patiently wait lol.

[13xforever]

I started to get similar issue few days ago, what I have noticed: it happens under high seeding load (15-50 Mbps upload), peer list on torrents are showing up empty for all active torrents, and after about 20 minutes it just stops accepting or making new connections, and the stats on active torrents are frozen (upload speed etc), and UI generally becomes unresponsive. If left in this state for several hours after hang, it may not properly shutdown and I have to kill the process.

I've used this version since release (v4.6.3 lt2.0), but only got issues very recently.

[13xforever]

It seems at least my issue was related to using Hyper-V when sharing physical ethernet connection.

[luzpaz]

Is this issue still relevant ?

[lesderid]

Is this issue still relevant ?

Yes, I regularly experience the issue described in the original issue post. I'm running qBittorrent 4.6.6 on Windows Server 2019 with a couple thousand torrents set to seeding (but rarely more than 10 active simultaneously).

It's unclear to me what triggers this problem, it occurs sporadically, but I believe it usually only happens when more than 20 new torrents are downloading (or perhaps have recently finished downloading).

Edit: Actually, my case might be a different issue: it only stops responding for a few seconds at a time for me. It feels to me like the UI thread just doesn't get much CPU time.

[xavier2k6]

@13xforever @lesderid Have either of you tested qBittorrent v5.0RC1?

[13xforever]

I already mentioned that my issue was with specific hyper-v networking configuration. After changing it, I did not experience the problem anymore.

[xavier2k6]

I already mentioned that my issue was with specific hyper-v networking configuration. After changing it, I did not experience the problem anymore.

@13xforever Apologies, I see that now (overlooked)

[lesderid]

@13xforever @lesderid Have either of you tested qBittorrent v5.0RC1?

AFAICT release candidates are not allowed by any of the trackers I use.