Changes to qBittorrent WebAPI breaks Mylar integration

[Arathen]

qBittorrent has recently removed legacy WebAPI support from their client, which has resulted in several applications (including Mylar) being unable to send snatches to it for download.

At this point, this is limited to clients running qbt from source, but the change will soon make its way through to the stable release which will impact all qbt users.

PR which broke integration is https://github.com/qbittorrent/qBittorrent/commit/2ce3aa9731aaf530b4228e5bd3e8e226986e2f8f

Log:

`17-Jan-2019 13:01:25 - INFO :: mylar.torsend2client.854 : SEARCH-QUEUE : matched on Catwoman 17-Jan-2019 13:01:25 - DEBUG :: mylar.torsend2client.863 : SEARCH-QUEUE : filename for torrent set to : /home/mylar/mylar/cache/Catwoman_7_2019.torrent 17-Jan-2019 13:01:41 - DEBUG :: mylar.dbUpdate.85 : Thread-14 : Refresh sequence set to fire every 5 minutes for 7 day(s) 17-Jan-2019 13:01:41 - DEBUG :: mylar.job_management.3492 : Thread-14 : ReScheduled job: DB Updater to 2019-01-17 02:06:41 17-Jan-2019 13:01:41 - INFO :: mylar.dbUpdate.353 : Thread-14 : Update complete 17-Jan-2019 13:02:26 - DEBUG :: mylar.torsend2client.1092 : SEARCH-QUEUE : [torznab] Saved torrent file to : /home/mylar/mylar/cache/Catwoman_7_2019.torrent 17-Jan-2019 13:02:26 - INFO :: mylar.connect.22 : SEARCH-QUEUE : http://qbt:9090/ 17-Jan-2019 13:02:26 - ERROR :: mylar.connect.25 : SEARCH-QUEUE : Could not create qBittorrent Object This wrapper only supports qBittorrent applications with version higher than 3.1.x. Please use the latest qBittorrent release.

17-Jan-2019 13:02:26 - INFO :: mylar.torsend2client.1169 : SEARCH-QUEUE : Connected to qBittorrent! Will try to add torrent now! 17-Jan-2019 13:02:26 - INFO :: mylar.load_torrent.58 : SEARCH-QUEUE : filepath to torrent file set to : /home/mylar/mylar/cache/Catwoman_7_2019.torrent 17-Jan-2019 13:02:26 - ERROR :: mylar.torsend2client.1180 : SEARCH-QUEUE : 'TorrentClient' object has no attribute 'client' 17-Jan-2019 13:02:26 - ERROR :: mylar.searcher.2390 : SEARCH-QUEUE : Unable to send torrent - check logs and settings (this would be marked as a BAD torrent if Failed Handling was enabled) `

Cheers.

[evilhero]

I don't have a working qbittorrent client to test the new api against but it looks like we need to be passing a cookie now with all the subsequent commands after the initial logon.

Unfortunately, as you indicated, the stable release is still using the legacy version - so this might have to wait until they package the new api changes into the stable release before it can get fixed correctly. Or unless someone else wants to take a stab at this one...

[Arathen]

The new WebAPI was introduced with qbt v4.1.0 in May 2018 so it has been available in all stable release clients since then (we're at 4.1.5 currently). Both old and new APIs have been supported side by side since then, with the old one only now being removed from source altogether. This old API removal will make it into stable when v4.2.0 drops, but theres no real suggestion as to when that will be.

I have no python skills to speak of sadly, so im not able to help with this, as much as I would like to :(

[evilhero]

Huh, shows what I know about qbittorrent. I couldn't find any documention on the change in the latest release, which is why I (wrongly) assumed it wasn't in there. Good to know it's a side-by-side integration. I'll try and take a stab at this and see if I can figure it out...

[Arathen]

OK so I was playing with the idea of taking a crack at this to see if I could teach myself some rudimentary python and I've quickly come across a line-in-the-sand issue. To put it bluntly, the qbt Web API is a schizophrenic mess. There have been three (major) versions of it in the last couple of years, documented here, here and here:

https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API-Documentation-(qBittorrent-v3.1.x) https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API-Documentation https://github.com/qbittorrent/qBittorrent/wiki/Web-API-Documentation

It looks like the current qbt API implemented in Mylar is the first (oldest) one.

If I implement the newest qbt API, then it will work with all versions since 4.1.0 (May 2018), but none before that. Is it acceptable to draw that line? It looks like that has happened once already because this exists in the code currently:

This wrapper only supports qBittorrent applications with version higher than 3.1.x. Please use the latest qBittorrent release.

I can just bump that minimum version. That would be my preference.

Alternatively, I could try to maintain both old and new qbt API versions using a user-specified config variable and a bunch of if/else statements, but that feels dirty to me because if statements come with a processor overhead,

But its your app @evilhero so ultimately your call to make. I'll abide by whichever way you want to go.

[evilhero]

I had this working a few days ago, but just the authentication part. It would authenticate fine, but was failing on the add portion so I had to scrap what I had done thus far and just haven't had a chance to revisit it just yet.

If you were going to do a PR for this particular item, I would suggest going with the latest API version since the others have different methods therein. So, 4.1.0 would be the minimum API version I would code against going forward (unless they change the API again)...

[Arathen]

Awesome. In which case im almost done with it. Ive got auth and add working, so the rest of it is just checking for additional API paths. I'll try to get a PR raised for it today/tomorrow.

[Arathen]

I believe this is fixed by https://github.com/evilhero/mylar/pull/2196 (and I learned some Python along the way).