Adding a movie that already exists in Radarr triggers a search that skips the isAvailable gate

[kinn81]

Description

When Seerr adds a movie that already exists/is monitored in Radarr, it triggers a Radarr movie search that ignores the availability status. In the rare situation that a different movie with the same name and release year exists, Radarr will grab it (depending on Radarr config). This is a rare but observed situation.

I think when adding a movie, SearchMovie() should only be triggered if movie.isAvailable = true. This should largely mitigate the above problem and more closely follow the other addMovie logic.

Version

3.4.1

Steps to Reproduce

1. Directly in Radarr, add a movie that releases in the future (Movie1) and happens to have a different, but identically named, movie already released in the same year (Movie2). Radarr is now monitoring Movie1 and will search for it once it releases.
2. In Seerr, request Movie1.
3. Seerr will determine that Movie1 already exists in Radarr and initiate movie search. Calling SearchMovie() directly ignores the isAvailable status of Movie1 and could, depending on Radarr config, result in grabbing Movie2 incorrectly.

Screenshots

No response

Logs

Platform

desktop

Database

SQLite (default)

Device

Ubuntu laptop

Operating System

Ubuntu

Browser

Firefox

Additional Context

No response

Search Existing Issues

• Yes, I have searched existing issues.

Code of Conduct

• I agree to follow Seerr's Code of Conduct

[kinn81]

If it's agreed this is a good change I'd like to work on it (fix logic in radarr.ts AddMovie, create some appropriate tests).

[fallenbagel]

I looked into this, but the issue described in the description isn't quite what is happening.

Nothing in this path identifies the movie by title and year. We look it up by tmdbId and then call MoviesSearch with Radarr's internal movie ID. The mismatch you describe is Radarr matching indexer releases to movies by parsed title and year. If two movies have the same title and year, Radarr can't tell them apart.

The only thing on our side is that we call the search command directly here:

seerr/server/api/servarr/radarr.ts

Lines 194 to 204 in a53f49b

	if (options.searchNow && !movie.hasFile) {
	logger.info(
	'Triggering search for existing monitored movie without file',
	{
	label: 'Radarr',
	movieId: movie.id,
	movieTitle: movie.title,
	}
	);
	this.searchMovie(movie.id);
	}

That goes through POST /api/v3/command, and Radarr treats API-submitted commands as CommandTrigger.Manual. That sets userInvokedSearch, which skips the movie availability check:
https://github.com/Radarr/Radarr/blob/a96bf7c3ecb23cb76993770727285dc17a613fbc/src/NzbDrone.Core/IndexerSearch/MoviesSearchService.cs#L42-L45

The availability spec then skips its check too, so the release isn't rejected either:
https://github.com/Radarr/Radarr/blob/a96bf7c3ecb23cb76993770727285dc17a613fbc/src/NzbDrone.Core/DecisionEngine/Specifications/RssSync/AvailabilitySpecification.cs#L23-L27

The other two addMovie paths use addOptions.searchForMovie instead. That ends up in MovieScannedHandler, which submits the same command with the default trigger. Since it isn't user-invoked, Radarr checks availability before searching:
https://github.com/Radarr/Radarr/blob/a96bf7c3ecb23cb76993770727285dc17a613fbc/src/NzbDrone.Core/Movies/MovieScannedHandler.cs#L42-L45

So the monitored path is effectively bypassing the minimum availability setting while the other two paths respect it.

As you suggested, yes gating this on isAvailable does make sense since Radarr already returns that based on the configured availability delay, so we're using the same value Radarr would use for the normal search flow. You can go ahead and create a PR for that.

That said, this only fixes us forcing a search that Radarr wouldn't otherwise run. It doesn't fix the actual Movie1/Movie2 mismatch. Once Movie1 reaches its minimum availability, Radarr can still search and match a Movie2 release if both have the same parsed title and year. That's on Radarr, a Radarr matching limitation, and not Seerr.

[kinn81]

Thanks for clarifying, we are on the same page. I was referring only to gating the two calls to this.searchMovie (the other is in the branch that re-monitors an existing movie). This will mitigate, but not eliminate, the issue, which as you say is actually happening in Radarr.

I'll put a PR through for this.