identification with date matchs media without date

[xp-1000 1]

Hello,

May be it is an implementation choice or a very minor bug but I found this behavior on emby server 4.5.4.

the identify search feature does not exclude movies without date when a date is explicitly provided in search criteria.

In my opinion this is not the desired behavior so I would like to inform you (in the past I would probably make a PR).

It seems trivial when using the identify manually: you provide a date and it retrieve also bad movies, you choose the right and that is good.
Nevertheless, it also affect the automatic identify feature which is most serious in my case (sometimes I have to recreate a lib and I have to identify manually again tens of this case)

"Train to busan" movie search with "themoviedb" as first indexer is a great example to reproduce:

- at the moment of writing, the search on the themoviedb provides 3 results: https://www.themoviedb.org/search?query=Train to Busan

If you try to identify this movie from emby without providing date:

Which is exactly what I expect (same result)

But if you provide "2016" as date in search criteria (which is what the automatic search does I suppose):

"Peninsula" disappeared because 2020 != 2016 ok but the other one not.

the intuitive behavior (at least for me) is that null != 2016 but may be it is desired.

Even if you agree about this point, you will could say the real problem comes from themoviedb api and you are probably right.

That said, please you can trust me this is not an isolated case so I think it is good to bring this to your knowledge.

As a workaround we can change the name of the file to a different language than english, in this example search for "Busanhaeng" instead of "Train to Busan" will remove the element without date and the provided date will exclude "Peninsula" so it works.

The drawback is we cannot follow an uniq naming convention for our files (e.g. first name in english or in original language for all movies).

I fully understand if you consider this issue as not a bug or very low priority I just want to let you know and choose

Edited February 25, 2021 by xp-1000

[Luke 36997]

Hi, there is currently a one year tolerance to account for different release years in different countries.

[xp-1000 1]

ok but this is out of the described issue

[Luke 36997]

Right OK, yes you're talking about a null year coming from the provider. Yea that's a tough one I guess. 

[xp-1000 1]

yes and pretty minor I confess, I just would like to make you aware of this.

while you understand the issue it is all that matters.

Edited February 28, 2021 by xp-1000

[Luke 36997]

Thanks for the info.

[xp-1000 1]

I checked and I have more movies than I thought wrongly identified because of this border case.

@Lukeis there any ability to "force" identifying for a file ?

I know emby can write metadata file next to video file, may be the reverse is also possible (read metadata info from file next to the video file like the IMDB ID) ?

thanks for your anwers

[Happy2Play 8238]

You can just add the providerid to the naming scheme.

see ID Tags in Folder & File Names section of the kb

Emby Movie Naming : Emby

But in theory a nfo file containing the proper providerid tag should do the same thing.  But have never test this limited information via nfo file though.

[xp-1000 1]

thank you @Happy2Play

I would prefer to not having to add the id into the filename to keep it clean but it seems to be a good workaround.

Given that you seem think it should work from nfo file I did more test from my side. In fact I did not understand there is 2 separate features:

- scan reads nfo file if available and use the themoviedbid inside for identifying. this feature is enabled by default (I don't think we ca disable it).
- nfo exporter which is the feature I known avaialble on the lib settings and which is disabled by default.

In my last question I think about the first and did not know this is the native behavior.
Because I enabled it in combination with real time monitoring and renamed the movie file (mkv) BEFORE the nfo file (not fast enough I suppose), emby did not read the nfo and I probably simply erased the one generated by emby.

As far as I understand how it works, if someone look for reliable identifying metadata from the file system information only (to be able to recreate libs in emby without problem) so, I would recommend to:

- give read only permission to emby for your directories
- make a scan of these directories with lib without nfo writer enabled (it does not have permission so it is useless)
- list all wrongly identified movies (sometimes changing the language of movie title will allow emby to retrieve the right one in first but sometimes there is absolutely no solution to perform right automatic identify only from name).
- create a temp directory and create a symlink for each file in list
- create a lib for this tmp directory with nfo writer enabled and make a scan
- fix all movies in this tmp lib manually, this will write right nfo file next to the symlink
- now copy these generated nfo next the original file
- you can delete the tmp directory / lib
- from now you can recreate libs emby will always identify the right movie for your files thanks to the nfo

Obviously you still need to keep this nfo (if you move or rename the movie file) next to the movie file and with the same name but you can keep real time monitoring without any risk without to be careful to the order of your operation (works even if you rename the movie file before the nfo file).

Of course this will not work with libs where nfo writer is enabled (and emby has write permissions to directories) while you cannot prevent emby to erase the nfo with bad metadata (retrieved from automatic identify). In this case, you still can rename / move file and prevent bad identify changing the nfo file BEFORE the movie file.

everyone has their preferences, the thing matters is to understand there are 2 differents steps:
- at scan and when found new file (renamed, added, moved..) emby reads any nfo file and allows to identify problematic movies
- at each identifying (manual or automatic), emby writes nfo file from its current state IF this option is enabled in lib

If you want use nfo writer I would advice to:
- consider emby as the "reference" and not your filesystem
- if you make any change on your filesystem level (like file renaming) you have to either reflect this change manually in emby (like re-identifying manually the bad match) or ALWAYS perform your operation on nfo BEFORE on each movie file

I hope this can help other who can now fully understand the nfo read/write separation as for me.

@Luke I still think that simply sorting the returned results from themoviedb api by "best" match at identify should allow user to cover almost all cases and make emby more reliable to filesystem changes (at least if movie is correctly named in first place). I see 2 possible improvements:
- put the "null" date movies at the end of the list (when date has been provided in search criteria)
- priorize result == to the title file name over result which only "contains" the title file name
This will not change the number of results (for manual search) but will allow the automatic identify to works drastically better.

[xp-1000 1]

fyi, according to my test the emby parser gives too many fails sadly I took the decision to create nfo for all my files and give read only access to emby.

this is the best way in my current understanding to make emby identification reliable over all situations.

I tested on a fresh instance of emby and I fall from 64 mismatch to ... 0

Note these 64 mismatch are totally impossible to resolve "automatically" (except using id in name as suggested by @Happy2Play).
The only way to identify these problematic movies was to identify them manually and as soon as you use this way you can be sure any filesystem operation (like a simple rename of the file) will lead to a new identification fail (which is obviously silent so very difficult to track).

In my opinion, I think the automatic identify should be more strict: it is easy to track movies withtout metadata but very painful to track movies with wrong metadata and in the current emby behavior this is something which happen often enough to be a problem.

[Luke 36997]

Hi there, can you please go over an example? Thanks.

[xp-1000 1]

Hello @luke

I think "train to busan" described in my first post is a good example of movie which will never match because of null date.

for an example about priorizing an exact match over a partial match you can use "Promare".

There 3 movies containing "promare" from themoviedb response and from the same date. of course emby parser should return all of them but it can returns the exact match before the others so there will have no error.

In the current behavior, as for "train to busan" which returns the null date as first result, it will take the first one "Promare: Lio-hen" which is an error.

Promare (2019)
└── Promare (2019) - MULTI.1080p.BluRay.HEVC.mkv
Promare: Galo-hen (2019)
└── Promare: Galo-hen (2019) - VOSTFR.1080p.BluRay.HEVC.mkv
Promare: Lio-hen (2019)
└── Promare: Lio-hen (2019) - VOSTFR.1080p.BluRay.HEVC.mkv
Train to Busan (2016)
├── Train to Busan (2016) - MULTI.1080p.BluRay.AVC.mkv
└── Train to Busan (2016) - MULTI.1080p.BluRay.HEVC.mkv

suppose you have this tree on your file system, the result on emby will be:

- Promare: Galo-hen : OK
- Promare: Lio-hen: OK
- Promare: KO (shown as errored duplicate of the previous)
- Train to busan: only one KO (because combined into versions) using the "empty" first result (red square in my first post)

If you name the movie "Busanhaeng" it does not match the "empty" result and "Train to busan" is correctly found.
however, it is not always possible to find a name which works as in this example.

If you want to try the exercice, check https://www.themoviedb.org/movie/300668-annihilation or https://www.themoviedb.org/movie/409421-blame
I am totally unable to make emby identify these movies himself only from the name no matter what I tried.

Of course all these results depend on the themoviedb indexer (which is the one enabled in my lib) but you should find totally different behavior if using another indexer.

I decided to write nfo everywhere with correct metadata set in emby and then remove permissions to emby to prevent it to update to wrong movie (for example if I rename or move "promare" or "train to busan", it will read the nfo and there is no risk it erase with its usual wrong match even if I move the movie before the nfo.

so it is ok for me you can close this issue but I would be happy to help you if you want more information.

Edited March 3, 2021 by xp-1000

[Luke 36997]

Thanks for the info. We'll look at what improvements can be made based on this.