Some years ago I posted a bug report about the problem with the way Tixati was handling abandoned pieces that got dropped by peers. At the time, when a peer (in my case, the only one) disconnected/reconnected, the old versions of Tixati would ignore all the incomplete pieces already half-downloaded and allow the peer to start yet another new piece, only for it to drop out yet again... and after many rounds of disconnection/reconnection with this peer I was left with a page of only incomplete pieces instead of any completed pieces, that could have been achieved if the scheduler had allowed (or forced) the peer to reconnect to an existing incomplete. It was intensely frustrating, as it was breaking the whole point of a torrent client aspiring to COMPLETE downloads, not scatter-gun downloads to the point that nothing was ever completed despite large amounts of data being received.

I've been examining the behaviour of a very large download (400MB) over the last few days, and I am very happy to say that behaviour has definitely been fixed. Abandoned incompletes are now (as I suggested back then) queued very highly so that they are reconnected to a peer rapidly, not left hanging around. There were very few incomplete pieces left queued even when some of the peers were dropping out frequently, all were quickly reconnected. :)

However, watching the piece completion closely, I've noticed another odd piece of behaviour, if not exactly a bug... it's almost the logical flipside of the original problem I reported.

If I set a file as high priority (or very high, or ultra high) then I am asking Tixati to prioritise that download over others (duh!). As expected, it queues more peers to complete the file. Some will be faster than others, so the majority of the file gets downloaded, except for the last few pieces, which were allocated to slower peers. OK, but... sometimes they are MUCH slower, or they actually stop sending data without disconnecting. Since Tixati seems to prefer to allocate only one peer to a piece, that means this non-sending peer blocks that piece from completing, and therefore blocks the file that I've asked to complete with a high priority, while all those nice fast peers that I'm lucky to have are merrily completing other pieces/files that are NOT marked high priority!

Sometimes I see that Tixati allows more than one peer to complete a piece, but I don't know what the policy is or how to alter it (if it can be changed) to encourage that. What I'd like is for the current completion policy to be tweaked so that if Tixati detects that a peer on a High/Very High/Ultra High priority has stalled sending data, or the peer connection is under a threshold (say 10KB/s) that will obviously block the piece and file from completing in a reasonable time, it allocates extra peers to help complete the piece quickly AS REQUESTED.

What I'm asking is that High priority (or better) means including the rate of completion, not just the speed a piece is allocated to a peer. Watching my piece completion closely, I've frequently seen pieces "grabbed" by a peer/seed that then sends little or nothing, blocking it completely. I've had to manually disconnect those non-sending peers to allow the piece to be requeued, at which point it rapidly gets reconnected and completed (thanks to the fix I mentioned at the start, which I'm very grateful for). But I shouldn't have to do that - Tixati should be smart enough to do that for me, or add peers to the piece, if that blocking peer is sitting on a piece of a file I've marked I want downloaded with higher priority, but it takes far too long to wait for it to disconnect, and of course it might not.

Related request: in the file list tab of a downloading torrent, have some method (pop-up on mouse-over? or a column that could be added) that shows which range of piece numbers are included in that file. When a file is blocked and doesn't complete, it would be helpful troubleshooting information to allow you to see the state of the pieces of that file in the piece tab, by identifying the number range. In an ideal world there would be a back-trace on the pieces too, to show which file they are a part of, but that's less critical.

Thanks for your attention to this.