Prefer smaller/larger releases

deekerman commented

2026-02-20 04:03:06 -05:00

Owner

Originally created by @markus101 on GitHub (Aug 3, 2015).

When nzbs have par files they are larger, currently we're grabbing the smallest nzb in that quality, when multiple releases come out with the same, some with par2 files, others without, we're grabbing the smallest release and missing out on par2 files. I think we need to be smarter about which we grab, not the largest (weed out the overly large files), but the smallest probably isn't the most preferred.

Originally created by @markus101 on GitHub (Aug 3, 2015). When nzbs have par files they are larger, currently we're grabbing the smallest nzb in that quality, when multiple releases come out with the same, some with par2 files, others without, we're grabbing the smallest release and missing out on par2 files. I think we need to be smarter about which we grab, not the largest (weed out the overly large files), but the smallest probably isn't the most preferred.

deekerman

2026-02-20 04:03:06 -05:00

closed this issue
added the
priority:medium

suboptimal

up-for-grabs
labels

deekerman commented

2026-02-20 04:03:07 -05:00

Author

Owner

@otoolejp commented on GitHub (Aug 3, 2015):

It might be easier (code wise) to just grab the largest, since people can already determine for themselves with quality definitions what is considered an overly large file.

@otoolejp commented on GitHub (Aug 3, 2015): It might be easier (code wise) to just grab the largest, since people can already determine for themselves with quality definitions what is considered an overly large file.

deekerman commented

2026-02-20 04:03:07 -05:00

Author

Owner

@Taloth commented on GitHub (Apr 17, 2018):

Like over a year ago I did propose a 'preferred' size in addition to the existing min/max.

@Taloth commented on GitHub (Apr 17, 2018): Like over a year ago I did propose a 'preferred' size in addition to the existing min/max.

deekerman commented

2026-02-20 04:03:07 -05:00

Author

Owner

@MicahZoltu commented on GitHub (Aug 28, 2019):

As a user, I would like to be able to tell Sonarr "Delay downloading for 6 hours after the first episode airs, and then download the smallest release available that matches X filter".

For some things, the quality doesn't bother me, especially if I'm going to be watching it on a mobile device anyway. Since I'm on a metered internet connection I would like to avoid fetching a 2GB file for a 30 minute show that I'll end up watching on a tiny screen. However, for some shows the only thing available is a large file and I would rather spend the bandwidth to get that then have nothing at all.

At the moment, I find myself spending a lot of time manually downloading files because I have setup my download profiles to target small encodings. Sometimes (fairly often) a show won't have an encoding available at the target size, which means I have to go in and manually initiate a download.

@MicahZoltu commented on GitHub (Aug 28, 2019): As a user, I would like to be able to tell Sonarr "Delay downloading for 6 hours after the first episode airs, and then download the smallest release available that matches X filter". For some things, the quality doesn't bother me, especially if I'm going to be watching it on a mobile device anyway. Since I'm on a metered internet connection I would like to avoid fetching a 2GB file for a 30 minute show that I'll end up watching on a tiny screen. However, for some shows the only thing available is a large file and I would rather spend the bandwidth to get that then have nothing at all. At the moment, I find myself spending a lot of time manually downloading files because I have setup my download profiles to target small encodings. Sometimes (fairly often) a show won't have an encoding available at the target size, which means I have to go in and manually initiate a download.

deekerman commented

2026-02-20 04:03:07 -05:00

Author

Owner

@sonuyos commented on GitHub (Feb 27, 2020):

Any update on this? its been 5yrs, lol.

@sonuyos commented on GitHub (Feb 27, 2020): Any update on this? its been 5yrs, lol.

deekerman commented

2026-02-20 04:03:07 -05:00

Author

Owner

@dippynark commented on GitHub (Nov 13, 2020):

Also surprised this is still not implemented, all that would be required is a switch on the function used to compare size (i.e. use CompareByReverse instead) github.com/Sonarr/Sonarr@c75c546888/src/NzbDrone.Core/DecisionEngine/DownloadDecisionComparer.cs (L191) I am maintaining my own fork just for that option

@dippynark commented on GitHub (Nov 13, 2020): Also surprised this is still not implemented, all that would be required is a switch on the function used to compare size (i.e. use `CompareByReverse` instead) https://github.com/Sonarr/Sonarr/blob/c75c54688883461d0e5275f349fba957d992f765/src/NzbDrone.Core/DecisionEngine/DownloadDecisionComparer.cs#L191 I am maintaining my own fork just for that option

deekerman commented

2026-02-20 04:03:07 -05:00

Author

Owner

@markus101 commented on GitHub (Nov 13, 2020):

Sounds like a PR should be opened so it can be reviewed and implemented.

@markus101 commented on GitHub (Nov 13, 2020): Sounds like a PR should be opened so it can be reviewed and implemented.

deekerman commented

2026-02-20 04:03:07 -05:00

Author

Owner

@Qstick commented on GitHub (Nov 13, 2020):

We've implemented preferred size for quality settings on Radarr v3 which also would be a fairly easy pull over. It solves this as @Taloth mentions above

@Qstick commented on GitHub (Nov 13, 2020): We've implemented preferred size for quality settings on Radarr v3 which also would be a fairly easy pull over. It solves this as @Taloth mentions above

deekerman commented

2026-02-20 04:03:07 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Nov 13, 2020):

@Qstick looks like that was this PR https://github.com/Radarr/Radarr/pull/4190 ?

@bakerboy448 commented on GitHub (Nov 13, 2020): @Qstick looks like that was this PR https://github.com/Radarr/Radarr/pull/4190 ?

deekerman commented

2026-02-20 04:03:07 -05:00

Author

Owner

@WernerCD commented on GitHub (Dec 14, 2020):

Answers like this got me to my solution: I'm willing to download 1080's and 720's... but prefer 480s... so I got something similar where it goes:

480
DVD
SDTV <= Cutoff
720
1080

@WernerCD commented on GitHub (Dec 14, 2020): Answers like this got me to my solution: I'm willing to download 1080's and 720's... but prefer 480s... so I got something similar where it goes: 480 DVD SDTV <= Cutoff 720 1080

deekerman commented

2026-02-20 04:03:07 -05:00

Author

Owner

@Ferk commented on GitHub (Jun 28, 2021):

It might be easier (code wise) to just grab the largest, since people can already determine for themselves with quality definitions what is considered an overly large file.

But I would prefer the smaller files, not larger. And if I limit the quality definitions I just get cut off completelly if there are no results within the threshold. It should be a preferred size, not a red line that prevents the download from happening at all.

I might prefer a 1080p video with relatively low size than a 720 video with the same or bigger size. But because I cannot filter by size in the end I have to give up on 1080p completelly if I want to avoid big 1080p videos being preferred over 720p ones.

It's good that now in v3 we can use "release profiles" to at least prefer certain codecs, like h265 / av1. But it would be great if we could also prefer based on size maximum/minimum. Currently I'm doing that with Radarr for movies but Sonarr does not have a way to do this (for Radarr I'm using "custom formats" to do it, which would be sort of similar to Sonarr's "release profiles").

@Ferk commented on GitHub (Jun 28, 2021): > It might be easier (code wise) to just grab the largest, since people can already determine for themselves with quality definitions what is considered an overly large file. But I would prefer the smaller files, not larger. And if I limit the quality definitions I just get cut off completelly if there are no results within the threshold. It should be a preferred size, not a red line that prevents the download from happening at all. I might prefer a 1080p video with relatively low size than a 720 video with the same or bigger size. But because I cannot filter by size in the end I have to give up on 1080p completelly if I want to avoid big 1080p videos being preferred over 720p ones. It's good that now in v3 we can use "release profiles" to at least prefer certain codecs, like h265 / av1. But it would be great if we could also prefer based on size maximum/minimum. Currently I'm doing that with Radarr for movies but Sonarr does not have a way to do this (for Radarr I'm using "custom formats" to do it, which would be sort of similar to Sonarr's "release profiles").

deekerman commented

2026-02-20 04:03:08 -05:00

Author

Owner

@cjmanca commented on GitHub (Jul 3, 2022):

Is anyone working on backporting this from Radarr? If not, I'll do up a pull request soon

@cjmanca commented on GitHub (Jul 3, 2022): Is anyone working on backporting this from Radarr? If not, I'll do up a pull request soon

deekerman commented

2026-02-20 04:03:08 -05:00

Author

Owner

@Qstick commented on GitHub (Jul 3, 2022):

Is anyone working on backporting this from Radarr? If not, I'll do up a pull request soon

Nope, all yours

@Qstick commented on GitHub (Jul 3, 2022): > Is anyone working on backporting this from Radarr? If not, I'll do up a pull request soon Nope, all yours

deekerman commented

2026-02-20 04:03:08 -05:00

Author

Owner

@njhughes-01 commented on GitHub (Sep 2, 2022):

Is anyone working on backporting this from Radarr? If not, I'll do up a pull request soon

Are you working on this? I don't want to look into it if it's already done.

@njhughes-01 commented on GitHub (Sep 2, 2022): > Is anyone working on backporting this from Radarr? If not, I'll do up a pull request soon Are you working on this? I don't want to look into it if it's already done.

deekerman commented

2026-02-20 04:03:08 -05:00

Author

Owner

@cjmanca commented on GitHub (Sep 2, 2022):

I haven't yet. I was waiting on my previous PR to be merged before doing a new one, which took longer than expected, and then I got distracted by other things. You're welcome to if you'd like, otherwise I'll probably get back to this eventually

@cjmanca commented on GitHub (Sep 2, 2022): I haven't yet. I was waiting on my previous PR to be merged before doing a new one, which took longer than expected, and then I got distracted by other things. You're welcome to if you'd like, otherwise I'll probably get back to this eventually

deekerman commented

2026-02-20 04:03:08 -05:00

Author

Owner

@spikysimonw commented on GitHub (Sep 23, 2022):

@cjmanca @Killerherts look forward to either of your work on this coming to fruition, thanks in anticipation.

@spikysimonw commented on GitHub (Sep 23, 2022): @cjmanca @Killerherts look forward to either of your work on this coming to fruition, thanks in anticipation.

deekerman referenced this issue

2026-02-20 04:11:45 -05:00

API Docs for Manual Import #1212

Rows
Columns

Prefer smaller/larger releases #445