starred/Radarr

Fork 0

mirror of https://github.com/Radarr/Radarr.git synced 2026-03-02 22:57:34 -05:00

Ghostbuster (2016) mismatch to the old movie (1984) #4654

New issue

Open

opened 2026-02-19 22:47:58 -05:00 by deekerman · 10 comments

deekerman commented

2026-02-19 22:47:58 -05:00

Owner

Originally created by @Haldir31 on GitHub (Aug 13, 2020).

Describe the bug
During the import for existing movie, I have ghostbuster movie with the old version from 1984 and the new one from 2016. Folder name is formatted as "Movie Name (Year)"

To Reproduce
Steps to reproduce the behavior:

Create two folder named Ghostbusters (1984) & Ghostbusters (2016)
Go in https:///add/import
Start import
Both movie are displayed with the expected folder name but the movie match is only for the 1984 version

Expected behavior
Based on the movie name and the year, both version should match with their respective year. To have a expected match, folder have to include the IMDB ID. TMDB ID is not able to override the match and use the 2016 version.

Screenshots

Platform Information (please complete the following information):

OS: MacOS 10.15.6
Mono Version: .Net Core 6.10.0 (Stable Channel)
Browser and Version [e.g. chrome, safari] (Only needed for UI issues)
Radarr Version: 3.0.0.3406

AB#828

deekerman added the

Type: Bug

Status: Confirmed

On Hold: MetadataAPI Blocking

labels

2026-02-19 22:47:58 -05:00

deekerman commented

2026-02-19 22:47:59 -05:00

Author

Owner

@austinwbest commented on GitHub (Aug 19, 2020):

I added both ghostbusters to a root folder and went to import, it detected them both without issue.

@austinwbest commented on GitHub (Aug 19, 2020): ![Annotation 2020-08-19 130508](https://user-images.githubusercontent.com/8321115/90667387-b2814780-e21c-11ea-83d1-9835f402bdca.png) I added both ghostbusters to a root folder and went to import, it detected them both without issue.

deekerman commented

2026-02-19 22:47:59 -05:00

Author

Owner

@mopey69 commented on GitHub (Aug 21, 2020):

v2 did the same with this movie.

@mopey69 commented on GitHub (Aug 21, 2020): v2 did the same with this movie.

deekerman commented

2026-02-19 22:47:59 -05:00

Author

Owner

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

I can re-produce this

It happens because the metadata server returns the 1984 movie first even when using the year=2016 parameter
https://radarrapi.servarr.com/v1/search?q=ghostbusters&year=2016

That happens becuase TMDB returns the 1984 movie first even when a year is passed.
https://api.themoviedb.org/3/search/movie?api_key=1a7373301961d03f97f853a876dd1212&query=ghostbusters&year=2016

SO... this is really a TMDB search issue.

@Qstick commented on GitHub (Aug 22, 2020): I can re-produce this ![image](https://user-images.githubusercontent.com/376117/90949178-45d09d80-e414-11ea-88e0-23fa9df4cc48.png) It happens because the metadata server returns the 1984 movie first even when using the year=2016 parameter https://radarrapi.servarr.com/v1/search?q=ghostbusters&year=2016 That happens becuase TMDB returns the 1984 movie first even when a year is passed. https://api.themoviedb.org/3/search/movie?api_key=1a7373301961d03f97f853a876dd1212&query=ghostbusters&year=2016 SO... this is really a TMDB search issue.

deekerman commented

2026-02-19 22:47:59 -05:00

Author

Owner

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

Actually the issue is we use &year when calling TMDB which means it will return results that have ANY release information for a given year. We should likely start with &primary_release_year parameter.

Would be nice if they would prioritize results with a primary release year first when searching by year

@Qstick commented on GitHub (Aug 22, 2020): Actually the issue is we use `&year` when calling TMDB which means it will return results that have ANY release information for a given year. We should likely start with `&primary_release_year` parameter. Would be nice if they would prioritize results with a primary release year first when searching by year

deekerman commented

2026-02-19 22:47:59 -05:00

Author

Owner

@stale[bot] commented on GitHub (Jan 8, 2022):

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 (Jan 8, 2022): 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

2026-02-19 22:47:59 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Jan 8, 2022):

Would this help / fix this?

https://github.com/Radarr/Radarr/pull/6870

@bakerboy448 commented on GitHub (Jan 8, 2022): Would this help / fix this? https://github.com/Radarr/Radarr/pull/6870

deekerman commented

2026-02-19 22:47:59 -05:00

Author

Owner

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

Yes, this is the same issue. And I would still suggest that "the API gives this order so it not our problem" is not helpful to the user's experience.

@howardjones commented on GitHub (Jan 23, 2022): Yes, this is the same issue. And I would still suggest that "the API gives this order so it not our problem" is not helpful to the user's experience.

deekerman commented

2026-02-19 22:47:59 -05:00

Author

Owner

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

Yes, this is the same issue. And I would still suggest that "the API gives this order so it not our problem" is not helpful to the user's experience.

Where exactly does it say this is not our problem?

Q clearly said we should change things, as in radarr, as in this is something we can possibly take care of, as in the complete opposite of what you are quoting.

Maybe I am missing some posts on the thread though so please quote the post that says that so I have some clarification if you don't mind bud.

@austinwbest commented on GitHub (Jan 23, 2022): > Yes, this is the same issue. And I would still suggest that "the API gives this order so it not our problem" is not helpful to the user's experience. Where exactly does it say this is not our problem? Q clearly said we should change things, as in radarr, as in this is something we can possibly take care of, as in the complete opposite of what you are quoting. Maybe I am missing some posts on the thread though so please quote the post that says that so I have some clarification if you don't mind bud.

deekerman commented

2026-02-19 22:47:59 -05:00

Author

Owner

@howardjones commented on GitHub (Jan 24, 2022):

Sure, "On Hold: Metadata API blocking"? Or this: https://www.reddit.com/r/radarr/comments/rnlp69/comment/hpt2u1a

@howardjones commented on GitHub (Jan 24, 2022): Sure, "On Hold: Metadata API blocking"? Or this: https://www.reddit.com/r/radarr/comments/rnlp69/comment/hpt2u1a

deekerman commented

2026-02-19 22:47:59 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Jan 24, 2022):

Metadata meaning it'd be something to correct in our metadata server if TMDB won't cooperate.

But there's also already a PR going relating to this.

If it's something that would not be fixed - it would be closed.

@bakerboy448 commented on GitHub (Jan 24, 2022): Metadata meaning it'd be something to correct in our metadata server if TMDB won't cooperate. But there's also already a PR going relating to this. If it's something that would not be fixed - it would be closed.