I loaded a torrent via magnetlink and (unfortunately) didn't check the diskspace required for it before it started allocating. More worryingly, neither did Tixati - this should be a basic sanity check on a torrent start! When it ran out of diskspace, the allocation errored out, but while the log says the torrent is stopped, it doesn't show anywhere in the list of loaded torrents/current transfers. It's been sent into transfer limbo...

This is now a big problem, as I CANNOT access it to start it or stop it, or even remove it. I thought restarting Tixati might rebuild the transfer queue and show it, but it doesn't. If I manually add the same torrent via the downloaded .torrent file, it offers to merge the trackers, but that still doesn't force it back into the queue, so I'm stuck - not only can I not delete it, I can't even add it fresh that way. There's no way visible to remove it from the active list of torrents in a config file in Tixati's working directory and no other mechanism I can see other than the main torrent transfer window to manage the list of active torrents. I can't see any troubleshooting option that might force Tixati to sanity-check its own internal data structures and detect the mismatch between the torrent being considered loaded/stopped and not being present in the visible transfer queue.

So I am reporting this as a bug, as I now have a ghost torrent that cannot be started or removed as there is no way of accessing it from the interface, or by removing it manually in a config list. (I presume it's in all that binary config data, which makes basic management by the user a total PITA - another user asked recently for human-readable and easily editable config files, and this is WHY that is such a good idea.)

Apart from fixing the bug that prevented it from showing in the transfer list originally (as stopped) due to the pre-start allocation error, a solution would be to add a check for such ghost torrents when the merge trackers option comes up (loading a .torrent file manually) so that it can be inserted correctly in the queue window at that point. Otherwise, I hope there's a way to add some bug-checking to detect these ghost torrents in the next release, so they are either purged properly from the queue or added correctly to it and removed from transfer limbo. Please consider this urgently.

Actually, this is a bigger problem than I thought. For some reason, since upgrading to v2.61, I've noticed torrents disappearing from my list of active transfers. I've assumed this might be my fault, as my mouse is playing up and sometimes double-clicks, which fires buttons under the active dialog when I close them when I don't want them to. This could accidently delete torrents if I'm not careful.

But the log under the "Home" button definitely shows two transfers I have "lost" loading on Tixati startup, as well as the one noted above that I now can't see - so I have three "ghost" torrents, not just one, that I cannot start, stop, delete or otherwise manage from the interface. Two are stopped that cannot be started (or removed), and one will likely never complete - but obviously I cannot now tell which individual files in it are 100% downloaded as I cannot access the properties for it, which is deeply annoying. I don't even know if this active "ghost" torrent is actually still downloading (or trying to) silently in the background.

So quite apart from the bug being triggered on an initial allocation error, something ELSE is making items simply disappear from the transfers list into an inaccessible oblivion. I doubt it's at random, but there MUST be a mechanism found urgently to restore them to visible in the list.

Just noting that doing a downgrade to 2.58 did NOT solve this - I thought that the older version might parse the config data for these ghost torrents differently on loading, but no. Once the torrents are "lost" they seem to stay "lost". It might, though, stop any more from suddenly disappearing on me. :(

This has really left a sour taste in my mouth for a long-time devoted user of Tixati. I just hope that reporting this/these bugs here isn't pissing in the wind, since there's never any feedback from developers on bug issues or feature suggestions they are working on...

OK, issue solved. It turns out the problem really was my mouse, in a way... I must have inadvertently clicked one of the row of status buttons, and I'd managed to turn off listing offline torrents without noticing.

I didn't even know that was possible (as it's not something I'd ever want or need to do) - in fact, I'd assumed those buttons were for stopping and starting individual torrents, not for changing the listing, as the style (like cassette tape buttons: stop, play etc.) clearly suggest ACTIONS, not the status of items (stopped/started) to act UPON. It's a definite problem with having a "clever", non-standard, button-infested GUI that doesn't duplicate functions in a normal menu like most software, which is where you'd normally go looking for options to change in case of problems... <sigh>

I'm getting file allocation errors as well, I do have enough space, but it is a very large multifile torrent. about half way through allocation checking (I assume Tixati writes a dummy file that takes up the proper amount of space as it's a relatively slow process) it kind of poops out /crashes.
 Selecting only several files from the torrent seems to work.

Is this just an echo chamber to ruminate on one's thoughts? why are there no responses to your posts?

what OS?
how large is the torrent?
you should post the magnet link of the torrent so the devs can see whats going on.