Sonarr version (exact version): 3.0.6.1196
OS: Windows 10 Pro
Debug logs: https://pastebin.com/qaPmmHLb
Example Timestamp: 21-4-12 17:04:11.5
Description of issue: A LOT of files are now being flagged as “Season number X was unexpected considering the folder name” requiring me to manually approve them.
This has been working just fine for quite some time and no settings have changed.
The _unpack folder in the “job” folder is not doing you any favours, it’s breaking Sonarr’s ability to find the correct parent folder and resulting in the parsing failing. Eliminating that will resolve the issue, but we may be able to make a change to help as well.
Yeah I have tried to disable that without much success in NZBGet.
This process has been this way for years and hasn’t been an issue until about 6 months ago.
Also worth noting that while 100% of files going through NZBGet have that unpack folder, not all of them get hung up this way. So I think it’s just barely breaking the logic to parse.
I would love to test that change you mentioned if needed, I would also be happy with an option to ignore this type of error and process it anyway since I think I have only had 1 time where it caught a file that wasn’t what it said it was upon download.
Just want to take a moment to say thanks a ton for all the hard work you guys do!
There is definitely a way, otherwise there would be thousands of people running into this issue. Might need to ask on the nzbget side (how to flatten/remove the _unpack folder after unpacking).
Right, because not all of the obfuscated names vaguely look like parseable formats.
You’re absolutely correct on all accounts.
Just did a bunch more reading into it and this is unfortunately caused by my file flow grabbing hold of the files too quickly not allowing NZBGET to finish its unpack process. I can’t fix that timing or change that process because I am honestly not smart enough to.
I now understand I am a fringe case and totally understand if there’s no appetite for trying to help my situation via a code change on the Sonarr side. But it would be immensely helpful if we could try your idea to help the handling of the _unpack folder or even giving us the option to turn off this check and letting it process regardless of a perceived mismatch.
Thank you again for your time and patience 
I’m not sure what you’re doing with the files, but having it ignore any path with _unpack in the path is probably your best bet.
There is already a change on Sonarr’s side to catch the case here, but other different formats may cause issues in the future (and it’s not a game of cat and mouse we’re going to get into).
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.