Similar request to https://forum.tixati.com/support/2781/
Except I have issues on my low spec machine during normal save operations. Setting the TTL interval for how often the configuration is dumped to disk will help alleviate the bottleneck which results from what I presume is a busspeed thrashing.
Example: With 800 transfers the RAM usage is ~525mb to 610MB which is fine. BUT the resulting core2.dat (and .dat.new when dumped to disk) is 32MB and with channels2.dat at 110MB so every 12-15 minutes (I didn't time it) when the program goes through collection efforts to save-state... I can get a non-responsive window for over a minute. As described in other threads about "locking" this error is not due to the internal processes checking data. At least not that I've seen and nothing that sysinternals is showing me. The file handle(s) open are the temp DAT files and the background dumping of data simply takes too long as-is.
It makes the most sense for options like this to be under SETTINGS --> User Interface--> Behavior or Transfers--> Files if this interval option of checking DAT files becomes more elaborate. Perhaps once the logic is set the NAS data throughput issue can be resolved...

Looking forward to any improvements. Thanks for Tixati!
P.S. As an alternative to the user-preferences to changes, perhaps not dumping everything sequentially could also be an option.