"Quality" Branches Dedicated to HEVC / x265


apologies, i thought i read one of the v3 threads where they said they were using it.

it was one of the primary reasons i was going to check out the v3 alpha but if its not there then i guess ill just stick to the standard release and plod along until it turns up in some variant


Nothing to apologize for, I just wanted to set the records straight.


I would also really like to see a global preferred field to allow the entry of keywords such as HEVC / x265. Where prefered keywords are not available, ignore and move on (x264 obviously) HOWEVER, continue with a low priority search to find and once successfully downloaded, replace the x264 with x265.

Disk space and speed of download are important to us.

I appreciate the dev required for this but this would, IMO, round off a great tool

Thanks for a great product and continued support.


I can only speak for myself, but this is (by far) my most desired enhancement to Sonarr. It would be absolutely amazing to cut my storage requirements in half.

I know everybody thinks their pet feature should be the developers’ priority #1 and… yeah, I do think that!


FWIW I have “solved” this myself by running two separate sonarr instances, one which retrieves the (x264) SD version of the new episodes (since this is usually the first one that comes out) and stops fetching any higher quality, then the main one looks for the h265 keyword as well as a couple of other keywords similar in higher qualities, and retrieves the episodes for longevity that way. It’s an inelegant solution but it accomplishes both prompt fetching of new episodes as well as quality upgrades of the more efficient format when they become available.

The one caveat is that you pick one out of two evils, either both sonarr instances point to the same category which works seamlessly on principle but leaves one of the instances with a long backlog of files that it thinks it should import but can’t since they already are imported by the other, or you use a separate category, which leaves both instances less confused but means you end up with two varieties of the same episode since neither instance sees the download performed by the other, meaning you’ll either have to tidy the shows every so often or live with the duplicates.

So yes, would certainly prefer sonarr to be able to handle this natively albeit I understand the reasoning behind not prioritizing it yet.


Thanks for the work-around suggestion.
I’m trying to replicate this; I have cloned my existing Sonarr and added a restriction to apply to all of ‘x265’ and flagged an existing backseries series to monitor again. When I manually search for an episode, there are ones it could download and replace but it is telling me ‘Existing file meets cut-off: HDTV-720p’. How do I resolve this so that it will download and replace with x265?
Thanks for the help in advance.


@MaleEgo if I understand you correctly you have existing x264 files of the same quality you want to get HEVC copies of? That won’t work I believe, since that as far as Sonarr is concerned is a sidegrade and I can’t see that that’s supported, hence you’d need to just manually replace the files.

For new content I use a cutoff at SD quality for the x264 instance, which means the HEVC instance will always be free to add the HEVC content when it becomes available.


@ameneon Unfortunately, that won’t work for me as I watch new releases almost immediately and cannot watch SD.

I think I need to go the manual route. Could you explain your category method more, please? I don’t understand it.

The only other way I can think of achieving this is creating a completely separate (empty) folder structure of all the shows and point my x265 instance to that. Need to find a way to copy a folder structure in Freenas without copying the files as well though! Do you know how to?

And, what list of ‘Restrictions’ do you find most successful? I’ve initially just put in ‘x265’ but i’ve noticed some release say ‘h265’ or ‘HVEC’ instead. I believed the restrictions list is an ‘AND’ list and not an ‘OR’ list??

Thanks again.


@MaleEgo The restrictions are OR, so I’ve got the usual suspects in there, x265, h265, hevc, and that has done the trick thus far. You will quickly see if a group tags theirs in some other way that requires a different tag in any case.

“Building on” my musings earlier about the category thing that seems to indicate that Sonarr looks at torrent client rather than the directory to identify whether an existing quality target has been met. If that is so, then “my” method should still work, have two instances, one that downloads the x264, the other the h265, going into separate categories in the torrent client.

You would still have the same result insofar as having to clean up/remove the x264’s manually but on principle should then let you get 720p and above of both encodes. Will adjust one of the shows I’m following to see if it works like that and get back to you, unless I hear otherwise first.

As far as the category method goes there’s nothing much to it. When you add a download client you specify which category to use in that client. If you use different categories in each sonarr instance sonarr appears to treat the downloads from each completely separated, allowing for duplicates (which you don’t normally want but in this particular setup you do, since sonarr can’t mix & match 264 and 265, because the restrictions are set globally on the indexer tab rather than per indexer or any other way that would permit mix & match).

If that helped? :slight_smile:

Quick edit: Doesn’t seem to work like that in hindsight, when temporarily changing the quality requirement on my “SD” instance for one of the shows to 720/1080 and doing a rescan the existing HEVC 720 in this case is still seen by Sonarr and thus (I assume) it won’t even try to download an x264 of the same way. Which (probably) means that it won’t try the other way around either since to Sonarr 720 is 720, encoding doesn’t play into it. It works for me since I go for a straight up quality upgrade. You could get somewhatish the same result by going 720 x264 and 1080 HEVC but eh. If you’re going for the ‘best’ quality as I gather you are, then that’s probably not viable either.


@MaleEgo Ok another addendum (apologies), but from testing just now actually it worked precisely like you wanted - downloaded first the x264 version of a random show and then the HEVC version a little while later. I haven’t -thoroughly- tested it but on the one show I did test that’s what it did, at least. Might be worthwhile to do a testrun yourself on it.

Edit: The first bit (where it seemed to not work) wasn’t a download check, rather I noticed that the show listed the 720p from HEVC in the series listing on the SD instance and so assumed that it wouldn’t work. The latter bit was an actual test adding of a random show with 720p on both the SD instance (just changed wanted quality to 720p) and the HEVC instance (which already starts at 720).


Yep, I was going to say, your setup only works because the h265 version you want to take priority is configured with a higher quality level because you likely didn’t edit the episode naming rules when you cloned your Sonarr instances.

For example, my episode naming is configured like this:

which yields this example:

What you could do to let the x264 instance download anything, is to hardcode the wrong quality into the episode naming structure

like this:

Basically you want the low priority Sonarr instance to name the file in such a way and then have profiles configured such that the higher priority Sonarr instance will see files from the lower priority Sonarr instance as files that can be upgraded.


@sienar Does sonarr actually look at file names for quality recognition? I assumed it was looking at the file itself to determine this?


@sienar With the reservation that it did work when doing the check on a random show, what you suggest seems to be a more certain way of doing it, cheers (I’m happy with the setup I have so will keep it for now but that’s a good suggestion if I ever change my mind, and for @MaleEgo, I suspect).



From my experience, I believe it looks at both. I’m pretty sure it requires the filename to contain the source - web, hdtv, bluray, dvd, etc. but it inspects the file itself for resolution. I don’t think there’s any standard metadata on the files that would contain the source.

In my testing just now, when it encounters something not right, like a file labeled as DVD that has a 1080p resolution (I renamed a bluray ripped episode to DVD), it will mark it as unknown.


@sienar @ameneon Gentlemen, I cannot thank you enough for your help. I’ve implemented the file rename with ‘DVD’ trick and all seems well. this is going to save me GBs if not TBs of storage space.

Do you guys do anything similar for films? I don’t use any auto downloaders for films currently but…? :wink:


I don’t use anything for movies, there is radarr but I prefer to make my way into the wilderness and hunt them myself rather than get them at the store, so to speak :stuck_out_tongue: (or perhaps going to the store and pick them out myself rather than using a delivery service would be a better analogy).

Glad it all worked out for you!


@ameneon I have the same feeling for finding films but after implementing this, I want something that will upgrade my library to x265… will give radarr a go, I never got on with coachpotato!

Thanks again


Glad I could help, I actually don’t have this dual instance setup myself and hadn’t even thought of it before this thread. But I’m definitely considering setting it up. The space savings would be huge and I don’t think the Sonarr devs have any near term plans to implement any logic to allow something similar. I may tinker with setting this up in v3 though, not sure.

As for movies, I’m a long time Couchpotato user. Couchpotato doesn’t have much in the way of library management features though, so I’ve been meaning to try out Radarr though since it’s come a long way.


Throw my name in for supporting a separate option for h.265 preference. If you’re worried about confusing regular users, leave the current behaviour as default, but put it into advanced options.

.265 is really such a drastic shift in the storage/size of high quality encodes, and the reality is that all the old codecs and encode types from years ago have all but vanished for releases (ie, Xvid, Mpeg4, Mpeg2, 3GP, Mpv, VP8, etc). Virtually everything coming out now is .264 and .265. With .264 being supported currently in TV/media devices, and the startings of decoder support for .265 appearing, and both are supported by the heavyweight media companies online, they’re going to be the standards for a long while.


Hey Guys -

Appreciate all the replies. Just wanted to say after reading most that yes, some control may be accomplished by using restrictions, sizes, etc. The main purpose I am wanting HEVC/x265 is for archiving, though.

For instance, if a new episode of one of my shows comes out; I want to watch it ASAP. Unfortunately, initial downloads are always x264 with x265 coming out much later. The reason that I wish to have it as a quality is so Sonarr will initially download the x264 one (which I can watch soon after release) then upgrade it to x265 once available. If using restrictions, yes - it will download the x265 copy, but will probably be a couple of days after airing that it appears - if ever.

I currently have over 40tb of media and am sure that if this setting was introduced and I configured it as desired, it would result in my library’s size eventually decreasing drastically yet retain quality - something I’ve done manually for certain shows where available in x265 by season.

If anyone has an alternate solution for this or scripts which could search for x265 replacements for existing items automatically, please let me know.

Just my thoughts - Thanks