Deleting the last 30 MB of the file also works. Deleting the whole file, rechecking, and resuming the download gets the file. The reason I think my explanation is correct is that requesting more data always works. Is there a correct way to solve this within the torrent client? It seems the clients prefer to send big swathes of data to one person rather than little pieces of data to various clients. I think this happens because other peers decide we need so little data that it's not worth it to start sending it to us. For most that will be an SSD now, so do keep an eye on its endurance.I think we've all experienced files in a torrent that get stuck at >99%, even though there are plenty of seeds. 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. 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). 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. Asynchronous file operations allow the program to do other work before the OS signals that the operation is complete. 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. 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. Your worst possible scenario would be having the cache folder and the Default Download Location on the same disk. 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). 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. 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. 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. Looks like things aren't adding up.Īs I wrote recently in another thread here, the file subsystem of Tixati is extremely inefficient. 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%. I copied magnetic and then I added my tixati as peer on another torrent client. PS: Looked at my tixati for a torrent that got stuck at 99% i.e. PS: What does Need more blocks to repair mean under the "pieces" tab in properties? I will leave it running over night now as it's already 2AM in the morning. If I can guess, something is stuck in incomplete and then it's hanging. There is about 5 or so peer with this status and yet Tixati doesn't download the last 1%. at the moment.Ĥ7,8GB complete in Remote Peer, 0 remaining, 47,8G totalĥ700 Pieces x 8MB Complete on Remote peer 0 remaining 5700 total Ok so I stopped tixati and it took about 40min for it to finish the shutdown procedure while write incomplete files.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |