Requests made to an old/deleted instance never get repopulated in a new radarr instance.

[arma26]

Setup and connect Radarr and Overseerr together.
Add a number of requests to Overseerr.
Delete/disconnect the Radarr instance.
Create a fresh new Radarr instance and connect it to Overseerr.
Continue adding requests.

My radarr instance shows 59 missing and my overseerr instance shows 85 open requests. I've manually ran all the jobs/tasks and waited at least 24 hours to see if this would resolve itself. There doesn't seem to be a way to force any type of consistency check to ensure previously Requests are still being tracked after initially accepted.

[TheCatLady]

Overseerr only communicates requests to the *arrs at the time that they are approved.

When purging the *arrs, it is also recommended to start fresh with Overseerr. The alternative is to go through the old requests and manually add them to the *arrs.

[arma26]

Which is reasonable in most cases, however I think there should be a manual job or something to be able to re-add things that exist in overseer to radarr or things which radarr already has as missing to show as automatically requested in overseerr. For instance, if the database of radarr gets corrupted, like if you're operating it over NFS, it's only a matter of time till your sqlite db gets corrupted, it's just the nature of the thing. Or if you restore radarr from a database backup. What happens when there's a breaking version change, these things happen and most of the time inconveniently. Sometimes it's just better to start fresh instead of migrating, in cases with a tool like Radarr I could see it happening if there was a significant improvement to the way it handles importing libraries automatically.

[TheCatLady]

Overseerr will automatically mark items already present in Radarr/Sonarr as requested, but will not re-request items that are missing in the Radarr/Sonarr servers if they are missing. Requests are associated with specific Radarr/Sonarr servers, and submitting them in bulk to new, different servers can have undesired effects.

Overseerr is not designed to help you recover from Radarr/Sonarr database failures. You should fix your setup so that it isn't "only a matter of time till your sqlite db gets corrupted."

[bakerboy448]

like if you're operating it over NFS, it's only a matter of time till your sqlite db gets corrupted

so what you're saying is using something in an unsupported manner that always breaks - and goes against *arr dev and SQLite's own statements is a valid usecase/example?

by that same logic it's Ford's fault that a Mustang falls apart trying to tow a 747 and it's totally ford that needs to fix their broken mustang

[arma26]

Those were examples, perfectly valid ones, but whatever. I'm putting forth a scenario which I think affects user experience. Admins are supposed to use this tool to simplify user requests from presumably non technical people and improve the admin's quality of life, correct? A user comes to me and says I requested this thing, when can I expect it to be downloaded, so I check and notice that there's an incongruity between the two services that are supposed to be working together. So now I go back to the user and say "Sorry, there was an issue, I'm going to delete everything, please resubmit your 85 requests and it'll probably work the next time."

A perfectly valid work around would just be a sql query to dump a list of movies, and delete all the current ones, and run another sql query to import them again to force them to re-home on the new radarr instance.

Now, I can understand if something is out of the scope of the project, usually there's work arounds and I'm fine discussing and implementing those, but I don't think being overly dismissive is very constructive and probably you should probably just stop replying. However I don't think the scenario lacks merit, maybe it's not appropriate for Overseerr, and could be served better with another tool, but my point stands.

[TheCatLady]

I appreciate your recognition that your request may be out of scope for the project, but it was not my intention to be "overly dismissive." Rather, I was just stating my opinion on the matter that the scenarios you listed should not happen if your services are configured and set up properly.

That said, you can totally query Overseer's DB and do whatever you like with the results. That is not within the realm of what we provide support for, though.

[TheCatLady]

Also, Overseerr has a well-documented API. You can likely write a script to do what you need using just the API, but again, that's outside of what we support.