When adding a torrent, offer directory suggestions

[scottopell]

In the rqbit web UI, the download interface offers a destination path which defaults to the download directory.

As a user, I try to keep an organization system - there is /home/rqbit/downloads/audio and /home/rqbit/downloads/other and /home/rqbit/downloads/video, and within these I have more subdirs for more specific filing.

When adding a torrent, I may not always know the exact folder I want to put it in, but I know there is some folder and I currently need to go look up my directory structure elsewhere.

I'm interested in adding support for "suggested directories" and a few other quality-of-life improvements around destinations, and wanted to check if these are worth pursuing to get them upstreamed here.

I started on an implementation in this branch that adds another API called dirPreview currently, and it returns the current destination and a few directories with it.

The UI is still a bit rough so I definitely have some work to do there, and I don't love the naming dirPreview for the API, but wanted to check and see what appetite there is for this change.

[ikatson]

Hi! Implementation aside (didn't look at it yet), I'm rather neutral to this feature due to a mix of up and downsides.

Upsides: I can imagine the UI evolving to have a directory picker. Which is nicer than typing the path.

Downsides:

• this adds complexity to rqbit.
• rqbit was born as API/CLI first tool, and this feature in API is UI-only and only needs to exist there to support it

I'd imagine there must be some HTML way to add a directory picker? That would alleviate all my concerns as this will stay UI only.

[scottopell]

I'd imagine there must be some HTML way to add a directory picker? That would alleviate all my concerns as this will stay UI only.

I'll look into this, but my guess is that any browser-native options would only be able to work on a local filesystem, where the browser can query the FS to list paths.
I run rqbit remotely and use the web interface to access a remote machine to add/remote torrents, so all my paths are relative to the remote FS.

I have a proposal that may address your concerns of having UI-only features in the UI as well as solve a 2nd problem I'm having.
Let me briefly describe my 2nd problem -- the "Adding an old magnet" problem:

When I try to add a magnet link for an old / low-seed count torrent, the current usage of a ListOnly request to request metadata about the torrent takes forever. In my environment, I'm running via an authenticating http-proxy that has a 60s timeout (that I can't control), so when adding such torrents via the web-ui, the ListOnly request hits 60s and times out. So I'm not actually able to add torrents that can't be listed (via the web-ui)

So, what if, instead of making the ListOnly request a required UI step for adding a torrent, the torrent was added as a managed torrent up-front, and then as the user selects a destination for it, what is happening behind the scenes is a series of updates to the existing torrent's output_folder?

Here's a proposed workflow:

1. User clicks add-torrent button, pastes the URL and clicks "Add"
2. This sends an AddTorrent request without ListOnly to create a ManagedTorrent.
3. The response has a new field DirPreview in the TorrentResponseDetails giving "directory preview" data about the current output_folder.
4. As the user sets a new output directory, it interacts with a new api POST /torrents/{id_or_infohash}/update_destination, which can respond with a fresh TorrentResponseDetails

If this is interesting, I can try to start off by adding POST /torrents/{id_or_infohash}/update_destination in order to split up the work a bit (and get myself more familiar with the code)

[ikatson]

I run rqbit remotely and use the web interface to access a remote machine to add/remote torrents, so all my paths are relative to the remote FS.

Ah of course! That in itself is enough to alleviate my concerns. It's plain impossible to list dirs on the client in your case, and the case is legit. So I'm for for the original proposal conceptually.

As for the second part, by a brief look, I didn't understand this: what stops you from just updating UI to add a torrent without list only by just providing magnet+ output folder?

The only reason listOnly is there now is so that you can select the files you want. But you can do that after adding the torrent too anyway.

Sorry if not clear I'm on phone

[scottopell]

As for the second part, by a brief look, I didn't understand this: what stops you from just updating UI to add a torrent without list only by just providing magnet+ output folder?

Yeah, what you suggest is probably the simplest thing to start with, I like it.
Then I separately want a way to update the destination directory in the web-ui for a torrent that is already added.

So I'll start with those two changes:

1. An alternate way in the UI to add a magnet link and output directory without waiting for ListOnly to return.
2. Add an api to update output folder of an existing torrent

I'll revisit this issue once I get to the UI component to "set new output dir", because I have a feeling that could be utilized in the existing AddTorrent modal and augmented to solve this current issue as well.

[ikatson]

The first one is good, but UI alone won't be enough, you need to update the backend to allow adding torrents without waiting for them to resolve the magnet.
Ideally, "resolving magnet" would be a new torrent state but that's too big of a refactor. Maybe spawn a tokio task to add_torrent() in this case...

As for the second one, changing output folder on an already managed torrent sounds pretty error-prone. The only sane way to attempt it is to pause, rename every file, then unpause. You will also need to update the persistence database. But anything in this process can fail mid-way, and then the torrent will be left in a screwed up state. Cleaning up that mess will be a much bigger problem. So nasty that I'd abandon the whole idea at inception. Unless you see an easier way!

[scottopell]

Added #286 to discuss the changes needed adding a torrent without resolving magnet to split off discussion over there.

Rename isn't something I have an urgent need for, so I'll punt on that for now, you're right, it seems like that's a fairly delicate operation and not much benefit at the moment.