Deleting in Overseerr also deletes in Sonarr/Radarr

[boultonn]

Description

Deleting an item in Overseerr also deletes the linked item in Sonarr/Radarr to avoid a build-up of unwanted titles, and so it doesn't have to be removed in multiple places.

Desired Behavior

When deleting a previously approved item, either automatically delete from Sonarr/Radarr too, or provide a prompt or configuration parameter to specific whether the item is deleted from Sonarr/Radarr and if this includes deleting the files too.

Additional Context

None.

[modem7]

I'd actually argue that the other way round, where deleting items in *arr deletes in overseer would make more sense from a workflow perspective.

Assuming ofc the workflow (as I see it) is:

Request (overseer) > grab/manage (*arr).

This would tie in with #377.

[richard-lee-863]

I am a fan of this idea. I like to expose Overseerr to my users so they can easily request things, but as an admin i would also like to manage media here.
The fact that Overseerr can sync with Plex library to keep up to date record on which files are actually present makes a good case for deletions to be managed here too. I don't believe Radarr has as nice a sync feature.

As an admin i'd like to manage the higher level stuff in one place, but i can see the other side of the coin of managing deletions in Sonarr/Radarr too.

I guess its more useful to have this feature when dealing with a small HDD Seedbox, as opposed to people who have large storage and intend to keep things around.

[TheCatLady]

I am a fan of this idea. I like to expose Overseerr to my users so they can easily request things, but as an admin i would also like to manage media here. The fact that Overseerr can sync with Plex library to keep up to date record on which files are actually present makes a good case for deletions to be managed here too. I don't believe Radarr has as nice a sync feature.

As an admin i'd like to manage the higher level stuff in one place, but i can see the other side of the coin of managing deletions in Sonarr/Radarr too.

I guess its more useful to have this feature when dealing with a small HDD Seedbox, as opposed to people who have large storage and intend to keep things around.

Overseerr actually does not keep track of your media files. And deletion of media files from within Overseerr will not be implemented (see #1924).

[richard-lee-863]

Ah i thought that is what is being presented by the "Recently Added" data, which is populated from running the "manual library scan"?

[TheCatLady]

Ah i thought that is what is being presented by the "Recently Added" data, which is populated from running the "manual library scan"?

Overseerr only keeps track of whether or not items are available, using data from Plex and the *arrs. Overseerr does not keep track of (or have access to) your media files.

[TheCatLady]

As per internal team discussion, closing this. Sorry folks! This is really a duplicate of another declined feature request #1924, just via the *arrs.

[dedworks]

As per internal team discussion, closing this. Sorry folks! This is really a duplicate of another declined feature request #1924, just via the *arrs.

Seems like #1924 was rejected for wariness of destroying data which is a great decision.

This request is not similar. It can't destroy data, it only involves selection of what will be downloaded in the future, which is precisely what overseerr is for (if I'm not mistaken).

What possible motivation could one have to delete a request, if it will not stop the disk from filling?

It's no use to remove the entry from overseerr's request history, if it won't stop the *arrs from consuming every last bit of the resources it would if I didn't delete it.

[TheCatLady]

This request is not similar. It can't destroy data, it only involves selection of what will be downloaded in the future, which is precisely what overseerr is for (if I'm not mistaken).

This is not true. A request could be deleted after the media has already become available or partially available, in which case this could be a destructive action.

What possible motivation could one have to delete a request, if it will not stop the disk from filling?

Deletion of requests is not intended to be performed on a regular basis. Overseerr wants to keep a record of requests for features like quotas. On the rare occasions an approved request needs to be canceled, the item should be deleted on the *arr side. It is planned for Overseerr to detect deleted items during scans in the future, but there are no plans to support initiating media deletion from within Overseerr.

[jaschuu]

"It is planned for Overseerr to detect deleted items during scans in the future"

Has this been done or had a date for when it will be?

[gravelfreeman]

"It is planned for Overseerr to detect deleted items during scans in the future"

Has this been done or had a date for when it will be?

Yeah because I'm at the point where my request dataset is full and I want to clean it up. It's very cumbersome to have to delete it from the Arrs AND Overseerr otherwise Overseerr will keep adding the request back in the queue which doesn't make any sense.

This really must get fixed, I don't see this behaviour as a feature request but an actual issue that must get fixed.

If I order something online and then I trash it, I don't want the order to get through infinitely, Overseer requests aren't groceries.

[abranski]

I agree 100%. If the overseer is the entry point to the entire ecosystem and has the ability to add new items, it MUST have the ability to remove them. Otherwise, its operation becomes unintuitive.

[gravelfreeman]

I think since a year the stuff you delete in radarr/sonarr removes the request in overseerr as well. It sure would be best to be able to let the user decide whether he wants to delete from overseerr or the arrs.