New api support?

[fedarovich]

New api support?

[fedarovich]

Hi,

I have figured out why it crashes on qBittorrent 4.2. Basically it's quite easy to fix, but there are several options how to do it, so I have to decide which one I should choose.

I'll try to release the fix this week.

[fedarovich]

@Ingvix I was able to reproduce this issue on Linux with qBittorrent 4.2 with alternate UI enabled. I know how to fix it, so I will likely release a version with the fix this evening.

[fedarovich]

Hi.

Yes, I will add support for the API 2.3.0 used by qBittorrent 4.2.

I guess the current version will still work with it, although some features won't be available. At the moment the qbt CLI supports both legacy API versions and the modern ones (up to 2.2.0). Though there may be some breaking changes. I haven't tried it with qBittorrent 4.2 beta yet.

Did you face any issues when using qbt CLI with qBittorrent 4.2? What are they?

[Jorman]

Hi, I had to switch back to normal 4.1.x because I've to adapt to many scripts in order to make it work, and some of are not mine :)
So for now I don't have tried qbt cli with new 4.2 beta.
Do you need some test?
Maybe is not the right time to make changes
https://github.com/qbittorrent/qBittorrent/wiki/Web-API-Documentation#api-v230
is all pending for now

[Ingvix]

I started getting 500 (Internal Server Error) after updating qBittorrent to 4.2. Could it be due to API changes or did I mess up something else?

[fedarovich]

Ok, I see. I will try to run unit tests with 4.2 beta.

[Ingvix]

Any estimate yet how long it might take? Qbt is a bit necessary for my setup so I was wondering if I should downgrade my qBittorrent for a while if a fix is not coming anytime too soon.

[Ingvix]

Alright, thanks for the update.

[fedarovich]

I've uploaded version 1.5.19322.1. It should work with qBittorrent 4.2 in general, though there still may be some partial incompatibilities. If you face some more compatibility issues, please do not hesitate to contact me.

The full compatibility for qBittorrent 4.2 including the new features will be added in qbt 1.6. I'll start working on 1.6 after qBittorrent 4.2 is released.

[Ingvix]

I'm still getting the same internal server error with 1.5.19322.1. Might the cause be something else than the API change?

[fedarovich]

@Ingvix What commands do fail? Could you also send me the error stacktrace, please? To get the stacktrace you can run a command with the --print-stacktrace option, e.g.

qbt torrent list --print-stacktrace

[Ingvix]

Pretty much all of the ones that try to connect to qBittorrent, namely I tried torrent list, global info and qbt torrent check [hash]. Stacktrace they give also looks pretty much the same.

qbt torrent list --print-stacktrace
QBittorrent.Client.QBittorrentClientRequestException: Response status code does not indicate success: 500 (Internal Server Error).
   at QBittorrent.Client.Extensions.HttpClientExtensions.EnsureSuccessStatusCodeEx(HttpResponseMessage message)
   at QBittorrent.Client.Extensions.HttpClientExtensions.GetStringAsync(HttpClient client, Uri uri, Boolean returnEmptyIfNotFound, CancellationToken token)
   at QBittorrent.Client.QBittorrentClient.GetLegacyApiVersionPrivateAsync(CancellationToken token)
   at QBittorrent.Client.QBittorrentClient.<>c__DisplayClass10_0.<<-ctor>b__1>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at QBittorrent.Client.QBittorrentClient.PostAsync(Func`2 builder, CancellationToken token, ApiLevel minApiLevel, ApiVersion minApiVersion)
   at QBittorrent.CommandLineInterface.Commands.ClientCommandBase.AuthenticateAsync(QBittorrentClient client)
   at QBittorrent.CommandLineInterface.Commands.AuthenticatedCommandBase.OnExecuteAsync(CommandLineApplication app, IConsole console)
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.InvokeAsync(MethodInfo method, Object instance, Object[] arguments)
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.OnExecute(ConventionContext context)
   at McMaster.Extensions.CommandLineUtils.Conventions.ExecuteMethodConvention.<>c__DisplayClass0_0.<<Apply>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.<>c__DisplayClass142_0.<OnExecute>b__0()
   at QBittorrent.CommandLineInterface.Program.Main(String[] args)

[fedarovich]

@Ingvix Hmm, it's very strange. I've checked these commands and everything works.

Could you please check that you have correct qBittorrent URL specified (including port)? I was getting the same stacktrace in case of incorrect URL.

[Ingvix]

My URL is correct. I'm executing the commands in the same system as qBittorrent is running in. Both http://127.0.01:8081 and http://192.168.1.185:8081 return Internal server error though in browser I can access the WebUI just fine with those addresses.

[Ingvix]

Any further debugging ideas? I tested setting webui to only use 192.168.1.185 and it refused connections from qbt on 127.0.0.1 and the former gives the same internal server error. So it's there but for some reason something goes wrong.

[Ingvix]

I just pinpointed the problem. It seems that it couldn't handle the new version of AndersMalmgren's alternative WebUI which included the management of RSS feeds and autodownloads. More about this in this issue: qbittorrent/qBittorrent#453

I understand if you're not interested taking this into account in the developement as it is unorthodox usecase but I just wonder if a fix would really require that much effort. The previous version of that altUI worked without problems with qbt-cli. If you're interested in taking a look, the altWebUI can be achieved by using AndersMalmgren's "qBittorrent-master\src\webui\www" as the alternative WebUI directory and adding "qBittorrent-master\src\icons" as 'images' dir in both 'public' and 'private' directories in the 'www' directory.

I believe I can revert the altUI to an earlier version without problems. The new version doesn't offer that much more functionality so I don't mind for the time being. It just allows adding new RSS feeds, which I don't do that often, from the WebUI.

[Ingvix]

Hmm, it seems to get internal server error with earlier version as well. Not sure what should I do now. Now I actually hope you at least take a look in Anders' repo to see if there'd be an easy workaround.

[Ingvix]

Further testing showed that I get internal server error even if the altUI is identical with the regular UI so I think problem doesn't actually lay in the changes in the altUI but in that it's enabled at all. I hope you can investigate this further. Maybe this needs a new issue?
EDIT: On the other hand this wasn't an issue with 4.1 so maybe this is still about the api change?

[fedarovich]

Ok, thank you for your investigation. I'll try to figure out whether it is possible to make it work with the alternate UI.

[Ingvix]

So, any news on the issue?

[fedarovich]

Well, I have tried many different scenarios including custom UI, but I cannot reproduce this issue with qBittorrent 4.2.0 release version.

Today I will release a version with improved compatibility with qBittorrent 4.2, but I guess I won't fix your issue.

[Ingvix]

So when you activate alternative WebUI you can still use qbt just fine? I' guess I better try out some things myself then, like if recompiling and -installing would fix the issue.

[fedarovich]

Yes, everything is fine in my case. Though, I have one more thought: I've tested it with qBittorrent on Windows, but it looks likes the source code for Unix-like platforms has some additional checks. I will try to reproduce your scenario Linux, when I have some free time.

[Ingvix]

Alright, thanks. I'll be waiting.

[Ingvix]

I can confirm that the latest version fixes the issue.

[fedarovich]

OK, so as the version 1.5.19350.1 works well enough with qBittorrent 4.2.0, I will close this issue.

The full support for the new features available in qBittorrent 4.2.0 (e.g. Tags) will be available in version 1.6.