I notice when I'm initializing a new torrent, the current torrent I'm downloading starts dropping speeds, almost to zero. It's like it's pausing while the new torrent is starting. I also use qbittorrent and this doesn't happen in that program. Is there any way to prevent this?

hello Guest

the slowness occurs probably during allocation of the files
go to the Settings dialog box choose "Transfert" then "Local Files"
and for the "File Allocation" option choose "Fast Allocate (default)" or better "Sparse Files"

my setting is "Sparse Files" and i didn't encouter some slowness when adding new torrent

hope it helps

I think it happens because hard drive is very busy during file allocation. Go to Settings > Local Files and change File Allocation to Sparse Files. It helps on Windows, it is much faster method than the one Tixati uses by default.

Ok I will try setting to Sparse Files, even though I don't know what this means lol. Thanks guys for the suggestion.

I updated the support page a little for this, but a new image is needed since the current options have changed.
If anyone can flesh out the explanations for the 3 options for "File Allocation" it would help.

I noticed a similar problem when initializing files, at least until I switched to "Sparse Files", and in general I have found the stability and responsiveness of Tixati to struggle during periods of intense HD activity.

In particular, if the application crashed, or an improper shut-down resulted in having to re-check a large torrent (> ~1GB), when I relaunch it the UI will slow to a crawl. Menus will open eventually, but sometimes take 4-5 seconds to respond. Tooltips will pop up, render a frame at half opacity, render another at full, and then disappear in a similar disjointed manner. Transfer speeds on unaffected torrents which do not need to be rechecked are extremely sporadic and will burst up to ~500KB/s UL and then fall back down to almost nothing, going back and forth, until drive utilization calms down.

I also need to mention that this only occurs when I am using my external HD. I haven't had lag issues while allocating/checking on my internal HD. I have it connected through USB 2.0 (~28 MB/s read, just tested) but maybe it gets bogged down with a high number of individual requests (i.e. reading 1000's of files instead of a few big ones). Though I would still expect the UI to remain responsive during this, so there is still some issue.

I've only ever experienced this problem during "Fast Allocation (Default)" or while re-checking, and with "Sparse Files" it rarely causes me trouble, but I sigh every time I have to check a torrent. I've also had it happen once when I accidentally started a defrag on my external HD instead of internal, so it seems to happen regardless of whether Tixati itself is causing the high utilization. The unresponsiveness of the UI is the biggest issue with this as it can be almost impossible to accomplish anything until the procedure is complete. In once case I had to wait almost a half hour for ~100GB of files to be checked (one massive torrent) before i could effectively add/remove transfers again.

It might be an issue with my particular external HD (getting a new one soon finally), but not sure why a slow HD would cause the UI thread to get crushed.

... Theory: It's multi-threaded but that does not mean they are independent. This is still an issue for certain setups with bus speeds not being utilized effectively. Theoretically, to avoid this problem, one would have to script the following:
Tixati autoloading your files without any prompts (the windows that pop up cause interruption to the data download)
Tixati either being set to fast allocation or sparse files.
Auto move upon completion to a new directory for COMPLETED transfers... which would ideally become defragmented (from fast allocate or sparse files, since the reason it's so fast Windows handles the disparate chunks of data)...
Then move to a fast READ drive/device separate from the download partition/drive. NAS may not cut it. You'd still be using bandwidth which would be better suited to a USB 3/C/Thunder/Lightning port. SSD theoretically performs the best, WO-Read Many... contiguous files would cause the least seek or bus thrashing after seeding.