Sonarr downloading larger files than what my quality is set for

Sonarr version
Mono version 6.12.0:
Arch - installed on Sunday:
** **:
Sonarr downloading larger files than I have it set for:

Tuesday morning after checking Deluge to make sure Sonarr grabbed my shows from the night before I noticed that one was within the size range I always receive and set and two were over two gigs. I didn’t think much of it cause I’ve always gotten the occasional one off that was larger than it should be. Like one every couple of months, nothing worth reporting. This morning I had all three shows from last night in Deluge over two gigs each. I checked my quality settings and they are still where I set them (minimum 4.2 / maximum 6.7 on everything). under indexers it’s set for 7800 MB to cover full season downloads. I removed the three shows from last night from Deluge after setting Sonarr to debug for the logs and then let Sonarr find the files again and it downloaded the same large files again which I expected it to do. If I do a manual search the only ones Sonarr doesn’t give me the red warning circle on are the ones within the size range I have set, so why Sonarr would grab anything else I have no idea. Help sorting this would be greatly appreciated. Thanks

2022-05-25 04:40:35.4|Debug|AcceptableSizeSpecification|Possible double episode, doubling allowed size.

First/ last episodes of seasons are allowed to be double the size.

Also why is completed download handling disabled thus meaning a healthcheck is ignored and you’re only using sonarr as a fancy RSS feed parser plus it’ll always grab episodes as they’ll never import and always be missing unless you’re manually importing or manually unmonitoring the episodes

bakerboy448 we are talking about 5 files in all that were each over four times there max allowed size, not double. As for complete download handling I don’t need for Sonarr to name my files or file them away. Don’t get me wrong the features are nice and probably great for most users but for someone like myself it’s not needed. If I could have Sonarr remove the files from the download client, move them to one master folder, rename them before or after moving them and not file them in their respective folders then I probably would use the completed download handling.

As for manually removing the episode after it downloads yes I’m aware I have to do that and already do. As for season finals the only times before this that I’ve seen files double the size they normally are is when the runtime is also double, which if I’m not mistake is the way Sonarr is designed. If I’m wrong on the later please feel free to correct me.

That said in a nutshell the issue still is that for the 5 files between 2 day each of those files were at least 4 times larger than the max allowed for episodes running between 41 and 43 minutes.

You have specifics? Releases or line numbers?

Wading through an entire log file of 3.1k lines and no context or anything specific to look for isn’t particularly useful nor constructive

We’re the releases even reported as the right size from the sites?

If you don’t have completed download handling on and not moving files into sonarr’s structure manually, then I’m assuming your unmonitoring episodes after you download them so they’re not grabbed forever as they’d always be missing.

One maybe two episodes not reported correctly maybe but five extremely unlikely. As for knowing what to look for it’s pretty counter intuitive to turn the debug log on AFTER something happens. Now that said I can add the episodes in question back and let Sonarr grab them again with debug on and try to only post the lines from the time i add the episodes back till they are grabbed. If that will help any let me know. I imagine Sonarr will grab them relatively quickly.

Side note: I clearly stated that I manually remove them once grabbed, so yes again I remove them manually from being monitored.

Can you please and the question. Thanks

EDIT: I found this after I turned debuging back on after I noticed Chicago Med’s lastest episode downloaded at 2.1 gis,

2022-05-25 04:44:52.5|Debug|FullSeasonSpecification|Checking if all episodes in full season release have aired. NCIS Hawaii S01 WEBRip x264-ION10
2022-05-25 04:44:52.5|Debug|LanguageSpecification|Checking if report meets language requirements. English
2022-05-25 04:44:52.5|Debug|MaximumSizeSpecification|Checking if release meets maximum size requirements. 8.9 GB
2022-05-25 04:44:52.5|Debug|MaximumSizeSpecification|8.9 GB is too big, maximum size is 7.6 GB (Settings->Indexers->Maximum Size)
2022-05-25 04:44:52.5|Debug|MinimumAgeSpecification|Not checking minimum age requirement for non-usenet report
2022-05-25 04:44:52.5|Debug|QualityAllowedByProfileSpecification|Checking if report meets quality requirements. WEBRip-480p v1
2022-05-25 04:44:52.5|Debug|ReleaseRestrictionsSpecification|Checking if release meets restrictions: NCIS Hawaii S01 WEBRip x264-ION10
2022-05-25 04:44:52.5|Debug|ReleaseRestrictionsSpecification|[NCIS Hawaii S01 WEBRip x264-ION10] No restrictions apply, allowing

That’s the max size requirement. There should be another line comparing / accepting the other size constraints that are quality/ runtime based

I found that by accident after setting the log to debug again and copying it to kate. can I search by quality / runtime to find what we’re looking for?

You’re looking for Beginning size check for: release_name, but generally it’s best to grab the whole block of release processing for the release, from Processing release 'release name' from 'indexer' to the acceptance/rejection at the bottom.

1 Like

OK thanks for that. Stranger things S04E01 and E03 downloaded sometime overnight and they were in sizes I would expect with my settings. I’m assuming E02 didn’t get grabbed cause of files smaller or larger than what I have set and the remainder of the episodes were not grabbed cause the season packs were dropped before E4 - 7 were dropped individually. I have 3 shows airing tonight, So I’ll see what I get in the morning. Thanks again.

OK the 3 I was expecting last night downloaded and they are within the size range they should be. So maybe those were just one offs after all.