Sonarr version (exact version): Mono version (if Sonarr is not running on Windows): Garuda:
Files are larger than maximum size set:
I went to move and rename files downloaded last night and two are far larger than the maximum I have set.
I set Quality right down the line to 350, 450, and 550 for 42 minutes so for Tracker S02E02 runtime of 40:26 max file size should have been 531 megs not 2.5 gigs, The Equalizer S05E01 runtime of 42.39 max file size should have been 557 megs not 2.9 gigs. The only thing I did was uncheck unknown and save.
To the best of my recollection:
First and last episodes in a season are allowed double the max size because sometimes they have a longer runtime / are actually double episodes.
This in combination with thetvdb not exposing individual runtime of episodes in their API but only at series level (I think).
OK that could explain The Equalizer but not Tracker. Also The Lord Of The Rings either episode 5 or 6 did the same thing. I should have mentioned this started after I adjusted the min / max file size allowed.
The thing to keep in mind is that the Size Limits in the Quality Definitions section is not a file size reference but rather an MPEG encoding rate min/max limit. It ultimately equates to a file size because filesize = time X encoding rate. The one weakness with the way Sonarr handles this is that it does not differentiate between x264 and x265 where you can set a max encoding rate for x264 and a different rate for x265 downloads. The differences in the file sizes you mentioned are suspiciously similar to what you would get for an x265 encoded file vs. an x264 encoded file.
Here is an example of what I am talking about for the same episode of a particular show. Notice the huge difference in file size for the different encoding algorithms. The posting group will also have some impact based on how much compression they used when they encoded the file but the bulk of the file size difference is a x265 vs x264 thing.
OK so I should be able to filter out x264 then. This certainly would also explain why when I picked 350 to 550 for 42 minutes so I could avoid files with artifacts why some in my size range are perfect and others are not.
The parameters defined in “Settings/Quality” are per file for a given release type and a given resolution. Here are my 1080p Web* configurations off my system…
The way this form works is that the values of the boxes are in MB/minute and these are linked and calculated on the fly with the slider that is beside them and is representing GB/hour. So you can see my max encoding rate is set to 170.6 MB/minute. When we do the math you get…
170.6 MB/min x 60 min/hour = 10,236 MB/hour
in gigabytes that is…
10,236 MB/hour divided by 1024 MB/GB which equals 9.996 GB/hour (or 10 GiB/h as seen on the slider of my screen capture).
This means if I have an episode with a one-hour run time, I will accept any file up to and including 10 GB. As mentioned though this is really more about an encoding rate so an episode with a shorter run time will have a smaller max file size. Moving the slider with your mouse or typing in a new value in the box will cause the other to automatically recalculate (the slider is in GB/h and the box is MB/min). The developers made the form this way because it is hard to visualize what a max 170.6 MB/min encoding rate means but if I tell you that the encoding rate equates to a file for a 60-minute program being 10 GB in size, that has meaning for you.
The advantage of looking at file sizes as a function of encoding rate is if for some reason a program has an extra long episode like a season finale for a one hour show that was a special episode that ran two hours, it is not a problem because the file size is not a hard limit, it is a limit as a function of time. The other scenario you may see is two episodes posted as a single file (you see this more with DVD or BluRay rips) making the file unusually large, again not a problem because the runtime also goes up meaning we are still within the encoding rate limits.
It’s clear from the above post that I know how it works. What needs answering is why it’s not always working that way when before I increased the acceptable size it was behaving with the occasional one off.
Please don’t take this as me being argumentative as I am not trying to be but I was confused by what you meant by this statement since you can’t explicitly set a quality based on “42 minutes”.
Also the graphic you posted with this statement of the Quality Profile does not show the actual configuration you have under “Settings/Quality”. I thought one possibility was that you set Min to 350, Prefered to 450, and Max to 550 in the Quality Definitions form which is why I went through how those fields are used to calculate file sizes. To be honest, it is still unclear to me how you have the Quality Definitions configured.
If you post a screen capture of the Quality Definition settings in Sonarr I am happy to be a second pair of eyes for you. If you are convinced you have everything set correctly then perhaps you should pursue this as a bug rather than a general request.
You definitely have the quality profiles set correctly as far as I can tell. I did an experiment on my system and set my HDTV-720P Min to 0 Preferred to 1 and Max to 2 and then did a Interactive search for an episode.
As you can see it rejected the highlighted release because of the file size so we know the Quality Definition code appears to be working at least in this case. Have you looked in the history of one of the episodes that are too big to see which quality profile Sonarr thought the release was? (history is available by clicking on an Episode in the Season view and selecting the History tab). Then hit the interactive search tab beside history and see if Sonarr is flagging the release as rejected for being too large (I am wondering if Sonarr is behaving differently for an Interactive search vs. a RSS search). Also check in the info bubble beside a grabbed entry in the history to see if there is a trend with all the oversize releases coming from a particular indexer (perhaps runtime metadata is missing or incorrect in their release RSS feed).
It is possible there is a bug in the Sonarr code but it is a matter of doing the due diligence to eliminate as many things as you can before you go down that path.
You make a good point about RSS cause I vaguely remember someone telling me that RSS could present problems. As for a pattern the only show that I noticed that did this regularly was The Lord Of The Rings other wise it seems to be hit or miss. I have one season and 3 loose episodes that should download by tomorrow morning that I can do what you suggested with. Thanks
I do believe you might have hit the nail on the head about RSS. I just got Tracker S01E05 and it’s over 900 megs for 42 minutes, and The Equalizer S05E03 902 megs for just under 42 minutes. Now The Penguin S01E07 is 592 for 46 minutes which is within the range I set. I did the interactive search to check it and sure enough Tracker and The Equalizer are rejected for size there. Now I just need to know if I can see if any if not all of these were grabbed by RSS feed or if by chance it has more to do with the particular SYNCOPY group. Awhile back there was a group that did supposed 512 files, but they were actually always 1.5 to 3 gigs even though Sonarr claimed they were only 512 megs. That I’m sure was the release group cause I’d go to the site it was grabbed from and it would say the file was 512 megs. If it’s the RSS can I just disable that? Thanks for the help, muchj appreciated.
Tracker 2024 S02E04 720p HDTV x264 SYNCOPY
The Equalizer 2021 S05E03 720p HDTV x264 SYNCOPY
The Penguin S01E07 Top Hat 720p MAX WEB DL DDP5 1 x264 NTb TGx
If the issue is related to the group that is a straightforward problem to solve as you can create a filter specifically to reject the group (look up Release Profiles in the Wiki if you need to figure out how to do that).
As far as the RSS, Automatic Search, and the Interactive Search they can be turned on and off independently in the configuration of the Indexer under Settings.
Good luck, trying to solve these kinds of problems can be frustrating.
I’m hoping it’s the group cause that’s easy to add to what I already have excluded. If it’s RSS related then from what I’m seeing I’m screwed cause from the wording I’ve seen in searching to see if I have to have RSS Sonarr won’t automatically grab anything if RSS isn’t allowed.
I honestly do not know what to think. Just created the below and for the equalized I’m within range. Tested with tracker and over 2 gigs. Added successfulcrab to the below, tested tracker again and still got over 2 gigs.
Would it hurt to set to debug and wait til next Thursday morning to post it so I can see out of 22 episodes between tonight Wednesday night if the above is working or not?
Would it hurt to set to debug and wait til next Thursday morning to post it so I can see out of 22 episodes between tonight Wednesday night if the above is working or not?
I really would appreciate a yes or no to this idea? Thanks
