Add export torrent functionality to WebUI API

[ai4739]

Suggestion

My particulars:

• Running QBT 4.5.2
• Linux 6.1.0-3-amd64 SMP PREEMPT_DYNAMIC Debian 6.1.8-1 (2023-01-29) x86_64 GNU/Linux

My client manages thousands of torrents across many trackers. I depend on the WebUI API to "make things right" when I run into filesystem problems or non-related libTorrent problems. I don't always have time to recheck hundreds of torrents ... it's easier to programatically reseed torrents that develop their own "issues" for whatever reason. I'll call these "distressed" torrents ... torrents that get stuck re-checking, missing files, or suffer from renaming issues (just a few off the top of my head). I know the files are "good," I just want QBT to resume these torrents (read: reseed) without the extra overhead of re-checking.

About a year ago, I was depending on the BT_Backup folder to [programatically] copy distressed torrents to a directory for reseeding. This worked perfectly until the 4.4.x+ branch, which moved the tracker information into .fastresume files and I was no longer able to just copy the .torrent files to reseed. So, I dug deeper into the WebUI API and extracted the tracker information and save path for my distressed .torrents before reseeding. All was good in the world.

In a most recent migration to a new LTS box, I noticed a small percentage (<1%) of my distressed torrents now had v2 hashes as well as the v1 hashes. These no longer worked with my scripts because the .torrent files simply do not exist in BT_Backup. But the 4.5.x branch added an Export .torrent... option which allowed me to quickly snag the small number of distressed [v2-hashed] torrents to reseed. The only problem is: I had to handle the v2-hashed torrents manually.

The Export .torrent... functionality is most welcome, thank you :) ... but please consider adding this to the WebUI API so we can automate the healing of distressed torrents.

Use case

I have a number of distressed torrents (torrents that are stuck re-checking, stalled, or errored due to filesystem IO) that I would like to reseed programatically.

Adding /api/v2/torrents/export?hash to the WebUI API would allow automation of this process.

Ideally, parameters to control the exported .torrent's name and location:

• name, i.e. current implementation/default that exports using the Name field
• v1hash, i.e. name the exported file <v1hash>.torrent
• v2hash, i.e. name the exported file <v2hash>.torrent
• export_folder, i.e. where to save the exported .torrent

All of my WebUI API interaction involves the v1hash (and this hash is already extensively implemented in the API), but v2hash would allow for some future proofing, I guess...

Extra info/examples/attachments

No response

[thalieht]

Adding /api/v2/torrents/export?hash to the WebUI API

It seems it's already there. If it helps this is how the WebUI uses it

qBittorrent/src/webui/www/private/scripts/mocha-init.js

Line 987 in 77bd09b

exportTorrentFN = function() {

[bofalot]

Thanks for this pointer. I was looking to achieve the same as the OP, exporting .torrent file programatically.
I've been able to use the /torrents/export endpoint to achieve just this 👍