NZBFinder TV/Other gets filtered out

[downey-lv]

Is there an existing issue for this?

• I have searched the existing open and closed issues

Current Behavior

My search results contain 4 TV/Other (5999) results, 5999 are allowed in Prowlarr, but are filtered out nevertheless.

Expected Behavior

Results from 5999 appear as allowed

Steps To Reproduce

No response

Environment

- OS: Windows Server 2022 Standard
- Prowlarr: 1.10.1.4058
- Docker Install: No
- Using Reverse Proxy: No

What branch are you running?

Nightly

Trace Logs?

Trace log

2023-10-26 12:48:19.6|Info|ReleaseSearchService|Searching indexer(s): [NZBFinder] for Term: [newsroom 2012 s02e05], Offset: 0, Limit: 100, Categories: [5000]
2023-10-26 12:48:19.6|Debug|Newznab|Downloading Feed https://nzbfinder.ws/api?t=search&extended=1&cat=5010,5020,5030,5040,5045,5060,5070,5080,5090,5999,5000&apikey=(removed)&q=newsroom+2012+s02e05&limit=100&offset=0
2023-10-26 12:48:19.6|Trace|ConfigService|Using default config value for 'logindexerresponse' defaultValue:'False'
2023-10-26 12:48:19.6|Trace|IndexerHttpClient|Req: [GET] https://nzbfinder.ws/api?t=search&extended=1&cat=5010,5020,5030,5040,5045,5060,5070,5080,5090,5999,5000&apikey=(removed)&q=newsroom+2012+s02e05&limit=100&offset=0
2023-10-26 12:48:19.6|Trace|ConfigService|Using default config value for 'proxyenabled' defaultValue:'False'
2023-10-26 12:48:19.6|Trace|IndexerHttpClient|Res: HTTP/2.0 [GET] https://nzbfinder.ws/api?t=search&extended=1&cat=5010,5020,5030,5040,5045,5060,5070,5080,5090,5999,5000&apikey=(removed)&q=newsroom+2012+s02e05&limit=100&offset=0: 200.OK (5879 bytes) (74 ms)
2023-10-26 12:48:19.7|Trace|NewznabRssParser|Parsed: The.Newsroom.2012.S02E05.1080p.BluRay.x264-ROVERS
2023-10-26 12:48:19.7|Trace|NewznabRssParser|Parsed: The.Newsroom.2012.S02E05.1080p.Bluray.x265-HiQVE
2023-10-26 12:48:19.7|Trace|NewznabRssParser|Parsed: The.Newsroom.2012.S02E05.1080p.BluRay.x264-ROVERS
2023-10-26 12:48:19.7|Trace|NewznabRssParser|Parsed: The.Newsroom.2012.S02E05.720p.BluRay.x264-DEMAND
2023-10-26 12:48:19.8|Trace|ReleaseSearchService|4 releases from NZBFinder (Newznab) which didn't contain search categories [5000, 5010, 5020, 5030, 5040, 5045, 5060, 5070, 5080, 5090, 5999] were filtered

NZB Finder API response:

<item>
<title>The.Newsroom.2012.S02E05.1080p.BluRay.x264-ROVERS</title>
<guid isPermaLink="true">https://nzbfinder.ws/details/dc77bf56-10b8-46e2-a58d-2b3928f22a8d</guid>
<link>https://nzbfinder.ws/getnzb?id=dc77bf56-10b8-46e2-a58d-2b3928f22a8d.nzb&r=4631730496a0e291928ad8aef414e1bb</link>
<comments>https://nzbfinder.ws/details/dc77bf56-10b8-46e2-a58d-2b3928f22a8d#comments</comments>
<pubDate>Wed, 18 Jan 2023 02:41:37 +0100</pubDate>
<description>The.Newsroom.2012.S02E05.1080p.BluRay.x264-ROVERS</description>
<enclosure url="https://nzbfinder.ws/getnzb?id=dc77bf56-10b8-46e2-a58d-2b3928f22a8d.nzb&r=4631730496a0e291928ad8aef414e1bb" length="5328761384" type="application/x-nzb"/>
<newznab:attr name="category" value="5999"/>
<newznab:attr name="size" value="5328761384"/>
<newznab:attr name="files" value="53"/>
<newznab:attr name="title" value="News Night with Will McAvoy"/>
<newznab:attr name="season" value="2"/>
<newznab:attr name="tvairdate" value="2013-08-11"/>
<newznab:attr name="tvdbid" value="256227"/>
<newznab:attr name="imdbid" value="1870479"/>
<newznab:attr name="grabs" value="75"/>
<newznab:attr name="comments" value="0"/>
<newznab:attr name="password" value="0"/>
<newznab:attr name="usenetdate" value="Wed, 18 Jan 2023 02:36:33 +0100"/>
</item>

Trace Logs have been provided as applicable. Reports may be closed if the required logs are not provided.

• I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain trace - that are relevant and show this issue.

[mynameisbogdan]

@Qstick Seems reasonable to add support for these x999 categories. WDYT?

See https://github.com/NNTmux/newznab-tmux/blob/1f3fb8cde150c5a31f294dbf9dcd742b3af939c6/app/Models/Category.php#L140

[Fossil01]

I am the admin of NZB Finder. Your software should use the API endpoint /api?t=caps to find the categories currently enabled for that user and only query on those.

I noticed a lot of Prowlarr requests to our API with non-existent category ID's which are now blocked from returning any results.

[mynameisbogdan]

Hello @Fossil01, thank you for reaching out.

Actually we're using the categories from t=caps, but could be an issue with the site categories mapping on our side since some users can set those in Sonarr/Radarr. Can you share a small list of those IDs to get a better idea of the situation?

[Fossil01]

<categories>
<category id="1" name="Other">
<subcat id="10" name="Misc"/>
<subcat id="20" name="Hashed"/>
</category>
<category id="2000" name="Movies">
<subcat id="2010" name="Foreign"/>
<subcat id="2030" name="SD"/>
<subcat id="2040" name="HD"/>
<subcat id="2045" name="UHD"/>
<subcat id="2050" name="3D"/>
<subcat id="2060" name="BluRay"/>
<subcat id="2070" name="DVD"/>
<subcat id="2080" name="WEBDL"/>
<subcat id="2090" name="X265"/>
<subcat id="2999" name="Other"/>
</category>
<category id="3000" name="Audio">
<subcat id="3010" name="MP3"/>
<subcat id="3020" name="Video"/>
<subcat id="3030" name="Audiobook"/>
<subcat id="3040" name="Lossless"/>
<subcat id="3060" name="Foreign"/>
<subcat id="3999" name="Other"/>
</category>
<category id="5000" name="TV">
<subcat id="5010" name="WEB-DL"/>
<subcat id="5020" name="Foreign"/>
<subcat id="5030" name="SD"/>
<subcat id="5040" name="HD"/>
<subcat id="5045" name="UHD"/>
<subcat id="5060" name="Sport"/>
<subcat id="5070" name="Anime"/>
<subcat id="5080" name="Documentary"/>
<subcat id="5090" name="X265"/>
<subcat id="5999" name="Other"/>
</category>
<category id="6000" name="XXX">
<subcat id="6010" name="DVD"/>
<subcat id="6020" name="WMV"/>
<subcat id="6030" name="XviD"/>
<subcat id="6040" name="x264"/>
<subcat id="6041" name="HD Clips"/>
<subcat id="6042" name="SD Clips"/>
<subcat id="6045" name="UHD"/>
<subcat id="6050" name="Packs"/>
<subcat id="6060" name="Imageset"/>
<subcat id="6080" name="SD"/>
<subcat id="6090" name="WEBDL"/>
<subcat id="6999" name="Other"/>
</category>
<category id="7000" name="Books">
<subcat id="7010" name="Magazines"/>
<subcat id="7020" name="Ebook"/>
<subcat id="7030" name="Comics"/>
<subcat id="7040" name="Technical"/>
<subcat id="7060" name="Foreign"/>
<subcat id="7999" name="Other"/>
</category>
</categories>

[mynameisbogdan]

Sorry on the poor formulation, in fact I really want a list of the non-existent category ID's that you're blocking. I want to see if they're with values greater than 100000.

[Fossil01]

That would be anything not in that list :-) Whatever the value is, if its not in there it gets blocked.

But no application should rely on a fixed list as categories might be added/removed in the future. Therefore the capabilities check exists in the API.

[mynameisbogdan]

I'm merely trying to reproduce the issue and pinpoint the culprit, not to hard code any values. Knowing the format of those IDs would've helped me to know if it's an site category mapping which have values greater than 100000 (eg. 100042 for ID 42).

[Fossil01]

Nothing over 10000. If you want to test something non existing I guess just pick something like 6666

[Qstick]

Based on the log we are sending an appropriate search request, it's nothing to do with that. Something seems goofy with our mapping of the categories pre-filter after results are received. @Fossil01 I have an account for testing on Finder, but it disables quickly, can you bump up the hits and I'll see what's going on here.

[Fossil01]

If you use the contact form and send me your username then yeah.