Log In
Register
Home
News
Support
Forum
Donate
Help and Support
Ask a question, report a problem, request a feature...
<< Back To Forum
Constantly "Checking" files
by
Guest
on 2014/07/31 09:59:43 AM
I have just started using Tixati (1.96) portable on Windows moving from uTorrent.
Every torrent I try starts ok and begins to download but then goes in to a constant loop "Checking" the files.
After scouring the forum I have tried forcing a check, changing peer read caching, changing file locations to local disk instead of USB, and enabling permissive checks but nothing has helped.
Event log keeps showing
"file last modified time mismatch"
Does anyone have any ideas how to stop this?
by
Guest
on 2014/08/01 02:19:48 PM
I have found the download does eventually complete but is very slow, I assume due to the constant checking.
Still no idea why it keeps looping on checking the files.
by
Sailor24
on 2014/08/07 06:59:12 AM
Is there a chance you have Utorrent running? maybe in the back ground? check with task manager.
by
Guest
on 2014/08/22 05:27:15 PM
Hello,
Apologies for the long delay in replying.
No, uTorrent is not running.
I have updated to 1.97 today and this has improved. It still checks frequently but it is no longer constant and seems to have much less impact on the download.
The release notes do say they have relaxed this for NAS isues and so I assume this has helped even though I am not using a NAS and it seems they are changing how the checking is done in future as well so it is probably not worth worrying over this any further.
Thanks
by
KH
on 2014/08/22 07:49:53 PM
There is something in the settings, at Transfers > Local Files, it says "Permissive last-write time checks".
Try that if you still get checking issues.
We're eventually going to eliminate the use of last-modified times and give Tixati a fine-grained hashing system instead.
by
Guest
on 2014/10/18 10:58:42 AM
Hello everyone,
I do suffer from the same phenomena, too.
Enabling permissive last-write does nothing (maybe helps something, but seems to have no real effect).
I tried to turn off individual files in the download by setting priority off.
Still, those files were opened for write( (w)) temporarily, although they already were in Off state.
Very disturbing that even some files are already completed, checking is initiated on them sometimes... why???
Also noticed that a file that have finished checking started checking right again.
My assumption is that some threads in Tixati do not know about what the others do, or should do.
A special setting which turns the checking off completely and/or logging the found and the expected value of the last write time could be very useful for debugging.
At the moment a ~10GB 12 file download with 1M pieces cannot complete, stuck at around 90%, because of the constant checking (target is a Ubuntu NAS).
I have stopped the download and watched the files last mod time, but it seem neither Windows nor Ubuntu seems to misbehave.
Something must be wrong within Tixati, it seems that is the only thing that accesses those files.
I have noticed that stopping the download, forcing a full recheck while in stopped state might help a bit, because the download can go on for a couple of minutes before starting the merry-go-round of checking again.
So the bug might be around reading/storing/comparing the last modifed data internally.
Any ideas?
by
Guest
on 2014/10/18 07:21:21 PM
send the torrent to devs with small explanation.
support@tixati.com
by
Guest
on 2016/10/02 09:37:42 PM
Before you assume it's an issue with Tixati, verify you are not running a "realtime scanner". This may be AV or Security or Malware or media player --whatever it is called... if you do not add an exception for the Tixati download folder this may happen.
Tixati does what it does very well but as stated it cannot control other programs. If the file are media and your player likes to mess with tags or append data.... If the files are disk images and you mount them in Windows.... If the files include thumbnails or shortcuts Windows will mess with them.
As of current version 2.47 this happens less but the options mentioned are still there for a reason. There is no universal implementation for non-local storage and as such you can try the two workarounds KH and the dev team have provided.
P.S. @KH is the fine-grained hashing any higher on the to-do?
EX: This is the procedure I follow for each version of Tixati with Windows Defender (included on all versions of windows post 7)
Windows -> Defender -> Open -> Settings ->
"Excluded files and locations" -- make sure main Tixati download folder is listed. Completed may be listed as well but by that time you should be able to get by with a full scan once you switch to seeding. (Be sure to save changes)
"Excluded file types" -- Add the 'incomplete' extension if you use it in Tixati, or add any extensions you don't want impacted. (Be sure to save changes)
"Excluded processes" -- Yes I check/add each version of Tixati here. I usually rename old versions to -2.43-x32 etc. So my Tixati.exe is still the same name but whatever Windows does i add the rule. It's much easier to be sure than try and troubleshoot later. (Be sure to save changes)
"Advanced" -- If I have "scan archives" checked i make sure the types I don't want to are listed above "iso; 7z; rar" etc.
"scan removable drives" applies to FULL, but when I have scheduler run this I make sure Tixati is not trying to fight the disk usage, scheduler is set to OFF for that hour.
by
Guest
on 2023/06/30 06:19:56 PM
2023 and I am getting the same repetitive checking. Over and over on a very large file. It is just killing throughput. When the checking stops for a few minutes, the throughput goes up to 10MB/s. When it starts up again, it dips down in the hundred MB/s. That's huge. I want this to finish but it is quoting many days due to the constant checking. Files are on a USB drive on a Raspberry Pi running their take on Linux. Tixati is running on Windows 11. Is there a time of day issue? A file updated time issue? What's going on. I need the revolving door of CHECKING to stop so this download will finish this year!
by
Guest
on 2023/08/10 09:51:43 AM
Exactly the same here. Keep on "checking" files in a neverending loop. Busy downloading 4x 60-70 Gb archives, and keep on checking in a neverneding loop
10/aug/2023 - tixati version v2.89
by
Guest
on 2023/08/10 03:58:56 PM
Have you tried upgrading to the newest version, 3.19?
by
Guest
on 2023/10/27 02:42:47 PM
This is also occurring for me, latest version v3.19. I am downloading from a windows 10 device to a 8TB SMB Share on my Synology NAS.
File Allocation - Sparse (default)
Peer Read Caching - Predictive
Skipping last-write check times is doing nothing (and is advised as not recommended!), but tested with this setting on and it's still a problem.
by
Guest
on 2023/10/28 04:19:18 AM
something is almost certainly touching your files, possibly even other transfers in the same client, maybe antivirus, who knows.
either way other clients are rather bone-headed and don't really care as long as the files are "there"... they will even let you "seed" a bunch of garbage data without even erroring out!!! realistically Tixati alerting you to an underlying problem designed to stop you from seeding/leeching garbage is not it's fault I would say
the tickbox as I understand it is only applies to the initial scanning phase when starting a transfer, not when downloading.
by
Guest
on 2025/05/17 11:21:41 AM
TV box ZIDOO X8 (android) with Samba, USB 2.0 and USB 3.0 available.
Torrent is loaded from windows Tixati v3.19 on a flash drive connected to USB 2.0 (Windows disk mapping) - constant checking.
Switched the flash drive to USB 3.0 - the problem disappeared.
So it's not a problem of some program or antivirus trying to access files created by Tixati.
by
Guest
on 2025/05/17 12:21:59 PM
I guess I was hasty in reporting that everything works fine on USB3 with Zidoo X8.
Three downloads were successful, but on the fourth one it's that endless checking again.
The same torrent was downloaded to the local Windows disk without problems.
by
Guest
on 2025/05/18 08:39:57 PM
Sorry, but I can't understand the description of your setup. Do you mean that you have a regular USB flash drive stick connected to a regular computer that you use to move files to that Android box? Or that box is directly connected to a computer, and is actively working, and can mutilate the files in any manner it finds suitable?
by
Guest
on 2025/05/20 07:03:52 PM
Android TV BOX, Zedoo X8. (IP 192.168.50.7)
A flash drive is connected to it.
Samba is running on the Zedoo X8.
Zedoo X8 and home Windows PC are on the same network.
On the PC that flash disk is mapped as a network drive - Disk_sdb1 (\\192.168.50.7) ( Z:)
So, the target for Windows Tixati - the flash disk on TV box.
It's like issues above with network NAS disks mapped on Windows.
by
Guest
on 2025/05/20 07:07:02 PM
flash drive - 128GB Amazon flash disk (with internal ssd ), connected to USB3 on TV-Box.
by
Guest
on 2025/05/21 05:55:26 PM
If file access times and file contents change, most likely something on that system (or maybe something on your computer) rewrites the data files. For example, to automatically add cover images and other crap to their tags. A different data file can't match the one listed in torrent file, so torrent client needs to re-download and re-write the changed blocks. Then it repeats again, and again, and again.
You can check for that manually. Move the torrent in question to a local drive. Check the hashes of some file that suffers from that (billions of tools and ways to do that already exist). Copy the file to the intended directory manually. Either wait for something to happen, or use the applications you use to deal with multimedia files. Check modification time and hashes for a copied file. If they are different, something rewrote part of your file.
Check the settings of applications on that device to see which activity might change the files. Alternatively, you might try to set read-only flags for files, or revoke write access rights to your media files, and see whether something breaks.
Add Reply
<< Back To Forum
This web site is powered by
Super Simple Server