[Feature Request] qBittorrent support

[adworacz]

I just want to say that stig is the sole reason I haven't switched from Transmission to any other bittorrent client. It's really that good.

With this in mind, I wanted to officially open this feature request, which is to add support for qBittorrent in addition to Transmission. I know that you took steps to abstract out the Transmission integration, so hopefully adding qBittorrent support won't be a world-shattering amount of work.

Some qBitorrent API/CLI/TUI integrations already exist, but none operate on the same level wrt TUI capabilities as stig:

• API: https://github.com/rmartin16/qbittorrent-api
• TUI (by same author): https://github.com/rmartin16/qbittorrentui
• CLI: https://github.com/fedarovich/qbittorrent-cli

I have some Python skills, so I may be able to implement this my self, but taking a quick look at the existing code base makes me think there's a fair amount more work involved than I'd originally expected.

[rndusr]

Thank you.

Unfortunately, adding support for other clients isn't straightforward (yet).

You'd have to add a few abstract base classes in the client module. IIRC, the API class is supposed to provide access to a subclass instance, but there is currently no way for the user to select a client.

If you want to work on this, feel free to pester me with questions. Maybe I could work on the ABCs and when that's more mature you could add the qBittorrent subclass. But I probably won't have time in the next few months.

[adworacz]

Gotcha gotcha.

Looking at the existing Transmission support, it looks like you created your own API implementation in order to integrate with the daemon.

Since the qBittorrent API I linked above already exists, do you think it's acceptable to use that implementation or go the more manual route like what you already did for Transmission?

[rndusr]

I would've preferred an existing and battle-hardened library, but I couldn't find one that fit my needs:

1. Be asynchronous.

2. Be efficient. transmission-daemon only has a polling interface that throws multiple MBs of JSON at you. To allow for other clients, there must be a translation into something generic (e.g. a Torrent class). The existing modules I found were either too barebones (~100 lines of code) or too inefficient (huge CPU spikes when fetching a torrent list.)

It doesn't look like the qBittorrent API you linked is asynchronous, so that's a problem. One option would be asking for async support upstream.

It's definitely worth having the API in a separate project, but it's extra work. The plan was to put the whole client module into a separate project when it's mature enough and when it supports more clients. But it uses non-trivial stuff from the utils module that is also used by the main application. So these would have to be sorted out into separate projects. Or maybe there are alternatives I didn't find.

Either way, it's lots of work.

[DiagonalArg]

I know this is a longer-term project, but here is a vote of encouragement ...

I've always used Transmission, from before stig and I've stuck with it because of stig. I have recently been considering moving to qbittorrent due to the latter's option to restrict the client to a particular network interface. The point being to make sure the client stays on the VPN. That's an option Transmission doesn't have.

Thanks for all your work.

[Kabouik]

Just to bring grist to the mill, I've always been a qBittorrent user, and never really used Transmission except for a few tests. stig made me switch to Transmission a few weeks ago. It's that good.

I can't say that I would not like qBittorrent support in stig though, of course that would be nice. The search torrent feature of qBittorrent, in particular, is quite nice, but I'm not sure that it's available from the API or qbittorrent-cli (qbt). In the mean time, I use pirate-get (PyPi) to search magnets from the terminal and add them in stig, but it's restricted to TPB only.

Anyway, great work with stig. I love it and use it even on my phone.