qBittorrent-nox RSS downloader shows bogus filter results when using square brackets

[kobuki]

qBittorrent & operating system versions

qBittorrent-nox: 4.4.3.1 x86_64 Operating system: Debian 11 Qt: - libtorrent-rasterbar: 2.0.7

Using static build from https://github.com/userdocs/qbittorrent-nox-static/releases/tag/release-4.4.3.1_v2.0.7

What is the problem?

When using a filter expression like "[tag] series title 1080", the "[tag]" token seems to be ignored and only the rest of the words are in effect as filter. If I remove the starting bracket, like: "tag] series title 1080", then it works correctly. Moving "[tag]" around in the expression doesn't make a difference. Using default filter settings, no regex.

The problem doesn't exist on Windows 10 when accessing via the web GUI. Filtering works as on normal desktop GUI. The issue only exists with qBittorrent-nox .

Steps to reproduce

See above.

Additional context

No response

Log(s) & preferences file(s)

New, default setup, no changes except for setting up an RSS feed and a filter.

[userdocs]

Taking a guess here but

1: The RSS patch is working it seems so that's a bonus.

2: Looking at this line i think you need to use PERL compatible regex, meaning you can't just use [ ]. Maybe the main GUI does it differently? https://github.com/qbittorrent/qBittorrent/blob/0e989185ce3ca106bfbbc2f043778b53d84315bd/src/webui/www/private/views/rssDownloader.html#L763

So looking here this all seems to be inline with your regex experience.

https://regex101.com/r/zyd8iv/1 https://regex101.com/r/WGSDse/1 https://regex101.com/r/otx7QC/1

Try doing this and escape the special regex characters?

https://regex101.com/r/mVzrIr/1

\[.*\]

Does this work?

[kobuki]

Again, I'm not using regex. With regex, tokens are used in strict order, whereas not using regex just uses all the words in conjunction for filtering, regardless or order.

As I've noted, the web UI of the Windows desktop app works as expected. I haven't tried the Linux version, but I will if it helps. Only the nox version on Linux has the issue so far (that's what I normally use nowadays).

[userdocs]

I am seeing this via journalctl but i don't see it in the qbit logs.

 QRegularExpressionPrivate::doMatch(): called on an invalid QRegularExpression object

[kobuki]

Thanks for the heads-up. Maybe it's relevant, maybe it's not, I'll check later. Could it be that qbt translates the free text search to regex searches? If so, the message could be relevant.

[userdocs]

So as far as I understand it's a wildcard match, not regex but not plain text either. You can see from these examples the brackets are not really needed.

And escaped with regex as they should be.

But there may be a unique linux character issue with opening square bracket if it works on windows but not linux.

That's something the devs will have to

[kobuki]

Your first non-regex examples shows the same error. A difference is that I usually use the "[TagWithNoSpaces]" token, like this random example: "[HachiRoku] Made in Abyss - Dawn of the Deep Soul". Yours is 3 tokens enclosed (virtually) with square brackets, but the error is the same, I think.

[userdocs]

I don't know exactly how it's working. I'd need someone to confirm how [ ] are treated in this wildcard matching. All i see is this.

Though if you read here, they can be used for list matching.

https://topic.alibabacloud.com/a/linux-shell-wildcard-characters-metacharacters-escape-characters_1_28_30150430.html

[userdocs]

Here it behaves like a list match [H] and [Hu] match where Hu does not. I'm not sure it's doing what you think it's doing.

[kobuki]

Yeah, it's even worse. [] characters seem to have a random effect. In Windows or in Windows with web UI, all works as described. No issues with square brackets, they're treated just like any regular character, as expected. (In non-regex mode.)

[userdocs]

It's working fine as list matching. As you see in the last one because h[anything]ndu has [i] to match Hindu

[kobuki]

Maybe, but it shouldn't. [ and ] should behave per docs - as regular character, and consistently over all platforms and UI variants.

[luzpaz]

What's the status of this ? Still reproducible ?

[kobuki]

Yes, still reproducible in the same way as in my OP.

[luzpaz]

@kobuki full About info please

[kobuki]

Screenshot attached, do you need anything more?