rechecking was triggered again without a reason - the storage was not disconnected

[Destroyarr]

qBittorrent & operating system versions

winver 26058.1300 (Windows 11 10.0.26058 Dev Build)

qbt 4.6.3

Qt: 6.4.3 Libtorrent: 2.0.9.0 Boost: 1.83.0 OpenSSL: 1.1.1w zlib: 1.3

What is the problem?

rechecking was triggered again without a reason logs show nothing about why the rechecking happens some torrents are rechecking others are not

Steps to reproduce

load 300+ torrents from different places (BT_Backup has 691 files in it) exit the client gracefully few times

Additional context

No response

Log(s) & preferences file(s)

It's supposed to be a massive seedbox TBs of files

Click

[BitTorrent] Session\SuggestMode=true Session\QueueingSystemEnabled=false BdecodeDepthLimit=999 Session\FilePoolSize=999 Session\AnonymousModeEnabled=true Session\MaxConcurrentHTTPAnnounces=99 Session\HashingThreadsCount=1 Session\SaveResumeDataInterval=1 Session\RefreshInterval=777 Session\Interface=ethernet_43879 Session\InterfaceAddress=192.168.1.2 Session\DefaultSavePath=O:\\ Session\AnnounceToAllTrackers=true Session\PieceExtentAffinity=true Session\MultiConnectionsPerIp=true Session\DiskQueueSize=2046976 Session\MaxUploads=-1 BdecodeTokenLimit=90000000 Session\OutgoingPortsMax=65535 Session\Preallocation=true Session\LSDEnabled=false Session\MaxConnectionsPerTorrent=-1 Session\MaxConnections=-1 Session\Port= Session\uTPMixedMode=TCP Session\CheckingMemUsageSize=999 Session\PerformanceWarning=true Session\GlobalDLSpeedLimit=24000 Session\MaxUploadsPerTorrent=-1 Session\AsyncIOThreadsCount=1 Session\InterfaceName=Ethernet Session\BlockPeersOnPrivilegedPorts=false Session\OutgoingPortsMin=1024 Session\ConnectionSpeed=999 Session\DHTEnabled=false Session\ReannounceWhenAddressChanged=true [AddNewTorrentDialog] DialogSize=@Size(1515 763) SavePathHistoryLength=23 Attached=false Enabled=true TopLevel=true RememberLastSavePath=false DownloadPathHistory= SavePathHistory=O:\\, L:\\S, N:\\, H:\\, K:\\D, K:\\Se, K:\\Se\\Full, K:\\M [GUI] Qt6\TorrentProperties\FilesListState= Qt6\AddNewTorrentDialog\SplitterState= Qt6\AddNewTorrentDialog\TreeHeaderState= UIThemeDialog\Size=@Size(451 348) Qt6\TransferList\HeaderState= Qt6\TorrentProperties\PeerListState= Log\Enabled=true StartUpWindowState=Normal MainWindow\FiltersSidebarWidth=226 DownloadTrackerFavicon=true Qt6\TorrentProperties\TrackerListState= [TransferList] SubSortColumn=14 SubSortOrder=1 [Application] FileLogger\Enabled=true FileLogger\AgeType=1 FileLogger\Backup=true MemoryWorkingSetLimit=7777 FileLogger\Path=C:\\Users\\User\\AppData\\Local\\qBittorrent\\logs GUI\Notifications\TorrentAdded=false FileLogger\Age=3 FileLogger\DeleteOld=true FileLogger\MaxSizeBytes=101376 [Preferences] General\MinimizeToTrayNotified=true General\MinimizeToTray=true General\PreventFromSuspendWhenSeeding=true Advanced\EnableIconsInMenus=true General\Locale=en General\PreventFromSuspendWhenDownloading=true General\ExitConfirm=false [TorrentOptionsDialog] Size=@Size(450 576) [AddTrackersDialog] Size=@Size(367 274) TrackersListURL= [TransferListFilters] selectedFilterIndex=0 [LegalNotice] Accepted=true [Network] PortForwardingEnabled=false [Meta] MigrationVersion=6 [Core] AutoDeleteAddedTorrentFile=Never [RSS] AutoDownloader\SmartEpisodeFilter= AutoDownloader\DownloadRepacks=true [DownloadFromURLDialog] Size=@Size(501 220) [TorrentProperties] CurrentTab=1 Visible=true SplitterSizes="594,179" [OptionsDialog] HorizontalSplitterSizes=171, 857 LastViewedPage=7 Size=@Size(1055 663) [AboutDialog] Size=@Size(545 314) [MainWindow] geometry= LastDir= [StatisticsDialog] Size=@Size(286 401) [SpeedLimitDialog] Size=@Size(481 272) [SpeedWidget] Enabled=false

[Destroyarr]

https://forum.qbittorrent.org/viewtopic.php?t=4230 Found this comment looks like I will have to do the same.

Quote: I have a bit more torrents. The recheck takes a week for me, so I save the qbittorrent profile files (config and data or [AppData\Roaming\qBittorrent] and [AppData\Local\qBittorrent]) on a daily basis and restore the state when there was no forced recheck. And I will add the few new torrents again or use the copy magnet links trick, if there were any. If there is a faulty torrent, it is among the new ones anyway.

Others reporting similar issue with storage which may have been disconnected or not: https://github.com/qbittorrent/qBittorrent/issues/17302

[Destroyarr]

We could add another indicator of completeness. Set ARCHIVE flag on filesystem as well as READONLY flag. This can be the last IO operation on the freshly completed torrent and should be the easiest to implement.

[Sepero]

I also seem to be experiencing this issue. I have about 1500 torrents, and I recently noticed over 300 torrents queued for recheck.

Normally I use qBittorrent-nox (headless), but 2 days ago I opened in qBittorrent-gtk and added about 5 new torrents. I noticed the recheck happening after using qBittorrent-gtk, but...

• I don't know if opening with qBittorrent-gtk triggered the recheck or not.
• I don't know if recheck is normally happening on qBittorrent-nox, because I rarely check it.

Most of my torrents are 100% complete, so there is no apparent reason for recheck.

OS: NixOS 23.11 qBittorrent-gtk v4.6.4 qBittorrent Nox (headless) v4.6.4 Libtorrent 2.0.10

[glassez]

qBittorrent-gtk

What is qBittorrent-gtk? qBittorrent uses Qt, so it has nothing to do with Gtk.

I recently noticed over 300 torrents queued for recheck

What exactly do you mean by "queued for recheck"? Would you mind to provide screenshots of how do they look in UI?

In fact, the log messages (covering the start of the session in which "recheck is triggered" and the end of the previous session) could be a starting point in troubleshooting this problem, but unfortunately you all ignore them from being provided.

[Destroyarr]

Does this qbt gtk and nox variants in containers or not do a gracaful shutdown of the app, so that the fastresume files are all saved ? I can guess that it didn't exactly gracefully write all of them. And so the recheck was triggered.

On the Win64 the problem hasnt happened since because every time I take all extreme care to do a graceful shutdown and setting write resume data every 1min. Since then total torrents in the app are 1000+ and GB up/day are usually 100+

Now if I figure it out how to do an instant preallocate without admin, on the NTFS I will finally be able to die happy.

[Sepero]

What is qBittorrent-gtk? qBittorrent uses Qt, so it has nothing to do with Gtk.

My mistake. You're correct. The binary is just named "qbittorrent", and I wrongfully assumed it was gtk based. Looking into the About section, I can see it shows QT.

What exactly do you mean by "queued for recheck"? Would you mind to provide screenshots of how do they look in UI?

Queued for recheck means that it isn't trying to read and verify them all at the exact same time. On the left side menu it has: All, Downloading, Seeding, Completed, ..., Checking

Each of these have a (number). The number of Checking was over 300.

In fact, the log messages (covering the start of the session in which "recheck is triggered" and the end of the previous session) could be a starting point in troubleshooting this problem, but unfortunately you all ignore them from being provided.

My apologies. You're absolutely correct. I will see if I can produce them.

Does this qbt gtk and nox variants in containers or not do a gracaful shutdown of the app, so that the fastresume files are all saved ? I can guess that it didn't exactly gracefully write all of them. And so the recheck was triggered.

Not a container. I recently set qbittorrent-nox to start and stop as a systemd service with my machine so that it just runs automatically, and I no longer have to manually run it. qBittorrent may not be getting proper time to shut down (not sure yet). I will try to follow up on this as I acquire new information.

[glassez]

The number of Checking was over 300.

"Checking" filter includes not only "checking hashes" torrents, but also "checking resume data" ones. What kind of status is displayed in the "Status" column for those torrents (it should be wide enough to see it in full)?

[Destroyarr]

@Sepero

From my side I have stability based on the following conditions:

1. Not restarting OS/VM/Container before the App is done saving its resume fastresume files
2. qBT settings - autosave 1 min or more often
3. Security measures on OS level
4. Hardware stability measures
5. OS is patched often
6. Probability for storage issues are minimized (storage subsystem is simplified)
7. Minimised bottlenecking scenarios by manually skipping rechecking and manual intervention as needed

@Sepero Can you say we can close this issue and open a new one if needed ?