Then why is the issue persistent on another system, with “correct naming”, which has no metadata cached (because it’s a fresh install)?
Did you not get an instant match? Or did you go directly to Fix Match - because that’s what you normally do?
I have to Fix Match on at least 10% of files Plex is already Fumbling - so I don’t need to ‘Create’ a reason to Fix Match. I prefer to ‘Prevent’ Fix Match if possible and the best way I know is proper file naming. <—and it worked instantly - as expected.
The screenshots above are all auto-matched. This is the honestly the first time I’ve had to Fix Match for a Movies item.
I bet most of y’all are cringing at this file name but Plex didn’t even flinch, so you can see why I think that the file name is the least concern…
Had exactly the same behaviour as the autor of this post with this movie. My file is called Countdown (2019).mp4 and I scrub all metadata enbedded from the file (like I always do). Scan library files then auto matched it with the 2016 movie. Very odd but a quick fix match resolved the problem so all was well again with the world! Interestingly I had to select the second movie found on the list.
I’m not waiving the fact that the file itself isn’t to blame. Its from the release group AAA, so I’m going through other AAA movies (thank god that I kept the scene name) to see if they have any issues or not.
Is this automated or do you do this manually?
Your problem is very likely the embedded Title Field in that MP4:
Do this under ALL TABS in Shows and Movies - then refresh metadata:
Red: Where Local Media Assets was
Green: Where it goes
Yeah I’ve ordered it like that. So in theory, before even touching the file contents, it would have fetched metadata from the folder name itself, which was always proper.
@dokuro said he scrubbed the embedded metadata, so that should not be an issue.
I had to do this too, but it’s a hassle when you don’t use a PC all the time.
It’s not my intent to pile on, but the reason we cringe at such file names is that they do not match the guidelines clearly laid out by Plex for naming files for movie libraries. Experience has taught us that such files will, eventually, cause problems.
The problems which such files are two-fold: The year is not enclosed in parentheses as it should be and there is a bunch of extraneous information the scanner has to parse and attempt to match.
The year, in particular, is extremely important in helping to disambiguate matches where there are multiple, equally valid, choices. If the year is not enclosed in parentheses, it is treated as part of the file name, not the release year. So, as far as the scanner is concerned, the release year has not been provided and all movies which match that name are equal.
This is where problem two comes in. With all the extraneous information in the file name, Plex has to consider more movies as potential matches than it otherwise would. That’s likely why you saw such low confidence scores with your original match attempt. All information which is not the actual movie name, and not the year, should be enclosed in square brackets so that Plex will ignore it during the matching process.
So, back to your original question: “Is there a way to know why Plex prefers the wrong metadata?” One correct answer is the one given several times in this thread, file naming. Given your additional testing it may be that you are experiencing other issues as well, but the file naming problem was likely the catalyst.
Your experience has taught you that “scene” names are fine for Plex’s scanners/agents. However, the lesson learned should have been that you’ve gotten lucky to this point. At some point it will break.
Also note that none of this suggests Plex’s scanners are perfect and will always find the correct match and metadata with correct file names. Unfortunately that is not the case. However, it stands a far better chance of success if the guidelines are followed.
1 Like
Thank you for the detailed post.
I got the same score on a different machine, with a fresh PMS and OS install, with the correct file and folder name. Please explain that, if you can.
@anon5074910 also faced the same exact issue however he scrubbed the metadata from the start.
Or maybe the software was developed in-mind for users possessing pirated content, with janky file names that most people otherwise don’t have the time or patience to sort out and maybe a guideline exists just to be on the safe side.
I cannot, and it was never my intent to. My intent was help explain why we find the file names being used problematic. Obviously there is something else in play here, be it a caching issue or some other phenomenon.
[Edit]
In the interest of full disclosure, I experienced an issue matching Countdown (2019) as well. As a test, I added it to my library as ./Movies/Countdown (2019)/Countdown (2019).mkv. I use Plex Movie as my agent for this library, and it preferred the 2016 movie over the one from 2019. Using The Movie Database as the agent doesn’t exhibit the incorrect match.
Plex Movie:
The Movie Database:
Not a big deal as a fix manually sorts it out but wanted to come back on a few points…
I use a tool to wipe all metadata from my files before they even get near my library to be scanned by plex, been doing this for years so I’m confident there is no local data in my file.
My agent is setup as follows … and you can see local is second on the list (again its always been like this).
Also… if I unmatch the movie (delete both local cache from plex servers, clear bundles and also cache from my browser ) and then try and search match using the following…
the results which are returned are as follows …
with the 2016 version of the movie at the top of the list which would be used in a auto matching scenario.
If I had to guess it could be a problem with TMDB’s api or cache returning the wrong list of values.
Again – no big deal as a fix match fixes the problem but it is certainly interesting as I’ve never seen something like this happen before with my close to 2,000 movie library.
@JuiceWSA seems hell bent on proving its a file naming issue for some reason.
I tend to agree with the idea of this being some sort of API problem with TMDB. I also do not rename files to match the “recommended” file name format. I have processed thousands of movies and I would guess that 99% of them match without issues. The few times that they do not match, I usually find a typo in the directory name that I placed the file in. However, there are a few examples (like yours) that I have been left scratching my head as to why it doesn’t match and I end up forcing it to match.
While Plex may be optimized to use a specific naming convention, I disagree strongly that it doesn’t work if you don’t. The matching algorithm that it uses is remarkably robust in my experience and it usually figures it out properly. That’s why I would agree that this is likely specific to this title and an issue on the backend.
1 Like
To add some info, having the year in the filename and not in parenthesis, can in some cases produce a wrong match.
a) Movie.year.mkv vs b) Movie (year).mkv
When PMS searches for a), it uses “movie” and “year” as the search terms for the title. The title match has a higher weight for scoring. The year just helps refine that result. When searching b) it only uses “movie” for the title. Some movies are stored by the agent with the year as part of the title too. “Movie (year)”.
So searching the term “movie year” could textually match better to “movie (year)” even if the years are different. Then when adjusting the score for the year, the score could still be higher, so you get a bad match.
This is complete BS. Several people have successfully reproduced the issue with proper naming.
What’s “shocking” about it?
It seems like you’re the one acting like a child here.
There is no issue with the naming, period.
It has always worked. This issue is not even remotely related to the naming.
The year was inside parentheses for all test cases.
Glad for that now all of us can sleep with a good conscience.
1 Like
