by
Nbr761 on 2024/01/07 12:35:04 AM
The title say it all ,
There are other posts in this forum about this issue, the ones I have read so far only address how to deal with this issue on effected pieces, not how to prevent this issue from occurring to new pieces when it keeps happing.
This has happed to me on both linux distributions and windows installs for a while now 2 years+.
The only interesting thing i have noticed so far is that these problematic pieces tend too show up at time when the local network is at or near capacity. Most piece repairs work how ever some times the only way to clear them is by shutting down tixati and deleting all the incomplete-pieces folders.
I can confirm this don't happen when using qbittorrent or biglybt, and the hardware is not experiencing any instability.
Im looking for a more permanent bug fix for this issue or recommendation for changes to tixati settings that stop this from happening.
by
Nbr761 on 2024/01/12 01:08:04 AM
TLDR; Check for packet corruption (not loss) and replace bad hardware.
memtest86, was a pass.
after a confused me did some other random test one did finally fail, iperf. After changing network cables, I removed the faulty cable.
I was able re-create this issue by using a application called clumsy by jagt and setting it to a [1~0.1]% tamper with redo checksum NOT enabled.
Now why was a rare few temp torrent piece unable to be repair until they where deleted while restarting tixati, just bad luck maybe.
Given some other strange things I had spotted in the past, like peers being blocked for sending bad data on private tracker torrents <--- should have clued me in sooner on what was up.