Trying to keep multiple versions of a movie #1678

Author

Owner

@mrhotio commented on GitHub (Aug 11, 2017):

No, has been asked multiple times already

@mrhotio commented on GitHub (Aug 11, 2017): No, has been asked multiple times already

deekerman commented

Author

Owner

@drashna commented on GitHub (Oct 11, 2017):

All due respect, not including this ability in Radarr is stupid, and a huge oversight.

Plex and Emby support multiple resolutions/formats in the same folder. And will automatically grab the most appropriate file, and reduce the likelihood that files need to be transcoded.

While I understand that most won't need this, for those of us that would like it, maybe keep it as an advanced setting that is off by default.

@drashna commented on GitHub (Oct 11, 2017): All due respect, not including this ability in Radarr is stupid, and a huge oversight. Plex and Emby support multiple resolutions/formats in the same folder. And will automatically grab the most appropriate file, and reduce the likelihood that files need to be transcoded. While I understand that most won't need this, for those of us that would like it, maybe keep it as an advanced setting that is off by default.

deekerman commented

Author

Owner

@mrhotio commented on GitHub (Oct 12, 2017):

Create a pull request for this, you can even collaborate with the few people that want this. Radarr is opensource and the devs would be happy to merge this PR I think.

@mrhotio commented on GitHub (Oct 12, 2017): Create a pull request for this, you can even collaborate with the few people that want this. Radarr is opensource and the devs would be happy to merge this PR I think.

deekerman commented

Author

Owner

@galli-leo commented on GitHub (Oct 14, 2017):

@drashna If it would be as easy as just adding a toggle, we would have done it a long time ago. But because this is built on Sonarr (and Sonarr was made with one file per episode in mind) it's not that easy.

@galli-leo commented on GitHub (Oct 14, 2017): @drashna If it would be as easy as just adding a toggle, we would have done it a long time ago. But because this is built on Sonarr (and Sonarr was made with one file per episode in mind) it's not that easy.

deekerman commented

Author

Owner

@woble commented on GitHub (Dec 3, 2017):

is there an option to not remove previously downloaded file? Perhaps that can be poor man's solution to download and keep multiple versions.

@woble commented on GitHub (Dec 3, 2017): is there an option to not remove previously downloaded file? Perhaps that can be poor man's solution to download and keep multiple versions.

deekerman commented

Author

Owner

@micdah commented on GitHub (Dec 20, 2017):

Yeah having the option to not delete lower/existing quality files, would be a good addition.

Couchpotato has this feature already, but it is cumbersome to manual download multiple qualities using Couchpotato - so a switch to Radarr would be ideal with the addition of this feature.

A way to keep around 2160p and 1080p versions, even though one would have to manually search for the alternate quality, but at least it would be possible to do.

@micdah commented on GitHub (Dec 20, 2017): Yeah having the option to not delete lower/existing quality files, would be a good addition. Couchpotato has this feature already, but it is cumbersome to manual download multiple qualities using Couchpotato - so a switch to Radarr would be ideal with the addition of this feature. A way to keep around 2160p and 1080p versions, even though one would have to manually search for the alternate quality, but at least it would be possible to do.

deekerman commented

Author

Owner

@woble commented on GitHub (Dec 20, 2017):

It could be per profile where each selected quality can be set to be removed or kept when a new quality is downloaded. Cutoff quality would naturally ignore that setting, or perhaps the checkbox for the cutoff quality shouldn't even be shown.

@woble commented on GitHub (Dec 20, 2017): It could be per profile where each selected quality can be set to be removed or kept when a new quality is downloaded. Cutoff quality would naturally ignore that setting, or perhaps the checkbox for the cutoff quality shouldn't even be shown. ![image](https://user-images.githubusercontent.com/494873/34241291-3787bc22-e660-11e7-883a-0ddef7fad3e4.png)

deekerman commented

Author

Owner

@AnnieTheEagle commented on GitHub (Jan 16, 2018):

This would be a very nice feature. Being able to keep a very high quality version for when you're on your fiber optic at home, and then a lower bit rate release for when you're on dubious hotel Internet.

I think there would need to be three changes:

A setting on whether or not to keep multiple versions
On import checking this setting and deciding whether or not to delete existing version because of this setting
Disk Scanner returns multiple files if present (I believe right now it returns the first, in filename order)

Personally I think having this would be great. We already have the UI since the tab itself says "Files" not "File" and has more than enough space to display multiple versions.

This quick fix won't allow for multiple Bluray-1080p since they'd have the same file name. But rather allow for someone to keep a Remux-2160p with a Bluray-1080p

@AnnieTheEagle commented on GitHub (Jan 16, 2018): This would be a very nice feature. Being able to keep a very high quality version for when you're on your fiber optic at home, and then a lower bit rate release for when you're on dubious hotel Internet. I think there would need to be three changes: 1. A setting on whether or not to keep multiple versions 2. On import checking this setting and deciding whether or not to delete existing version because of this setting 3. Disk Scanner returns multiple files if present (I believe right now it returns the first, in filename order) Personally I think having this would be great. We already have the UI since the tab itself says "Files" not "File" and has more than enough space to display multiple versions. This quick fix won't allow for multiple Bluray-1080p since they'd have the same file name. But rather allow for someone to keep a Remux-2160p with a Bluray-1080p

deekerman commented

Author

Owner

@intelligence commented on GitHub (Jul 2, 2018):

This sure sound interesting. I'm having issues with 4K content as my server can't transcode it on the fly. And having Plex converting it is less than ideal since you can't really tweak the conversion settings that well.

@intelligence commented on GitHub (Jul 2, 2018): This sure sound interesting. I'm having issues with 4K content as my server can't transcode it on the fly. And having Plex converting it is less than ideal since you can't really tweak the conversion settings that well.

deekerman commented

Author

Owner

@emopinata commented on GitHub (Aug 6, 2018):

This would even be useful in Sonarr, for the same reasons. Wonder if it's something that might be in their v3 work...

@emopinata commented on GitHub (Aug 6, 2018): This would even be useful in Sonarr, for the same reasons. Wonder if it's something that might be in their v3 work...

deekerman commented

Author

Owner

@emopinata commented on GitHub (Aug 6, 2018):

Well, there's at least an open issue, though it seems to be of equally low priority https://github.com/Sonarr/Sonarr/issues/312

@emopinata commented on GitHub (Aug 6, 2018): Well, there's at least an open issue, though it seems to be of equally low priority https://github.com/Sonarr/Sonarr/issues/312

deekerman commented

Author

Owner

@donkeyjuks commented on GitHub (Dec 21, 2018):

any update to this?... I'd also like to keep 4K version and 1080p version (different folders).

@donkeyjuks commented on GitHub (Dec 21, 2018): any update to this?... I'd also like to keep 4K version and 1080p version (different folders).

deekerman commented

Author

Owner

@galli-leo commented on GitHub (Dec 24, 2018):

@donkeyjuks https://blog.radarr.video/development/update/2018/11/11/roadmap-update.html

@galli-leo commented on GitHub (Dec 24, 2018): @donkeyjuks https://blog.radarr.video/development/update/2018/11/11/roadmap-update.html

deekerman commented

Author

Owner

@mattbailey commented on GitHub (Mar 20, 2019):

My super lazy hack: github.com/mattbailey/Radarr@f9300900c2

@mattbailey commented on GitHub (Mar 20, 2019): My super lazy hack: https://github.com/mattbailey/Radarr/commit/f9300900c2ca2410b8f7d5875a0727ccc4ba2b5f

deekerman commented

Author

Owner

@ravensorb commented on GitHub (Mar 3, 2020):

Maybe we at least have a setting to enable/disable deleting existing videos?

@ravensorb commented on GitHub (Mar 3, 2020): Maybe we at least have a setting to enable/disable deleting existing videos?

deekerman commented

Author

Owner

@epheterson commented on GitHub (Apr 19, 2020):

Could we re-visit this? I figured I was just missing a setting but this would be a great feature to add.

@epheterson commented on GitHub (Apr 19, 2020): Could we re-visit this? I figured I was just missing a setting but this would be a great feature to add.

deekerman commented

Author

Owner

@Qstick commented on GitHub (Apr 19, 2020):

It’s a tad more complicated than that if we want to do it right.

@Qstick commented on GitHub (Apr 19, 2020): It’s a tad more complicated than that if we want to do it right.

deekerman commented

Author

Owner

@cjemorton commented on GitHub (May 12, 2020):

I came looking to see if this was a thing yet. I realize it's not super easy to implement, yet I'm looking forwards to it being available.
I usually like to keep multiple encodes around for local streaming - laptop etc and then higher quality encodes or REMUX's etc for streaming directly to larger screen tv's.

The quick'n dirty hack that I've been considering is simply running multiple versions of radarr in separate jails, each managing their own quality - tho in my opinion this is like taking a buzz saw to a loaf of bread. It works, but it's messy and you end up with bit's n pieces everywhere.

@cjemorton commented on GitHub (May 12, 2020): I came looking to see if this was a thing yet. I realize it's not super easy to implement, yet I'm looking forwards to it being available. I usually like to keep multiple encodes around for local streaming - laptop etc and then higher quality encodes or REMUX's etc for streaming directly to larger screen tv's. The quick'n dirty hack that I've been considering is simply running multiple versions of radarr in separate jails, each managing their own quality - tho in my opinion this is like taking a buzz saw to a loaf of bread. It works, but it's messy and you end up with bit's n pieces everywhere.

deekerman commented

Author

Owner

@evanrich commented on GitHub (Aug 22, 2020):

Why is it so hard to run two copies of radarr? I know it's a pain, one would be easier, but to be honest...it's really not THAT complicated. I run one for 4k and one for 1080p. EZ.

@evanrich commented on GitHub (Aug 22, 2020): Why is it so hard to run two copies of radarr? I know it's a pain, one would be easier, but to be honest...it's really not THAT complicated. I run one for 4k and one for 1080p. EZ.

deekerman commented

Author

Owner

@Puntoboy commented on GitHub (Dec 15, 2020):

When running two copies of Radarr, do you need two separate media folders where the movies are stored or can you have one location just with two versions of Radarr writing to it?

@Puntoboy commented on GitHub (Dec 15, 2020): When running two copies of Radarr, do you need two separate media folders where the movies are stored or can you have one location just with two versions of Radarr writing to it?

deekerman commented

Author

Owner

@austinwbest commented on GitHub (Dec 15, 2020):

When running two copies of Radarr, do you need two separate media folders where the movies are stored or can you have one location just with two versions of Radarr writing to it?

Each instance has its own root folders & you can just join them in plex for example

@austinwbest commented on GitHub (Dec 15, 2020): > When running two copies of Radarr, do you need two separate media folders where the movies are stored or can you have one location just with two versions of Radarr writing to it? Each instance has its own root folders & you can just join them in plex for example

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Dec 16, 2020):

Could use this for movies that are split into two parts

not really, it’s a different beast with its own hurdlers and logic.

this request is two discrete versions in each a single file. 1 movie -> many versions; One version -> One File

what you’re saying would be multiple versions and multiple files

1 movie -> many versions; many versions -> many files

significantly more complex

@bakerboy448 commented on GitHub (Dec 16, 2020): > Could use this for movies that are split into two parts not really, it’s a different beast with its own hurdlers and logic. this request is two discrete versions in each a single file. 1 movie -> many versions; One version -> One File what you’re saying would be multiple versions and multiple files 1 movie -> many versions; many versions -> many files significantly more complex

deekerman commented

Author

Owner

@ryanfb commented on GitHub (Dec 17, 2020):

@azumukupoe you're looking for #145

@ryanfb commented on GitHub (Dec 17, 2020): @azumukupoe you're looking for #145

deekerman commented

Author

Owner

@timmehtimtims commented on GitHub (Jan 15, 2021):

When running two copies of Radarr, do you need two separate media folders where the movies are stored or can you have one location just with two versions of Radarr writing to it?

Each instance has its own root folders & you can just join them in plex for example

I guess what I'm finding is that having multiple instances takes up a huge amount of HDD space. I have a 500Gb nvme and each instance is about 25Gb, using up valuable space. I have 3 instances: 4K, 1080p REMUX and low quality Web-DL 1080p/720p = 75Gb (nearly 1/5th) of my HDD, just to run radarr. If there was a way to do this in once instance then that would be amazing. 👍

@timmehtimtims commented on GitHub (Jan 15, 2021): > > When running two copies of Radarr, do you need two separate media folders where the movies are stored or can you have one location just with two versions of Radarr writing to it? > > Each instance has its own root folders & you can just join them in plex for example I guess what I'm finding is that having multiple instances takes up a huge amount of HDD space. I have a 500Gb nvme and each instance is about 25Gb, using up valuable space. I have 3 instances: 4K, 1080p REMUX and low quality Web-DL 1080p/720p = 75Gb (nearly 1/5th) of my HDD, just to run radarr. If there was a way to do this in once instance then that would be amazing. 👍

deekerman commented

Author

Owner

@Puntoboy commented on GitHub (Jan 15, 2021):

Having one instance wouldn't make a difference in your case, the video files will still take up that space.

In that situation the best way is to have a single best quality version (4K) and then transcode it on the fly for the devices that need it. That just takes a lot of CPU/GPU to do.

@Puntoboy commented on GitHub (Jan 15, 2021): Having one instance wouldn't make a difference in your case, the video files will still take up that space. In that situation the best way is to have a single best quality version (4K) and then transcode it on the fly for the devices that need it. That just takes a lot of CPU/GPU to do.

deekerman commented

Author

Owner

@timmehtimtims commented on GitHub (Jan 15, 2021):

Having one instance wouldn't make a difference in your case, the video files will still take up that space.

In that situation the best way is to have a single best quality version (4K) and then transcode it on the fly for the devices that need it. That just takes a lot of CPU/GPU to do.

Sorry, I should have been more clear - the metadata in /opt/appdata/radarr is 25Gb. Same again for /opt/appdata/radarr4k and /opt/appdata/radarrlowquality
One instance would mean I'd reduce the amount of space used by metadata by 1/3.

@timmehtimtims commented on GitHub (Jan 15, 2021): > Having one instance wouldn't make a difference in your case, the video files will still take up that space. > > In that situation the best way is to have a single best quality version (4K) and then transcode it on the fly for the devices that need it. That just takes a lot of CPU/GPU to do. Sorry, I should have been more clear - the metadata in /opt/appdata/radarr is 25Gb. Same again for /opt/appdata/radarr4k and /opt/appdata/radarrlowquality One instance would mean I'd reduce the amount of space used by metadata by 1/3.

deekerman commented

Author

Owner

@Puntoboy commented on GitHub (Jan 15, 2021):

How big if your library? I have over 500 movies and the metadata on mine is only 700mb each.

@Puntoboy commented on GitHub (Jan 15, 2021): How big if your library? I have over 500 movies and the metadata on mine is only 700mb each.

deekerman commented

Author

Owner

@timmehtimtims commented on GitHub (Jan 15, 2021):

Haha, good point. Maybe this isn't a common issue...

@timmehtimtims commented on GitHub (Jan 15, 2021): Haha, good point. Maybe this isn't a common issue...

deekerman commented

Author

Owner

@stale[bot] commented on GitHub (Jun 25, 2021):

This issue has been automatically marked as stale because it has not had recent activity. Please verify that this is still an issue with the latest version of Radarr and report back. Otherwise this issue will be closed.

@stale[bot] commented on GitHub (Jun 25, 2021): This issue has been automatically marked as stale because it has not had recent activity. Please verify that this is still an issue with the latest version of Radarr and report back. Otherwise this issue will be closed.

deekerman commented

Author

Owner

@epheterson commented on GitHub (Jun 25, 2021):

This is still desirable, please consider!

@epheterson commented on GitHub (Jun 25, 2021): This is still desirable, please consider!

deekerman commented

Author

Owner

@ravensorb commented on GitHub (Jun 27, 2021):

Agreed!

@ravensorb commented on GitHub (Jun 27, 2021): Agreed!

deekerman commented

Author

Owner

@bouncy99 commented on GitHub (Jul 3, 2021):

Agreed, this is still desirable, and yet lacking for the last 4 years :(

@bouncy99 commented on GitHub (Jul 3, 2021): Agreed, this is still desirable, and yet lacking for the last 4 years :(

deekerman commented

Author

Owner

@timmehtimtims commented on GitHub (Jul 3, 2021):

Again, agreed desirable :)

@timmehtimtims commented on GitHub (Jul 3, 2021): Again, agreed desirable :)

deekerman commented

Author

Owner

@ta264 commented on GitHub (Jul 3, 2021):

Please, comments like this are not helpful. We know it's wanted, but it is a lot of work.

@ta264 commented on GitHub (Jul 3, 2021): Please, comments like this are not helpful. We know it's wanted, but it is *a lot* of work.

deekerman commented

Author

Owner

@ravensorb commented on GitHub (Jul 3, 2021):

Question - is there a discussion around ideas on how to implement? Its possible others might be able to help if there is kind of an agreed approach.

@ravensorb commented on GitHub (Jul 3, 2021): Question - is there a discussion around ideas on how to implement? Its possible others might be able to help if there is kind of an agreed approach.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Jul 3, 2021):

Question - is there a discussion around ideas on how to implement? Its possible others might be able to help if there is kind of an agreed approach.

Some rough initial discussion is taking place over on Sonarr
https://github.com/Sonarr/Sonarr/issues/4551

@bakerboy448 commented on GitHub (Jul 3, 2021): > Question - is there a discussion around ideas on how to implement? Its possible others might be able to help if there is kind of an agreed approach. Some rough initial discussion is taking place over on Sonarr https://github.com/Sonarr/Sonarr/issues/4551

deekerman commented

Author

Owner

@ta264 commented on GitHub (Jul 3, 2021):

And just to be clear, constructive suggestions/ discussion is very welcome. It's only "+1" and "I can't believe this hasn't been done in 4 years" that are to be avoided.

@ta264 commented on GitHub (Jul 3, 2021): And just to be clear, constructive suggestions/ discussion is very welcome. It's only "+1" and "I can't believe this hasn't been done in 4 years" that are to be avoided.

deekerman commented

Author

Owner

@aronmgv commented on GitHub (Jul 25, 2021):

@ta264 Can you please explain why that would be lot of work? On the development level please. Thanks

@aronmgv commented on GitHub (Jul 25, 2021): @ta264 Can you please explain why that would be lot of work? On the development level please. Thanks

deekerman commented

Author

Owner

@austinwbest commented on GitHub (Jul 25, 2021):

@ta264 Can you please explain why that would be lot of work? On the development level please. Thanks

Because the entire app is setup for 1:1

The UI, the api, the database, the code base. Everything has to be switched from that to a 1:many and a lot of the database has to be rearranged to accomadate that as well. The grab logic, upgrade, rss, cutoff, folder structures, etc is all 1:1

Everything is going from a single string checks to list loops for example.

@austinwbest commented on GitHub (Jul 25, 2021): > @ta264 Can you please explain why that would be lot of work? On the development level please. Thanks Because the entire app is setup for 1:1 The UI, the api, the database, the code base. Everything has to be switched from that to a 1:many and a lot of the database has to be rearranged to accomadate that as well. The grab logic, upgrade, rss, cutoff, folder structures, etc is all 1:1 Everything is going from a single string checks to list loops for example.

deekerman commented

Author

Owner

@ksj01 commented on GitHub (Oct 25, 2021):

I haven’t dug into the code yet, but it seems appending the resolution to the end of the file name would fix some of the issues surrounding different resolutions overwriting one another. This would at least make it feasible for manual searches, with more work being necessary to include the functionality in automation.

@ksj01 commented on GitHub (Oct 25, 2021): I haven’t dug into the code yet, but it seems appending the resolution to the end of the file name would fix some of the issues surrounding different resolutions overwriting one another. This would at least make it feasible for manual searches, with more work being necessary to include the functionality in automation.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Oct 25, 2021):

I haven’t dug into the code yet, but it seems appending the resolution to the end of the file name would fix some of the issues surrounding different resolutions overwriting one another. This would at least make it feasible for manual searches, with more work being necessary to include the functionality in automation.

If it was that simple it would have been done already - it is not... not at all. Read the previous comments for details and specifics.

@bakerboy448 commented on GitHub (Oct 25, 2021): > I haven’t dug into the code yet, but it seems appending the resolution to the end of the file name would fix some of the issues surrounding different resolutions overwriting one another. This would at least make it feasible for manual searches, with more work being necessary to include the functionality in automation. If it was that simple it would have been done already - it is not... not at all. Read the previous comments for details and specifics.

deekerman commented

Author

Owner

@ksj01 commented on GitHub (Oct 26, 2021):

Yes, I’m aware that’s not all there is to it. I was merely providing a potential jumping off point for a manual download solution specific to people who don’t need active file management handled by radarr.

But it’s clear that this isn’t being worked on by anyone and no dialogue is going to get that ball rolling.

I’m going to work on this and see what I can come up with, because this is something that is important to me and a lot of other people.

@ksj01 commented on GitHub (Oct 26, 2021): Yes, I’m aware that’s not all there is to it. I was merely providing a potential jumping off point for a manual download solution specific to people who don’t need active file management handled by radarr. But it’s clear that this isn’t being worked on by anyone and no dialogue is going to get that ball rolling. I’m going to work on this and see what I can come up with, because this is something that is important to me and a lot of other people.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Oct 26, 2021):

storing multiple video files in a single movie folder and trying similar for sonarr will cause weird and unexpected problems and goes without saying is not supported.

manual downloads have nothing to do with it. Multiple video files in a movie's folder is not supported and will 100% cause weird and unexpected behavior at some point.

(Side note: quality is irreplaceable metadata and should be stored in your file name anyway if you ever need to reimport then everything will be assumed to be the worst quality for that resolution and this would likely be upgraded)

@ksj01 some initial thinking on scope, edge cases, and general thoughts on Sonarr https://github.com/Sonarr/Sonarr/issues/4551

this is not at all an easy task and is a complex one that again requires functionally an entire rewrite for the bulk of the program as Austin previously stated.

@bakerboy448 commented on GitHub (Oct 26, 2021): storing multiple video files in a single movie folder and trying similar for sonarr will cause weird and unexpected problems and goes without saying is not supported. manual downloads have nothing to do with it. Multiple video files in a movie's folder is not supported and will 100% cause weird and unexpected behavior at some point. (Side note: quality is irreplaceable metadata and should be stored in your file name anyway if you ever need to reimport then everything will be assumed to be the worst quality for that resolution and this would likely be upgraded) @ksj01 some initial thinking on scope, edge cases, and general thoughts on Sonarr https://github.com/Sonarr/Sonarr/issues/4551 this is not at all an easy task and is a complex one that again requires functionally an entire rewrite for the bulk of the program as Austin previously stated.

deekerman commented

Author

Owner

@ksj01 commented on GitHub (Oct 26, 2021):

To be honest, I’m not especially concerned with the multiple resolution issue. That doesn’t affect me to a great deal.

My implementation would be for alternate cuts, and I believe I have a way to implement it that would keep everything as a 1:1 relationship in the majority of situations.

I’m going to try to explain my thoughts, but that’s never been one of my strong suits.

For example, Logan - Noir Edition. Imagine there was an option to effectively clone a movie listing within radarr, which then prompts for an “alternate cut” keyword (this could also be initiated via the API if the request includes the “alternate cut” field). In this case, it would be “Noir.” Radarr could create a new movie instance in addition to the standard Logan listing. Radarr would search for Logan as normal and then exclude results that don’t have Noir in the title, and then put that movie in a folder titled “Logan - Noir (2017). In theory, this should keep things in a 1:1 relationship for the majority of functions.

@ksj01 commented on GitHub (Oct 26, 2021): To be honest, I’m not especially concerned with the multiple resolution issue. That doesn’t affect me to a great deal. My implementation would be for alternate cuts, and I believe I have a way to implement it that would keep everything as a 1:1 relationship in the majority of situations. I’m going to try to explain my thoughts, but that’s never been one of my strong suits. For example, Logan - Noir Edition. Imagine there was an option to effectively clone a movie listing within radarr, which then prompts for an “alternate cut” keyword (this could also be initiated via the API if the request includes the “alternate cut” field). In this case, it would be “Noir.” Radarr could create a new movie instance in addition to the standard Logan listing. Radarr would search for Logan as normal and then exclude results that don’t have Noir in the title, and then put that movie in a folder titled “Logan - Noir (2017). In theory, this should keep things in a 1:1 relationship for the majority of functions.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Oct 26, 2021):

multiple resolutions / multiple editions. Same concept. Same problem. Everything in radarr is 1:1 and it requires a major front and backend rewrite and database rework to change that

1:1 status-quo includes one singular TMDB id in the database, so that concept you think would not work either. Again, it's not at all as simple as anyone who has ever commented on this issue seems to believe it is.

You can't solve the issue in piecemeal and this and the Custom Folders request are the two most complex changes to radarr, both require significant rewrites.

Perhaps swing by discord and chat things out with the dev team before diving into a feature that again requires an entire rewrite of just about the whole code base and restructuring of the database

@bakerboy448 commented on GitHub (Oct 26, 2021): multiple resolutions / multiple editions. Same concept. Same problem. Everything in radarr is 1:1 and it requires a major front and backend rewrite and database rework to change that 1:1 status-quo includes one singular TMDB id in the database, so that concept you think would not work either. Again, it's not at all as simple as anyone who has ever commented on this issue seems to believe it is. You can't solve the issue in piecemeal and this and the Custom Folders request are the two most complex changes to radarr, both require significant rewrites. Perhaps swing by discord and chat things out with the dev team before diving into a feature that again requires an entire rewrite of just about the whole code base and restructuring of the database

deekerman commented

Author

Owner

@kaysond commented on GitHub (Nov 11, 2021):

Does radarr distinguish between regular files and symlinks? Meaning could I have separate radarr instances for 1080p/4k and symlink video files from one into the folders of another? It would be a decent workaround that supports multiple versions in emby/jellyfin

@kaysond commented on GitHub (Nov 11, 2021): Does radarr distinguish between regular files and symlinks? Meaning could I have separate radarr instances for 1080p/4k and symlink video files from one into the folders of another? It would be a decent workaround that supports multiple versions in emby/jellyfin

deekerman commented

Author

Owner

@lunks commented on GitHub (Jan 23, 2022):

My 2c on two ways to implement this in a way that could help some scenarios: Allow us to lock or ignore the file for Radarr i.e. for all intents and purposes the file would be either locked or ignored. If file is locked, it would never try to upgrade or remove the locked file. If ignoring, Radarr could keep doing its thing for the movie but would solely ignore the file that has been marked as ignored. Some examples:

Considering multiple resolutions:

If lock is the way to go:

I have one 1080p file and a 4k file.

I decide that the 1080p is great and I prefer it since it's more compatible so I lock it. Radarr can eventually get rid of the 4k given it's not locked and a locked file exists, so it is free to do whatever with other files that are not locked.

I want to keep both, I lock both which would behave similar as if I'm not monitoring given movie. It can't rename, can't upgrade, can't remove any of them.

If ignore is the way to go:

I have one 1080p file and a 4k file.

I decide that 1080p is great and I would like to keep it because the 4k version needs transcoding. I set radarr to ignore the 1080p file and so Radarr is free to upgrade the 4k file, replace it, etc.

If I decide that I want to keep both versions forever, ignoring both would make Radarr consider those files are not there, downloading a third version.

Considering multiple versions i.e. theatrical and extended:

If lock is the way to go:

I love this particular movie theatrical version and it's a rare find, I manually downloaded it outside radarr, added the file and locked it. I'll only have this theatrical version because the file is locked. If I want to add an extended version, I'd have to manually add that file and mark it as locked. Radarr would never upgrade these files.

If ignore is the way to go:

Same theatrical version that is hard as hell to find. I set the file as ignored, then Radarr won't ever mess with it. It could download an extended version in better quality, a theatrical version in better quality even, but the one I ripped and that gave me a lot of work would be kept there.

I personally prefer the ignore route as it at least sounds easier to implement and I think, apart from full-fledged features where we can have an UI to handle multiple resolutions and/or multiple versions, would fit what semantically I want Radarr to do, which is "stop deleting my precious file I want to keep!"

@lunks commented on GitHub (Jan 23, 2022): My 2c on two ways to implement this in a way that could help some scenarios: Allow us to lock or ignore the file for Radarr i.e. for all intents and purposes the file would be either locked or ignored. If file is locked, it would never try to upgrade or remove the locked file. If ignoring, Radarr could keep doing its thing for the movie but would solely ignore the file that has been marked as ignored. Some examples: ## Considering multiple resolutions: ### If lock is the way to go: I have one 1080p file and a 4k file. I decide that the 1080p is great and I prefer it since it's more compatible so I lock it. Radarr can eventually get rid of the 4k given it's not locked and a locked file exists, so it is free to do whatever with other files that are not locked. I want to keep both, I lock both which would behave similar as if I'm not monitoring given movie. It can't rename, can't upgrade, can't remove any of them. ### If ignore is the way to go: I have one 1080p file and a 4k file. I decide that 1080p is great and I would like to keep it because the 4k version needs transcoding. I set radarr to ignore the 1080p file and so Radarr is free to upgrade the 4k file, replace it, etc. If I decide that I want to keep both versions forever, ignoring both would make Radarr consider those files are not there, downloading a third version. ## Considering multiple versions i.e. theatrical and extended: ### If lock is the way to go: I love this particular movie theatrical version and it's a rare find, I manually downloaded it outside radarr, added the file and locked it. I'll only have this theatrical version because the file is locked. If I want to add an extended version, I'd have to manually add that file and mark it as locked. Radarr would never upgrade these files. ### If ignore is the way to go: Same theatrical version that is hard as hell to find. I set the file as ignored, then Radarr won't ever mess with it. It could download an extended version in better quality, a theatrical version in better quality even, but the one I ripped and that gave me a lot of work would be kept there. I personally prefer the ignore route as it at least _sounds_ easier to implement and I think, apart from full-fledged features where we can have an UI to handle multiple resolutions and/or multiple versions, would fit what semantically I want Radarr to do, which is "stop deleting my precious file I want to keep!"

deekerman commented

Author

Owner

@cjemorton commented on GitHub (Jan 23, 2022):

I seriously like the approach of locking a file.

Say, for example. There's encodes I have personally done for a show but
there's also 4k releases that are out. I don't want to nix the DVD encode,
for playing on smaller devices. But having the ability to grab a 4k release
for streaming to larger TV that support it.

Being able to lock all files for a release group. (I tag all my personal
encodes with my own tag), then if a higher quality comes out, or is
obtained, it gets imported alongside the locked encode.

On Sun., Jan. 23, 2022, 4:49 a.m. Pedro Nascimento, <
@.***> wrote:

My 2c on two ways to implement this in a way that could help some
scenarios: Allow us to lock or ignore the file for Radarr i.e. for all
intents and purposes the file would be either locked or ignored. If file is
locked, it would never try to upgrade or remove the locked file. If
ignoring, Radarr could keep doing its thing for the movie but would solely
ignore the file that has been marked as ignored. Some examples:
Considering multiple resolutions: If lock is the way to go:

I have one 1080p file and a 4k file.

I decide that the 1080p is great and I prefer it since it's more
compatible so I lock it. Radarr can eventually get rid of the 4k given it's
not locked and a locked file exists, so it is free to do whatever with
other files that are not locked.

I want to keep both, I lock both which would behave similar as if I'm not
monitoring given movie. It can't rename, can't upgrade, can't remove any of
them.
If ignore is the way to go:

I have one 1080p file and a 4k file.

I decide that 1080p is great and I would like to keep it because the 4k
version needs transcoding. I set radarr to ignore the 1080p file and so
Radarr is free to upgrade the 4k file, replace it, etc.

If I decide that I want to keep both versions forever, ignoring both would
make Radarr consider those files are not there, downloading a third version.
Considering multiple versions i.e. theatrical and extended: If lock is
the way to go:

I love this particular movie theatrical version and it's a rare find, I
manually downloaded it outside radarr, added the file and locked it. I'll
only have this theatrical version because the file is locked. If I want to
add an extended version, I'd have to manually add that file and mark it as
locked. Radarr would never upgrade these files.
If ignore is the way to go:

Same theatrical version that is hard as hell to find. I set the file as
ignored, then Radarr won't ever mess with it. It could download an extended
version in better quality, a theatrical version in better quality even, but
the one I ripped and that gave me a lot of work would be kept there.

—
Reply to this email directly, view it on GitHub
https://github.com/Radarr/Radarr/issues/1910#issuecomment-1019468049,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAUJR5EOCTTIQJG4YGAU2L3UXPTOPANCNFSM4DWTFOZQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID:
@.***>

@cjemorton commented on GitHub (Jan 23, 2022): I seriously like the approach of locking a file. Say, for example. There's encodes I have personally done for a show but there's also 4k releases that are out. I don't want to nix the DVD encode, for playing on smaller devices. But having the ability to grab a 4k release for streaming to larger TV that support it. Being able to lock all files for a release group. (I tag all my personal encodes with my own tag), then if a higher quality comes out, or is obtained, it gets imported alongside the locked encode. On Sun., Jan. 23, 2022, 4:49 a.m. Pedro Nascimento, < ***@***.***> wrote: > My 2c on two ways to implement this in a way that could help some > scenarios: Allow us to lock or ignore the file for Radarr i.e. for all > intents and purposes the file would be either locked or ignored. If file is > locked, it would never try to upgrade or remove the locked file. If > ignoring, Radarr could keep doing its thing for the movie but would solely > ignore the file that has been marked as ignored. Some examples: > Considering multiple resolutions: If lock is the way to go: > > I have one 1080p file and a 4k file. > > I decide that the 1080p is great and I prefer it since it's more > compatible so I lock it. Radarr can eventually get rid of the 4k given it's > not locked and a locked file exists, so it is free to do whatever with > other files that are not locked. > > I want to keep both, I lock both which would behave similar as if I'm not > monitoring given movie. It can't rename, can't upgrade, can't remove any of > them. > If ignore is the way to go: > > I have one 1080p file and a 4k file. > > I decide that 1080p is great and I would like to keep it because the 4k > version needs transcoding. I set radarr to ignore the 1080p file and so > Radarr is free to upgrade the 4k file, replace it, etc. > > If I decide that I want to keep both versions forever, ignoring both would > make Radarr consider those files are not there, downloading a third version. > Considering multiple versions i.e. theatrical and extended: If lock is > the way to go: > > I love this particular movie theatrical version and it's a rare find, I > manually downloaded it outside radarr, added the file and locked it. I'll > only have this theatrical version because the file is locked. If I want to > add an extended version, I'd have to manually add that file and mark it as > locked. Radarr would never upgrade these files. > If ignore is the way to go: > > Same theatrical version that is hard as hell to find. I set the file as > ignored, then Radarr won't ever mess with it. It could download an extended > version in better quality, a theatrical version in better quality even, but > the one I ripped and that gave me a lot of work would be kept there. > > — > Reply to this email directly, view it on GitHub > <https://github.com/Radarr/Radarr/issues/1910#issuecomment-1019468049>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAUJR5EOCTTIQJG4YGAU2L3UXPTOPANCNFSM4DWTFOZQ> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > You are receiving this because you commented.Message ID: > ***@***.***> >

deekerman commented

Author

Owner

@ta264 commented on GitHub (Jan 23, 2022):

I don't think anything that requires a manual intervention for every case is a viable solution.

If and when we do something about this, it will be a something that allows upgrades via profiles I think. We don't have much interest in a half-baked stop-gap solution - we should do it right or not do it at all in my view.

@ta264 commented on GitHub (Jan 23, 2022): I don't think anything that requires a manual intervention for every case is a viable solution. If and when we do something about this, it will be a something that allows upgrades via profiles I think. We don't have much interest in a half-baked stop-gap solution - we should do it right or not do it at all in my view.

deekerman commented

Author

Owner

@ptyork commented on GitHub (Apr 1, 2022):

Is there not a relatively easy, non-breaking option that doesn't involve breaking the 1:1 ImdbId:MovieId relationship? In looking (admittedly very briefly) at the model files, it seems maybe you could add a MovieVersion class:

        public int MovieId { get; set; }
        public Movie Movie { get; set; }
        public bool Monitored { get; set; }    // MAYBE...if need to monitor separately
        public string Path { get; set; }   // MAYBE...if multiple versions in 1 folder is a major issue...could also just append profile name to the parent movie folder
        public Profile Profile { get; set; }
        public int ProfileId { get; set; }
        public HashSet<int> Tags { get; set; }
        public MovieFile MovieFile { get; set; }
        public int MovieFileId { get; set; }

Then modify Movie to include:

        public bool AdditionalVersions { get; set; }
        public List<MovieVersion> AdditionlVersions { get; set; }

Then basically in the UI you'd check a box and be able to add additional profiles. So you'd have a primary profile (non-breaking) and alternate profiles. Since profiles include both quality and custom formats, you'd be able to handle both the multiple quality and multiple languages, editions, cuts, etc. requests. Other metadata like Runtime, Year, a VersionTitle may also be needed/wanted. But you get the idea.

Obviously oversimplified and there's a decent amount of work to actually implement this since it touches so many bits of system---movie lists, indexers, importers, parsers, etc. But it would seem to at least avoid breaking changes to the core Movie model (really adding only a bool to the table) and relying on separate tables for these edge cases). And would not over complicate the UI as the changes would be hidden in a check-to-show container. Feels like a major effort but not a ground-up rewrite.

Just a thought form a naive observer.

@ptyork commented on GitHub (Apr 1, 2022): Is there not a _relatively_ easy, non-breaking option that doesn't involve breaking the 1:1 ImdbId:MovieId relationship? In looking (admittedly very briefly) at the model files, it seems maybe you could add a MovieVersion class: ``` public int MovieId { get; set; } public Movie Movie { get; set; } public bool Monitored { get; set; } // MAYBE...if need to monitor separately public string Path { get; set; } // MAYBE...if multiple versions in 1 folder is a major issue...could also just append profile name to the parent movie folder public Profile Profile { get; set; } public int ProfileId { get; set; } public HashSet<int> Tags { get; set; } public MovieFile MovieFile { get; set; } public int MovieFileId { get; set; } ``` Then modify Movie to include: ``` public bool AdditionalVersions { get; set; } public List<MovieVersion> AdditionlVersions { get; set; } ``` Then basically in the UI you'd check a box and be able to add additional profiles. So you'd have a primary profile (non-breaking) and alternate profiles. Since profiles include both quality and custom formats, you'd be able to handle both the multiple quality and multiple languages, editions, cuts, etc. requests. Other metadata like Runtime, Year, a VersionTitle may also be needed/wanted. But you get the idea. Obviously oversimplified and there's a decent amount of work to actually implement this since it touches so many bits of system---movie lists, indexers, importers, parsers, etc. But it would seem to at least avoid breaking changes to the core Movie model (really adding only a bool to the table) and relying on separate tables for these edge cases). And would not over complicate the UI as the changes would be hidden in a check-to-show container. Feels like a major effort but not a ground-up rewrite. Just a thought form a naive observer.

deekerman commented

Author

Owner

@nakda commented on GitHub (Apr 6, 2022):

I simply want to contribute with my requirements related to this feature:

I have got several users connected to my Plex server, and they add movies through a request management system (Overseerr, Petio, Ombi, etc.) connected to Radarr
Some users prefer movies in their original audio language, others prefer our local (french) language
In addition to user preferences, it also depends on the movie genre (Animation movies usually preferred in french in all cases for example)

At the moment, the only solution is to run two Radarr instances, with two folder structures, and probably two instances of a request management system.

What I think would best answer our need would be the ability to request multiple Quality Profiles for a movie monitored by Radarr:

When adding a new movie directly from Radarr, I can select multiple profiles (French 1080p, Original 4K, Original 1080p, etc.) representing all the version I want Radarr to find (and that will coexist)
When requesting movies from a request management system, the requester will be able to select the profiles they want to see added because they can be fetched from Radarr (like existing Quality Profiles)
If a movie is already available as the "French 1080p" version, I can request the "French 4K" or any other

The "Keep" toggle suggested above probably won't suit my needs since we might not always want a 1080p and a 4K version. I think it would be best for this to stay flexible.

Does that make sense?

@nakda commented on GitHub (Apr 6, 2022): I simply want to contribute with my requirements related to this feature: - I have got several users connected to my Plex server, and they add movies through a request management system (Overseerr, Petio, Ombi, etc.) connected to Radarr - Some users prefer movies in their original audio language, others prefer our local (french) language - In addition to user preferences, it also depends on the movie genre (Animation movies usually preferred in french in all cases for example) At the moment, the only solution is to run two Radarr instances, with two folder structures, and probably two instances of a request management system. What I think would best answer our need would be the ability to request multiple Quality Profiles for a movie monitored by Radarr: - When adding a new movie directly from Radarr, I can select multiple profiles (French 1080p, Original 4K, Original 1080p, etc.) representing all the version I want Radarr to find (and that will coexist) - When requesting movies from a request management system, the requester will be able to select the profiles they want to see added because they can be fetched from Radarr (like existing Quality Profiles) - If a movie is already available as the "French 1080p" version, I can request the "French 4K" or any other The "Keep" toggle [suggested above](https://github.com/Radarr/Radarr/issues/1910#issuecomment-353178603) probably won't suit my needs since we might not always want a 1080p and a 4K version. I think it would be best for this to stay flexible. Does that make sense?

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Apr 6, 2022):

@Nakda hoe would you handle if two different quality profiles overlap and want to download the same movie?

As far as the keep toggle comments, sounds like that's a use case for the existing process.

@bakerboy448 commented on GitHub (Apr 6, 2022): @Nakda hoe would you handle if two different quality profiles overlap and want to download the same movie? As far as the keep toggle comments, sounds like that's a use case for the existing process.

deekerman commented

Author

Owner

@nakda commented on GitHub (Apr 6, 2022):

@Nakda hoe would you handle if two different quality profiles overlap and want to download the same movie?

As far as the keep toggle comments, sounds like that's a use case for the existing process.

I can't think of a scenario like this, but maybe it's because I'm using Quality Profiles in a different way. Do you have an example in mind?

@nakda commented on GitHub (Apr 6, 2022): > @Nakda hoe would you handle if two different quality profiles overlap and want to download the same movie? > > As far as the keep toggle comments, sounds like that's a use case for the existing process. I can't think of a scenario like this, but maybe it's because I'm using Quality Profiles in a different way. Do you have an example in mind?

deekerman commented