search

Drapersniper / Qbitrr

A simple Python script to talk to Qbit and Arr's
MIT License
27 stars 4 forks source link

Blocklist corrupted or fake items #34

Open DVDIsDead opened 2 years ago

DVDIsDead commented 2 years ago

Sonarr/Sonarr#969

Radarr/Radarr#4365

the *Arr team refuses to consider a feature (literally, tried to make my case and they locked the issue, and reported me as a spam poster, my issue has been removed and my account flagged because of it) that automatically blacklists releases that are auto-detected ALREADY BY RADARR AND SONARR as 'samples' but with only one media file in the release, clearly making it fake. they kept saying "thats what the release size settings are for" but these files are literally filled with the word "padding" (i checked with a hex editor) over and over after a short clip saying to download a codec or visit a site, etc. and can be the same size as a normal 720p-4k release (i checked with a hex editor and provided proof to them which led to the drama)

wondering if you can take a whack at the problem since theyre so abrasively unwilling for some reason. if not, no big deal.

there is a script i found, that auto detects and deletes these files, but i would like the releases to be blacklisted and justs not import in the first place, seeing as theyre already detected as fraudulent via runtime BY SONARR AND RADARR, and no other files are in the release. this should be possible, right?

Drapersniper commented 2 years ago

The script will already do that.

If you add "sample" to the list of undesired items, if that is the only item in the torrent the torrent will get marked as failed and blocklisted

Drapersniper commented 2 years ago

If you mean Files not named as sample. That are not playable the script already tried to do that.

that's why ffprobe is used.

if after a download completed when the files in that download are processed if all files are not probeable then the release should get blocklisted

Drapersniper commented 2 years ago

Actually my bad, I just checked if a file can't be probed it won't be blocklisted as we don't have a reference to the completed download at that point.

I could add it but concerned about false positives

L1523 would essentially be done on an on_download_complete block - that way we keep a reference to the download id without having to store it, doing it here could cause problem though while the torrent moves from the incomplete to the completed folder

Drapersniper commented 2 years ago

Okay after looking into this a bit - what you are asking is not feasible.

That being said I will be moving the cleanup logic as I mentioned on comment#4.

What that means is All files are marked as bad then a release will be blacklisted - a file is marked as bad based on the filters set by you in the config and if an FFprobe run fails, probe passes as I run then can net false positives i.e pass when its a corrupted file. - for me to get the same level of analysis as Arr is just too much CPU time being used and I'm not willing to implement that (you could easily be monitoring 1000s of files and running probe again those while handling exceptions etc and this just adds way too much complexity to the project )