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)

Linux with v3.24 happened after a cold boot. I'd say it mostly happens only after a fresh system boot. I'm in a seeding only scenario, I haven't added or changed any torrents in ages.

When I have time I will try to test if loading Tixati with all file caches emptied makes it more reliable to reproduce.

Ok, my torrents don't stay at "Scanning 0%", they do get scanned one by one eventually and reach 100% status. But it is very slow and happens after every restart, which seems pointless.
From the time it takes I assume it's not checking file content, just file listing and possibly size. But even that is a very slow operation with a network drive over wi-fi and torrents that have tens of thousands of files. It really shouldn't be done every time. It is fine to check the file is there for single-file torrents, but for multi-file torrents it should only check the base directory or perhaps a single file inside it, not more, at least at initialization time. The rest should be assumed OK if cached torrent state was OK before the restart, and re-checked as needed only when the files actually have to be accessed, i.e. when actually seeding or downloading them.

"It is fine to check the file is there for single-file torrents, but for multi-file torrents it should only check the base directory or perhaps a single file inside it, not more, at least at initialization time. The rest should be assumed OK if cached torrent state was OK before the restart..."

For most people that won't cut it. These are sanity checks on the state of the files you're seeding! It's not doing a complete hash re-scan - I am going to assume that the filesize and the time-stamp (last altered) are checked against Tixati's database of active torrents, so it knows if anything has been changed since it last confirmed they were complete. I wouldn't expect anything less!

Your other option (checking only when files are needed) might work, but are you really prepared at that stage to have torrents drop out of action if there has been an unexpected change? Doing it at start-up at least allows these basic checks to happen before you begin to saturate the disk's own internal bandwidth with active downloading/seeding, which would make it take even longer.

Since the discussion is about start-up, the issue here is most likely using drives that are still asleep, so need to spin up before anything can be checked. And they may be slower drives (shingled?) or network-connected too. Or connected over USB - I have a USB expansion caddy that takes ages to copy to/from despite having fast disks in. That's all great for archiving but probably not for active downloading/seeding.

Storage solutions are always designed in tiers/layers so that active data is close-connected on fast drives and cold data is on slower mediums with higher latency. Can you not seed from faster, closer-attached disks then move it to slower storage when completed? SSDs are ideal for small seed sets, but if you're hammering spinning disks with vast amounts of torrent data needing so long to check on start-up then you probably need to be using server-quality or RAID-edition hardware like WD Golds anyway... not home-standard hardware with far lower internal bandwidth. That might help mitigate these issues. ;)

I said it's about network drives. And it's on torrents that almost never get any action/peers. They block newer and known active torrents for several minutes at each startup. It is completely pointless.

> but are you really prepared at that stage to have torrents drop out of action if there has been an unexpected change
Well duh, I am. That's what I want. I want it to not drop out my good torrents for minutes at every startup, but drop out the once-in-a-blue-moon externally-modified/bad torrent when it happens. Why are you acting like it's such a wild idea? Are you constantly going around deleting things in your torrents that you need to have Tixati fix your mess at every startup? Well, I don't.