Fix using movie.nfo first when <filename>.nfo also exists

[leovan]

<filename>.nfo is used for store custom information of movie uploader on some private tracker bittorrent website, which is not a valid movie metadata nfo file. Overwrite <filename>.nfo will lead errors with file sharing. Therefor using movie.nfo first may be better when <filename>.nfo also exists.

Changes
Use movie.nfo first when <filename>.nfo also exists.

Issues
Fixes #1558

[Shadowghost]

I don't see an issue with this.

[barronpm]

If there are multiple movies in a folder, would this force the same nfo onto all of them even if they have their own?

[Shadowghost]

That is correct and a problem. Likely the reason why this check was placed after the direct match.

Not sure how we could remedy this though. I'd rather drop this PR if we don't find a way to handle this.

[leovan]

If there are multiple movies in a folder, would this force the same nfo onto all of them even if they have their own?

In this code, I see only when item.IsInMixedFolder is false, movie.nfo will be the candidate metadata file. And in MovieResolver.cs when resolverResult.Count > 1, which I think it means there are multiple video files in parent folder, then isInMixedFolder will be true, then movie.nfo won't be the candidate metadata file.

jellyfin/Emby.Server.Implementations/Library/Resolvers/Movies/MovieResolver.cs

Line 285 in 40f7eb4

var isInMixedFolder = resolverResult.Count > 1 || parent?.IsTopParent == true;

Sorry I didn't fully read the codes. So please check whether the condition !item.IsInMixedFolder && item.ItemType == typeof(Movie) can avoid the problem you mentioned or not.

[leovan]

That is correct and a problem. Likely the reason why this check was placed after the direct match.

Not sure how we could remedy this though. I'd rather drop this PR if we don't find a way to handle this.

If the condition !item.IsInMixedFolder && item.ItemType == typeof(Movie) cannot avoid the problem. A better solution is to check whether <filename>.nfo is valid metadata file. If not then use movie.nfo. Is there a helper function to check whether a nfo file is a valid metadata file (at least is a valid xml file)? In the situation I mentioned before, the <filename.nfo> created by movie uploader is just a plain text file not a valid xml file.

[leovan]

I made a minimal test on my machine and it seems working fine. I think item.IsInMixedFolder can tell whether a movie fold has multiple video files or not.

It uses their own nfo file to show the title.

[Shadowghost]

What you tested is only different movies in a single folder if I understand the pictures correctly?
What we're concerned about is multiple versions in the same folder:

Matrix (1999)
| - Matrix (1999) - 1080p.mkv
| - Matrix (1999) - 1080p.nfo
| - Matrix (1999) - 2160p.mkv
| - Matrix (1999) - 2160p.nfo
| - movie.nfo

[leovan]

I made the test of multiple versions in the same folder, it works too. Besides, 1080p.mkv and 2160p.mkv are the same sample videos, I just copy and change the filename.

[Shadowghost]

Your structure is not correct though, you'd need to test it with a folder structure like this:

<library root>
| - Matrix (1999)
     | - Matrix (1999) - 1080p.mkv
     | - Matrix (1999) - 1080p.nfo
     | - Matrix (1999) - 2160p.mkv
     | - Matrix (1999) - 2160p.nfo
     | - movie.nfo

This is because the multi-version matching depends on the folder name (see our naming guidelines)

[leovan]

Now I can see the problem after changing the parent folder name to Matrix (1999). It use movie.nfo for the collection title which I think is reasonable.

Problem is that it also uses movie.nfo for details of different version. Same title for 1080p and 2160p, Matrix movie.nfo.

After removing movie.nfo, it use Matrix (1999) - 1080p.nfo for the collection title which I think it choose the first nfo file ordered by filename.

But it still has the problem, it also has the same title for 1080p and 2160p, Matrix 1080p.

This problem may be beyond this PR to fix.

So a better way to fix the issue is to check whether <filename>.nfo is a valid xml file before add it to the candidate nfo file list. I will try to fix this issue in this way later.

[Shadowghost]

This problem is know, so it's working as expected even if we have multiple versions. I guess we're fine now. Thanks for testing!

[leovan]

This problem is know, so it's working as expected even if we have multiple versions. I guess we're fine now. Thanks for testing!

You mean current simple solution of this PR for #1558 is OK?