Log In
Register
Home
News
Support
Forum
Donate
Help and Support
Ask a question, report a problem, request a feature...
<< Back To Forum
Downloads marked as complete missing a piece after force check
by
PhoenixNL72
on 2025/11/02 11:28:20 PM
Tixati v3.36 on Windows 10
Very often after a download is reported by Tixati as complete it turns out a single piece has not been properly moved from the piece cache to the download. After I do a force check the torrent turns out not to be complete. This seems to only happen with multifile torrents and happens more often when the destination folder is set to a different drive from the one holding the piece cache.
This problem has been persistent since the first Tixati (v2.57) I used over 6 years ago. It happens so often that I've created special checking/checked categories so I know which torrents I've force checked and which have passed those tests. And I've had this problem on multiple different PCs with both windows 7 and later windows 10. I've started doing those forced checks in the past cause I kept encountering video files that wouldn't play in completed downloads regularly and found those torrents to be incomplete after doing a check after encountering those unplayable files.
As far as I can tell it's seems to always be the last piece at the end of the penultimate file and the start of the last file meaning two incomplete files, one of which (the last one) misses it's starting header.
Would be very nice if someone would finally be able to fix this issue.
by
PhoenixNL72
on 2025/11/02 11:33:30 PM
Addition: I've set Tixati to automatically do a check of the files (not hash) after a download is completed. But even after that check succeeds if I manually do a check later it's incomplete.
It's not caused by hardware issues like bad memory as it happens on different computers who have all passed memtest x86+ memory tests and the prime95 CPU burn tests.
These are some of the settings from the 'File Menu' I use in case they are relevant:
File Allocation - Sparse
Move individual files upon completion = Enabled
Redundant hash-check on completion = File
Also note that my 'Piece Cache' drive, Download drive and 'Move on Complete' Drives are different ones.
by
Guest
on 2025/11/03 12:48:25 AM
if you have a torrent where this happens consistently post the magnet link here so the dev can recreate it.
does it happen if you turn off 'Move individual files upon completion = Enabled '?
is it moving the incomplete files to your complete folder?
do you have incomplete files still in your download folder?
by
Guest
on 2025/11/03 04:29:49 PM
> As far as I can tell it's seems to always be the last piece at the end of the penultimate file and the start of the last file meaning two incomplete files, one of which (the last one) misses it's starting header.
That would be extraordinary if true, as for many many builds now Tixati has deliberately prioritized pre-fetching the starts and ends of all files for EXACTLY that reason - to ensure headers are intact and ends of files are also fetched correctly (the stated reason being that many users download while viewing so ends of video files in particular may not always be reached and finished). If you set sequential downloading and ordered file-completion, you will see that the file starts and ends across the whole torrent are ALWAYS prioritized before the sequential downloading (you might want to try setting those download defaults to see if it makes a difference).
It should certainly not be persistently necessary to force check to get a last missing piece. However, note that you can also set Tixati to do a full hash confirmation check pass on the torrent after downloading, which should be the same as doing your forced check. This might at least help automate your issue.
Since the reported behaviour is not consistent with my observation of how Tixati works and the stated intent of the developers explained above, this must be something unique to your setup or configuration. Nothing you have stated (cache file location etc.) should affect that. :/
by
Guest
on 2025/11/09 07:56:41 PM
It doesn't happen with a specific torrent/magnet but regularly with multifile torrents.
It might be related to another issue I keep having is that scans/checks or move freeze. If Tixati is performing an action that takes up a lot of CPU power (window becomes unresponsive) tasks like that will freeze and I'll have to go through the entire list to find the one that's stuck, stop it and restart it to get those worker threads (I'm assuming are what perform those scan/check/move actions) unfrozen. And the incomplete torrents seem to happen more frequently after a freeze like that. On average I have about 4-5 torrents a week that are incomplete after a check even though Tixati said they were finished.
As a note I have tixati running all the time on a PC that's always on. So it's usually been running for days if not weeks.
I also have a big list (9000+ torrents at the moment) but the issue also occured years ago when the list was a few thousand torrents.
Since my last post I've noticed at least one torrent which had an incomplete file in the middle of the list (sorted alphabetically) though at the time I made my original post I had 3 torrents that had a missing piece on the second to last file running over into the last file.
by
PhoenixNL72
on 2025/11/09 08:13:33 PM
>> does it happen if you turn off 'Move individual files upon completion = Enabled '?
I've had it happen with that option disabled too in the past.
>> is it moving the incomplete files to your complete folder?
Yes
>> do you have incomplete files still in your download folder?
No, though I have noticed that sometimes in torrents that did complete successfully that parts of the torrent are still in the download folder even though a forced check completed succesfully. I've also noticed that when moving a torrent manually to another drive sometimes files are left behind in the original complete folder.
>> That would be extraordinary if true, as for many many builds now Tixati has deliberately prioritized pre-fetching the starts and ends of all files for EXACTLY that reason - to ensure headers are intact and ends >> of files are also fetched correctly (the stated reason being that many users download while viewing so ends of video files in particular may not always be reached and finished). If you set sequential downloading >> and ordered file-completion, you will see that the file starts and ends across the whole torrent are ALWAYS prioritized before the sequential downloading (you might want to try setting those download defaults to >> see if it makes a difference).
As I said it happens with multifile torrents only. And when I reported the issue it was the last block of the second to last file (alphabetically) in 3 different multifile torrent downloads. But I've payed more attention and seen it in other files in different parts of multifile torrents I downloaded since.
>> It should certainly not be persistently necessary to force check to get a last missing piece. However, note that you can also set Tixati to do a full hash confirmation check pass on the torrent after
>> downloading, which should be the same as doing your forced check. This might at least help automate your issue.
Like I said I have been having to do forced checks for the past 6 years on two different computers running both Windows 7 and Windows 10. And regularly multifile torrents are incomplete after the forced check has completed. I never had this issue with uTorrent which I used before it was taken over and turned into adware by the new owners (Which is why I switched to Tixati back then).
>> Since the reported behaviour is not consistent with my observation of how Tixati works and the stated intent of the developers explained above, this must be something unique to your setup or configuration.
>> Nothing you have stated (cache file location etc.) should affect that. :/
It seems to me that sometimes, when the program has been very busy to the point it froze, things get messed up in the program, Maybe the piece(s) aren't moved from the piece cache due to other threads being to busy an stalling it but they are registered in the torrent as moved? Eg something like a racecondition between different threads?
My setup is using 3 different drives(2x 3TB and 1x 4TB) and a NAS server, though the NAS is the final location where I move torrents manually to through the tixati interface after having done a forced check.
I have partially completed/downloading torrents on all 3 drives and seeding torrents on all 3 drives and from the NAS.
by
PhoenixNL72
on 2025/11/09 08:25:49 PM
>> If you set sequential downloading and ordered file-completion, you will see that the file starts and ends across the whole torrent are ALWAYS prioritized before the sequential downloading (you might want to try >> setting those download defaults to see if it makes a difference).
I have set the download default to ordered and synchronized mid last year when I upgraded to v3.31 (I think it was) which was the first version I used that had the option to set that as an option. I often did set priority of files in (big) torrents to Ordered/sequential manually before that. Didn't help.
Main problem with this is that it's intermittent, sometimes I can download 100 torrents without an issue and at othertimes I can download 10 which all have this. Which makes me think it's a state the program gets into where something gets messed up with not moving pieces from the cache but flagging them as moved. I've had it happen with torrents which finally completed after months of trying to download it. And no telling when the torrent got messed up during that time. It doesn't seem to happen as often with torrents I add that start and finish downloading in one go in a short time though.
Add Reply
<< Back To Forum
This web site is powered by
Super Simple Server