Version 2.34 is the last one that worked without this issue.

Every version since, even after a clean install or with portable edition, all torrents are doing this.
It is also very taxing on CPU usage.

I have also confirmed that "Skip last write time checks" is unchecked in 2.34, so I did not want to have to check that in later versions as a work around.

In the meantime, I have reverted back to 2.34

Any ideas? What changed?

Thanks

The tolerance window for incorrect last-modified times may have changed.  It was on the order of 10-15 seconds difference allowed at one point, perhaps it's less now.  I have not run drives with this kind of problem in a long time.  It could be now that the checkbox to override this is available, the tolerance is less, so to avoid more 'false negatives' when files that actually were changed are missed for checking and end up seeding bad pieces, because the modification happened shortly after the file was last closed after writing, during an overly-wide tolerance window.

Regardless, if you look at the event log for one of the transfers doing this, you can find the actual mismatch, expected time and actual time.  If you post these lines (but blank out any file names) then maybe there will be something there...

BTW do you have any sort of anti-virus or backup utility running?  Internal hard drive?  External?  Network drive?  Windows/Linux?  Filesystem (eg. ntfs or fat32 or ext4)?

here's the log

 *** 6/22/2016 ***
[5:56:36 PM]  starting
[5:56:36 PM]  downloading initiated
[5:56:45 PM]  starting DHT search
[5:57:12 PM]  downloading initiated
[5:57:27 PM]  file created > {FILE_NAME}
[5:57:31 PM]  completed DHT search, found 131 peers
[6:00:55 PM]  file LM time mismatch, expected 2016/06/22 05:57:12 PM but file is 2016/06/22 05:57:27 PM > {FILE_NAME}
[6:00:55 PM]  waiting to check files
[6:00:55 PM]  checking files
[6:01:01 PM]  files check complete
[6:01:26 PM]  file LM time mismatch, expected 2016/06/22 05:57:27 PM but file is 2016/06/22 06:01:01 PM > {FILE_NAME}
[6:01:26 PM]  waiting to check files
[6:01:26 PM]  checking files
[6:01:32 PM]  files check complete
[6:03:10 PM]  file LM time mismatch, expected 2016/06/22 06:01:01 PM but file is 2016/06/22 06:03:08 PM > {FILE_NAME}
[6:03:10 PM]  waiting to check files
[6:03:10 PM]  checking files
[6:03:15 PM]  files check complete
[6:03:54 PM]  file LM time mismatch, expected 2016/06/22 06:03:31 PM but file is 2016/06/22 06:03:45 PM > {FILE_NAME}
[6:03:54 PM]  waiting to check files
[6:03:54 PM]  checking files
[6:04:02 PM]  files check complete
[6:04:44 PM]  file LM time mismatch, expected 2016/06/22 06:03:45 PM but file is 2016/06/22 06:04:23 PM > {FILE_NAME}
[6:04:44 PM]  waiting to check files
[6:04:44 PM]  checking files
[6:04:50 PM]  files check complete
[6:04:55 PM]  file LM time mismatch, expected 2016/06/22 06:04:23 PM but file is 2016/06/22 06:04:49 PM > {FILE_NAME}
[6:04:55 PM]  waiting to check files
[6:04:55 PM]  checking files
[6:05:01 PM]  files check complete
[6:05:23 PM]  file LM time mismatch, expected 2016/06/22 06:04:49 PM but file is 2016/06/22 06:05:14 PM > {FILE_NAME}
[6:05:23 PM]  waiting to check files
[6:05:23 PM]  checking files
[6:05:29 PM]  files check complete
[6:05:38 PM]  file LM time mismatch, expected 2016/06/22 06:05:14 PM but file is 2016/06/22 06:05:37 PM > {FILE_NAME}
[6:05:38 PM]  waiting to check files
[6:05:38 PM]  checking files
[6:05:44 PM]  files check complete
[6:06:10 PM]  file LM time mismatch, expected 2016/06/22 06:05:37 PM but file is 2016/06/22 06:06:03 PM > {FILE_NAME}
[6:06:10 PM]  waiting to check files
[6:06:10 PM]  checking files
[6:06:16 PM]  files check complete

"BTW do you have any sort of anti-virus or backup utility running? Internal hard drive? External? Network drive? Windows/Linux? Filesystem (eg. ntfs or fat32 or ext4)?"

av: eset
backup: no
drive: external usb3 (mapped drive to a vmware shared folder not network share)
os: windows (vmware vm)
fs: ntfs/hgfs

In your log, notice how the expected time is the same as previous actual time, which is the correct expectation, since nothing should be writing to the file and updating the last-modified time between checks.

However, something clearly is updating that time, it could be your AV, maybe something else.

Some external drives with buggy versions of firmware will update the last-modified time when a file has been merely read, which is incorrect behavior, but generally does not cause problems, except when these times are relied upon (backup utilities run into this exact problem too).

To test, outside of Tixati, in your usual windows file explorer, you could create a file on that drive, note the last modified time, then make a copy of the file... the last modified time of the original should not change, if it does, then there's the problem.

Anyhow, the solution to this will be to use the option to ignore the lastmod times.  Everything will be fine.  They probably tightened the window up a bit after 2.34, which is a good thing, since this is a rare problem it seems, and the solution works well.

This is EXACTLY what is happening here.  I can tell just by looking at that log.

OP, try updating your NAS firmware.  If that doesn't work, you have to check the option in Settings > Transfers > Files to ignore last-modified times.  If a previous version was more lax about checking those, then you aren't being protected anyway and it's the same as running the newer one with the workaround activated.

Google: network attached storage last-modified time updating on read

There are several results that talk about this problem with some buggy NAS units, eg. http://support.2brightsparks.com/knowledgebase/articles/215345-the-last-modification-date-and-time-are-wrong  and http://backupchain.com/i/why-you-shouldnt-buy-a-nas-like-drobo-synology-buffalo-netgear-qnap

There's really nothing wrong with Tixati here or that the devs can do to fix other people's bugs beyond providing the work around option.  They definitely shouldn't relax the time checks to what they were before, even if it buys the illusion of safety for 0.001% marginal cases of these NAS firmware bugs.

Thank You

I will investigate further.

The option to check "Skip last write time checks" is working for now.

I will update if/when I am able to spend some more time troubleshooting

Love tixati and happy im changed fron others :=) Im have a same problem on 2 diffrent nas synology and qnap

Hope you guys cans  sort this out wery frustating :=)

V2.86, windows 10

I recently starting seeing "waiting to check" while downloading, found this thread, however, I think the items have changed since this thread started, the feature is now listed as:

settings
files
skip last-write time checks (not recommended)

click the check box (should now have a check listed)

the files will continue checking until 100% and then stop checking

-

Very useful on a NAS drive, since I really don't want it re-checking every time the % downloaded updates...

Thanks Tixati... keep up the great work! :)

I am getting this message multiple a day.  The file was created and seeded by me.  It has not been modified in any way.  It is hosted on a Linux box and Tixati is hosted on a Windows box.  There are 3 of these folders with many files inside but they are all movie files and never get modified.  How can any time mismatch happen when there is nothing going on with the folder?  It is find for a long time (12 hours or more, sometimes) then throws this error.  I don't understand why there the program is complaining or what it is complaining about!  Please fix this.  It keeps throwing my seeds offline.