Few versions ago Tixati started loading (and failing) additional meta file for each torrent from specific tracker.
Sorry i cannot post a torrent, this happens only for specific site's torrents.

the result is that i have a correct working torrent and a non-working torrent which just needs to be removed.
for example for a working torrent file Tixati also tries to load this one, here is the log:

 *** 28/12/2024 ***
[17:15:38]  creating transfer from meta-file
[17:15:38]  starting
[17:15:38]  initiating load from file > D:\Downloads\HKPN6xlS.torrent
[17:15:38]  loading meta-file > D:\Downloads\HKPN6xlS.torrent
[17:15:38]  stopping
[17:15:38]  stopped: Error reading meta-file : The system cannot find the file specified. (2)

Thanks a lot for this report, the dev is trying to track this down.

Just to confirm, this happens on the newest version 3.31?

A few questions, just to help narrow this down and save time:

How are you loading the torrent?  
eg.
-Directly from .torrent file that you click on in the web browser?  
-Or magnet link from the web browser?  
-Or opening .torrent file that's already on your hard-drive directly?  
-Or are you using a watched folder for .torrent files?
-Or RSS?

Do you have any of the settings in Settings > Transfers > Meta-Info turned on?

If you could post any relevant lines from Help > Diagnostics > System Log that might help a lot.

The dev has been looking at the code and experimenting for a while to try to find this, and so far no luck.  He said it might be a great time saver if you could post an example .torrent, or let us know which torrent site it's from.  I promise we I remove it from your message in the moderation queue so it will never be shown publicly.  You could also email it to support at tixati dot com.

Thanks again for taking the time to report this.

How are you loading the torrent?  

i have setup autoload folder and auto categorize for this tracker with capture transfer load tracker match, no other settings in meta-info section
i tried to reproduce with tracker match turned off and the issue is still there.
i disabled folder autoload and the issue is gone, maybe this started few versions ago with folder check improvements or torrent v2. just some wild guesses :)

sorry i cant provide more info, theres nothing more of use in system log.
is there a way to view torrents info, maybe i can find something there?

There's a new version 3.32 coming out in a few days that *might* have fixed this, and also there will be some better diagnostic logging that will be more insightful.

But if not, there's some things that might fix it or lead us to a fix/solution.

1 - Check to make sure you aren't using both the global folder meta-info watch in Settings > Transfers > Meta-Info AND a meta-info folder watch in a Category.  This will lead to the exact behavior you describe, I've recreated it myself this way.

2 - From the main Help button in the top-right of the main window, go to Diagnostics > File Operations Log, and cut/paste the section when the double-load happens into a message here or just email it to support at tixati dot com.

3 - In Settings > Transfers > Files, there's a checkbox that says "Use polling method".  Might be worth seeing if that makes a difference, but it's a long-shot at best.

I have (as i think) same situation.
1. Desktop PC with Tixati (v3.32...)
2. Mobile phone1 with Tixati 3.31...
3. Mobile phone2 with Tixati 3.32... and LibreTorrent
I share some *.zip file from Desktop PC.
Phone1 found and fully download them (in aprox. 5 minutes)
Phone2 found (after 25 minutes). First work LibreTorrent. After 5 minutes Tixati found and fully download file.
In next step i place few anothers *.zip files and wait for download (i need files in Phone2, but without Phone1 its take very long time.
After short time i see on Desktop PC red text "bad metadata" and "ignored" for both Phone1 and Phone2 for first (fully downloaded) *.zip file ....
Confusing situation. New downloads cant work because both phones now is "ignored". This status can not be changed - after few (3...5) seconds "unignore" is returned to red "ignored" again.
File is downloaded correct - no damages, no information loses ... But why now metadata is incorrect?

1 - Check to make sure you aren't using both the global folder meta-info watch in Settings > Transfers > Meta-Info AND a meta-info folder watch in a Category.  This will lead to the exact behavior you describe, I've recreated it myself this way.
NO, theres no watch on category level

2 - From the main Help button in the top-right of the main window, go to Diagnostics > File Operations Log, and cut/paste the section when the double-load happens into a message here or just email it to support at tixati dot com.

umDirectory callback h=18af30 c=8 e=0  us = 1
2990:57.661> EnumDirectory callback h=18af30 c=8 e=0  us = 1
2990:58.864> EnumDirectory callback h=18af30 c=8 e=0  us = 1
2990:59.546> WatchDirectory notification h=5d0 action=1 name=gQGNRwdR.torrent  us = 4
2990:59.546> WatchDirectory notification h=5d0 action=1 name=gQGNRwdR.torrent.part  us = 2
2990:59.546> WatchDirectory notification h=5d0 action=1 name=bbb.aaa.torrent  us = 2
2990:59.546> WatchDirectory notification h=5d0 action=5 name=ccc.aaa.torrent.part  us = 1
2990:59.546> WatchDirectory notification h=5d0 action=5 name=bbb.aaa.torrent  us = 2
2991:00.076> EnumDirectory callback h=18af30 c=8 e=0  us = 1
2991:01.287> EnumDirectory callback h=18af30 c=8 e=0  us = 1
2991:02.488> EnumDirectory callback h=18af30 c=8 e=0  us = 1
2991:03.690> EnumDirectory callback h=18af30 c=8 e=0  us = 1
2991:04.282> File::Setup({}) ec=2   us = 79
2991:04.282> File::Close() fd=0xffffffffffffffff  us = 1
2991:04.317> File::Setup({}) fd=0x4c8   us = 70
2991:04.317> File::Read(maxbytes=200000000,partialok=1) fd=0x4c8 retsz=10836 leftover=199989164  us = 30
2991:04.317> File::Close() fd=0x4c8  us = 18

3 - In Settings > Transfers > Files, there's a checkbox that says "Use polling method".  Might be worth seeing if that makes a difference, but it's a long-shot at best.
this seems to fix the issue. yeah after few tests i can confirm that this fixes it. enabling "use polling method" fixes the issue.