Content not added to channel if metadata lookup fails

[devos50]

It seems that if metadata lookup fails, the torrent will not be added to your channel. Instead, it shows an error that the meta info lookup has failed. This makes it impractical to add content to your channel that is currently not being seeded/healthy, unless you have generated the torrent yourself.

I tried it with the following magnet link:

magnet:?xt=urn:btih:55b9043a942dc075e97807b54741a0fc7740b465&dn=RandomStuff

Furthermore, after adding the torrent to your channel, there is no visual feedback that the metadata of the torrent is currently being fetched from the network. This is confusing since it might seem like the operation has failed. However, this issue is less

[ichorid]

@devos50 , to add a torrent to a channel, one should know at least the size and the name of the torrent. Until the metadata is downloaded, we don't know these.
How would you solve this problem from the UX standpoint?

[devos50]

Is it strictly required to know the size of a torrent? I would say that at the bare minimum, an info hash and name are required, both of which are usually included when adding a magnet link. Even if the name is not known, we can always display something like 'unnamed torrent'.

My concern now is that it is not clear why I cannot add this torrent to my channel. I don't even see if a lookup is ongoing or not. Only after 30 seconds, the default timeout of a meta info lookup, I get feedback. As a user, I might have moved on to a different screen then already.

One possible approach could be to immediately add the content to your channel, do a meta info fetch in the background and enhance the torrent with incoming meta info if a response arrives. This way, the user gets immediate feedback (the torrent is added to your channel) and any additional information will be added to the channel entry later. I think, however, that this solution requires quite some engineering effort.

[ichorid]

Imagine a bunch of "unnamed torrents" with "unknown size" in your channel. Humans are notoriously bad at remembering infohashes...

The only plausible approach I see for solving all kinds of background checks, etc. is to introduce a list of background processes.

Anyway, forgetting to add a torrent to a channel is not that bad. If the user notices it, they can always click on the download and use drop-down menu there to add the torrent again, this time for good.

[devos50]

Imagine a bunch of "unnamed torrents" with "unknown size" in your channel. Humans are notoriously bad at remembering infohashes...

I agree with that, but the price of requiring this information to be present in a channel entry is a latency of up to 30 second when adding a torrent to your channel (due to the DHT/HTTP meta info lookup). And the channel entry will never be added if the lookup fails, which is why I created this issue in the first place.

[ichorid]

That's why I propose forget about this issue until we implement a list of "background tasks", like some OSes do for file managers (e.g. Ubuntu Gnome file manager) and some programs do for file-related operations (e.g. Calibre ebook manager tasks list).

[devos50]

Well, I think at least the issue that a torrent of which the lookup fails is not added to your channel should be addressed somehow. Everything else discussed in this issue can be solved later.

[ichorid]

That is exactly the problem: how to add the torrent to a channel if you don't know its name or size? Also, Channels GUI does not support changing size/date of the torrent at the moment.
So, I see several ways of fixing this without creating a task list window:
a. (automatise) add "unknown/none" placeholder entries in the channel.
b. (fail) notify the user that adding the torrent failed.

The problem with "a" is we'll have to add some logic to Libtorrent Manager and/or GigaChannel manager to periodically cross/check the data between the personal channel and the downloads list, and update the torrents in the personal list with the downloaded metadata as soon as it becomes available. This becomes especially tricky to handle when we get to the territory of state maintenance, where the user, e.g. adds a single torrent to more than one channel, renames the download, deletes, re-adds it, etc.

So, "b" looks much more attractive. That's exactly what we have now (except for the failure message being non-descriptive).

[devos50]

If that change is going to be invasive, it's better to delay it to a later release then. Let's also see what users think about the channel management (in general) and based on that, we can then make further design decisions.

[ichorid]

I completely agree about getting more feedback from users. We need that, as Channels interface is completely new now.

[synctext]

Well, I think at least the issue that a torrent of which the lookup fails is not added to your channel should be addressed somehow.

Agree. Just offer a button to the user as a stop-gap measure for now. A user can click on a failed torrent and "fetch torrent name and size information" through a button.

[ichorid]

Just offer a button to the user as a stop-gap measure for now. A user can click on a failed torrent and "fetch torrent name and size information" through a button.

This is the best solution so far. It is far from perfect, but at least it does not involve changing database format, etc.