After I boot up Windows and run Tixati it always stays on "Scanning 0%", the solution is to restart Tixati, then it will successfully scan the files and start seeding.

https://i.imgur.com/37z57wd.png

Is this a bug with Tixati or is my Windows broken?

I have a similar problem, except that restarting doesn't solve the issue. I uninstalled, rebooted, and reinstalled the latest version (2.71), deleted all the files that were stuck and did a new search on them, no luck.

Thought it might be my firewall and VPN, but it's working on my other machine that's on the same network with the same firewall and VPN.

I can see traffic going in and out, but the downloads themselves (and the seeds) don't have any movement.

I've had this happen twice that I remember, last time today on v3.12.

This continues to happen, I guess 5-20% chance on startup. Apparently it happens more often since a recent update. I would love to help and debug this but how? Can I safely downgrade from 3.14 to whichever version?
Windows 7 x64. Channels, DHT, IP filter enabled, no RSS.

I never had this problem so far. (Windows 7 SP1 32 bits)


I opened v.3.14, changed sequential download settings (minimum seed count, progress limit...), created 1 hybrid and 1 v2 torrent, then closed the program. After that, i replaced the executable with v2.61. As expected, when going to settings > files, sequential options aren't there, because they were not added to Tixati back then. However, v2 and hybrid torrents were showing up like v1 torrents. After closing v2.61 and going back to v3.14, everything went back to normal (sequential options and v2/hybrid torrents). It seems that old Tixati executables preserve correctly the data created by new versions.

Thank you TIX007, I will try downgrading and testing if it happens once more time.
Still present as of v3.16, Windows 7. It seems to happen after a fresh system restart. I couldn't trigger this after like 10 subsequent Tixati launches.

My experience with that bug, and I have had it few times over the years, is that it is some form of corruption in my Tixati config files. When it shows I save all my seeding torrents etc. and wipe all the TIXATI directory and install fresh. Reload everything and I am off for another couple of years. Not storing files in the completed section has helped reduce the instance of this bug. Using external drives that might be asleep also an issue. In fact I have not seen it for a couple of years, but I think it is coming back. I have become lazy and not getting rid of the completed torrents and that list has grown. Now I am seeing the first signs, like scanning takes longer, next will be frozen at 0%. Rebooting always worked for me until it did not.
BTW saving your config and installing that in the fresh install does not work because you save the bad. But I have saved small sections IE just one config, and added them one at a time until one caused a problem and then went back for a do over without adding it again. Settings, Import/export, then export and a list comes up save each one separately but heed the warning at the top and backup everything before you start.

Older threads:
2022/09/08, v3.11 Windows 7 x64, me: https://forum.tixati.com/support/7449
- different -
2014/08/13, Windows, Sailor24: https://forum.tixati.com/support/905  - had bad sectors that were freezing I/O
2017/03/26, v2.53 Windows 7 x64, Bugmagnet: https://forum.tixati.com/support/3892  - only happened when creating new torrents
____

This just happened again on Linux 6.1.25 kernel, I moved away from Windows. Same HDDs and setup. Tixati 3.17. I think it's the first time I've hit it here on Linux. I will consider downgrading Tixati next time.

Some work by the Devs was done in this area for v3.18 and it should be fixed.
If this is still happening post about it.

Tixati v3.18 Portable, Linux x86_64 (storage is on NTFS via ntfs-3g). Happened again. The scanning is completely deadlocked, not a single active torrent has been checked.

All inactive transfers such as "Complete - Offline" show 100% because they never needed a check. All transfers that should have been active are at 0%. Clicking force check only adds an entry to the event log that the action was queued and nothing happens. Comment: I assume this is how it has always been, I never took time to describe it in such detail.

The shell output is quiet and the main event log looks normal, lots of "cycled" messages although all of these transfers are waiting to be scanned. The DHT graphs are 1/10th compared to regular activity.

This problem was commonly being caused by file size mismatches that weren't being properly handled during scanning, but that was fixed for 3.18.  I tested against this problem and it looks good.

There's obviously something else that could cause this exact same issue, probably related to the availability/reliability of network filesystems.  The scanning routine is still not 100% correct.

So for 3.19, I added some more checks to the scanning routines.

If anyone still has this problem in 3.19, please let us know.  Please include the tail end of the output from Help > Diagnostics > File Activity Log right after it gets stuck.

It happened again with v3.19, Linux. The storage is local on top of encrypted volume (truecrypt unlocked via cryptsetup) and NTFS-3G and also on other plain HDDs with NTFS (multiple files and categories).
Here's the log but it is not helpful in my situation because it starts logging only once I open the window. Usually I don't notice until an hour or later when I check back and look at Tixati.

The log lines repeat every so often, no actual activity. Channels continue to work.
(Log removed by Mod and sent to Devs)

Thanks for posting the Log, it has been sent to the Devs and they are looking into it.

Happened again (I've only launched Tixati 3-4 times since). Would you like any more of these logs or should I wait for the  next version?
Transfer log for the Fopnu which was cycled at the same time I copied the diagnostics log:

(Log removed by Mod and sent to Devs)