Hi,

Yes several peers have complete 100% torrents, did start/stop I did force check (that usually helps on qbittorrent), but nope still stuck.. it's not one either it's like 10 or so.. all go up to 99 and then it stops.. any tricks, I'm running 2.81 under Linux.. it should be added I used it for a week or two and it been working fine until now.. It's not like there is just one seeding peer connected but there are some with up to 16 connected peers and still can't get the last 50MB down on a 10GB torrent.. anyways tips and explanation of any settings helping it out, I do have a lot of torrents so maybe I hit some wall.  Ah yes the fieds red/green in the peer section would be nice to know what they mean.

Cheers J

PS: How can u post images?

Hi,

Ok so I stopped tixati and it took about 40min for it to finish the shutdown procedure while write incomplete files. It's about 60GB worth of it.. at the moment.

Looking at a peer for a torrent it says:

Status of peer is:
IN (GREEN)
LI (G)
RC (G)
OUT (RED)
LC (G)
RI (R)

47,8GB complete in Remote Peer, 0 remaining, 47,8G total
5700 Pieces x 8MB Complete on Remote peer 0 remaining 5700 total
173 Remove pices Useful Locally
0 local pieces useful remotely


There is about 5 or so peer with this status and yet Tixati doesn't download the last 1%...

If I can guess, something is stuck in incomplete and then it's hanging.. so question is how do you fix it..
I'm running latest version now v.2.83

I will leave it running over night now as it's already 2AM in the morning..

Jorm


PS: What does Need more blocks to repair mean under the "pieces" tab in properties?
PS: Looked at my tixati for a torrent that got stuck at 99% i.e. I copied magnetic and then I added my tixati as peer on another torrent client. Interesting to see it is that it reports my torrent to only be 93.8% in progress while in tixati it self it reports 99%. Looks like things aren't adding up.

Hi Again,

So after running for another 6h or so the Incomplete is down to more sane levels of 276MB and all stuck torrents reached it's completion. To me it looks like Tixati had issues with handling that many torrents at the same time, but might be other things such as disk speed but as I can rsync and copy files with ok performance from the same disks I'm not convinced that was the issue.

As I wrote recently in another thread here, the file subsystem of Tixati is extremely inefficient. Everything gets routed into a single disk (wherever the cache folder or "Incomplete Piece Storage Location" is located in Settings->Transfers->Locations), and is then copied from that disk out again to the eventual location within the fileset, instead of each piece and file being built in situ directly on the destination disk. This means that the bandwidth of the single cache disk becomes the bottleneck for ALL Tixati's file operations, and to make it worse it is copying all data twice instead of just once, so that bottleneck is exacerbated by the bandwidth being effectively halved.

Putting the cache folder on a slow spinning disk (which is a sane choice because all the tiny completion file updates and piece writes will kill an SSD very fast, especially as people are being forced to move to SSDs with lower and lower endurance) will really cripple Tixati when it is doing many file operations at once, and especially if some are BIG, continuous operations like writing the initial filesets or verifying files, or moving them between disks. So you might try ensuring that the cache is on an SSD, and that you NEVER store filesets there so you never have to build them or verify them on the same disk at the same time that pieces are downloading (although you will have to watch the endurance of that SSD carefully). Your worst possible scenario would be having the cache folder and the Default Download Location on the same disk. But you are still subject to disk bandwidth limitations on any other disks that you are building files on, so if those are slow, it will take time when there are multiple operations happening, as you have found.

I am also starting to suspect that the file IO of Tixati is not using the asynchronous file API, which cedes control to the OS to do the work instead of actively managing every file operation itself, in which case it is just sitting wasting time waiting for the file operation (write, read etc.) to complete. Asynchronous file operations allow the program to do other work before the OS signals that the operation is complete. That could explain why the interface is so laggy in some cases, as processor cycles in the single program thread aren't able to respond to user input or even update the interface, they are just waiting for file IO to complete.

Until this addressed by the developer, then this is expected behaviour with slow disks and many torrents, especially if some are verifying or building, as this seems to have a higher priority than pieces being saved into the filesets (which is when you get the "Trying to save..." messages which block the torrent from any further downloading until the pending operations are done). All you can do is keep filesets OFF the cache disk, and try to put the cache on the fastest (highest bandwidth and IOPs) disk you have. For most that will be an SSD now, so do keep an eye on its endurance.

Yes, my observation too. Seed a load of torrents and things also crawl to a halt near your downloads, it has a hard time dealing with the incomplete files. I love some of the aspects of Tixati, that you get a load of info and that you also can control things to the 11th degree but the way it handles disk and the last legs of downloads are well not the best. It's also where it's sad it's closed source as developers can't step in and help..  

Jorm

I've been having a similar issue, I've been moving my torrents over to Tixati because I've finally decided to stop using uTorrent, and it seems a couple files lost a bit of data in the process, so I turned them on to download the couple megabytes they needed to finish, but this one torrent has gotten stuck, with one piece saying its fully downloaded, but when I start the torrent it gets stuck on "trying to save", and then stops itself after a while with a "error opening: access denied, another program may have this file open" and the stuck piece says "need more blocks to repair. Ive tried rechecking the whole torrent multiple times, and deleting the file that wont fully download and restarting the download, and it always seems to get stuck on this same piece.

UPDATE (Same guest as above this): I deleted the whole torrent and restarted it, and that seems to have fixed the error, but still very irritating issue if the only fix is to redownload a whole torrent. This torrent was about 16 gb so it was irritating but not incredibly time consuming to deal with, I just hope I dont get something like this with a really large like 50+ gb torrent.