Emby Xml plugin does not recognize 3D tags - Nfo reader duplicates ID

[chjohans 32]

I have a library with 3D movies and when I'm adding this to Emby it does not seem to correctly identify these titles as 3D, all are HSBS. THis is in the xml:

 

<MediaInfo>

   < Video>

   .....

   <Format3D>HSBS</Format3D>

</Video>

 

See the attached xml for the full file.

 

And of course the Emby XML reader is set with priority over the nfo reader (I have nfo's as well),

 

If I set the nfo reader with first priority it correctly identifies the 3D titles as HSBS,

 

BUT, the nfo reader gives me a dfferent problem. It will set "IMDd Id" and "TheMovieDb Id" to the same id and both will be the "TheMovieDb Id", obviously the IMDb Id is not the same as that from TheMovieDb.

 

This problem started a few weeks ago, and since Luke keeps telling me not to use MCM for metadata I thought I would try the XML reader before reporting this.

 

But there is a problem, the nfo reader will add both ID's as the same number, which is obviously wrong. (I noticed thie because BlurN would keep showing me movies that I already had and had watched, so that made me dig and I found this).

 

And the XML reader will not correctly identify the 3D tag.

 

Se attached example of xml and nfo. (zipped since it wouldn't let me upload them without)

 

See also the screenshot that shows how both IDs are set to the same when the Nfo reader has precedence, this does not happen if I move the Xml reader on top.

Avatar (2009) HSBS.zip

Edited March 20, 2018 by chjohans

[Luke 37185]

Hi, at this point we're dependant on community help to hunt down and resolve the XML issue. We no longer have the bandwidth to personally develop and test this plugin. The source code can be found here:

https://github.com/MediaBrowser/XmlMetadata

I would strongly suggest using our built in nfo support. Thanks.

[chjohans 32]

I did use the nfo, but the issee was as I describe above. It would set both the TheMovieDb ID and IMDb id to the same, and both would be set to the ID from TheMovieDb, in my .nfo (see the attachment above) they are both set correctly. This caused a lot of issues.

 

Deleting my libraries and importing them again with the XML reader resolved that issue, but it does not correctly read the 3D tags as I decsribed above.

 

So I'm kind of stuck to chose between two evils here....

Edited March 21, 2018 by chjohans

[chjohans 32]

I had a look at the source code for the XML plugin, to me it looks like it at least tries to read the 3D tags. Have a look here:

 

https://github.com/MediaBrowser/XmlMetadata/blob/master/XmlMetadata/Parsers/BaseItemXmlParser.cs#L676

 

But I don't know the internal workings of things nor did I attempt to trace any of the variables, but it sure means to read those tags. But something prevents this from working, at least in my case, my xml attached above indeed has the correct 3D tag.

Edited March 21, 2018 by chjohans

[Luke 37185]

In regards to nfo, probably because the nfo was saved incorrectly?

[chjohans 32]

Not at all an useful answer

 

Did you look at my attached nfo at all or are you just assuming?

 

Emby used to read all my 2000+ nfo's just fine, when I removed and added my libraries a while ago (during the constant sync to Emby for Kodi bug) this happened. When Emby added my titles again after that it set both ID's to the same ID, only the TheMovieDb Id is correct, the IMDb Id is set to the same id which is obviously wrong.

 

I did pay for a lifetime Premiere license, for two systems actually. You could at least pretend to give me some support in return

[Luke 37185]

I've never seen this variation of id's before:

<id moviedb="tmdb">19995</id>
	<id moviedb="themoviedb">19995</id>

we support

<id imdb="xxx"></id>
<id tmdb="xxx"></id>

if those attributes arent' there, then we assume this to be tmdb:

<id>19995</id>

So i guess yours is falling into that.

[chjohans 32]

OK thanks, that was very useful

 

I'll ask Pete over at the MCM why he writes all those tags, he's trying to support multiple systems. He used to support Mediabrowser/Emby quite well, but I guess he might be slipping lately. This issue is so major that I probably will dump MCM.

Edited March 22, 2018 by chjohans

[Luke 37185]

He doesn't really have to support emby specifically.

 

We base our nfo support on what's documented in the Kodi wiki. If he supports that he supports emby.

[chjohans 32]

@@Luke

Sorry to be a nag but could you possily spare a minimum of time to just look at the Xml reader code and see if you see something obvious why it does not read the <Format3D></Format3D> tag?

 

It seems to be in the code here:

https://github.com/MediaBrowser/XmlMetadata/blob/master/XmlMetadata/Parsers/BaseItemXmlParser.cs#L676

[Luke 37185]

It seems like it should but it looks like it's not under MediaInfo but just under the main node.

[chjohans 32]

Ah ok, well at least it's easier for me to automate adding that tag to the main node of all my 3D xml's than to manually add it in the metadata manager.

 

But wouldn't it make more sense to expect this under "MediaInfo" since all other media related info is there?

[Luke 37185]

In hindsight probably yes but it's been that way for years now.

[chjohans 32]

Ok thanks, it's a minor problem.

 

Seems like I can continue to use MCM for a while longer by using the XML Reader and make a post-process script for MCM to add/move the Format3D tag for the main xml node.

 

I absolutely cannot use the Nfo reader since my .nfo format is not 100% compatible.

 

I probably just discovered this now because I re-added all my libraries recently, and then all my .nfo's were read again, triggering the "duplicate id" issue. Most of my library were imported into Emby when you still had Xml Reader built-in to the server. So the "duplicate IDs" problem has just grown since you dropped Xml reader support in the core some time ago, until it exploded when I deleted and re-added all my libraries.

 

Will switch back to the Xml reader, hopefully someone will help to maintain it

Edited March 22, 2018 by chjohans

[chjohans 32]

@@Luke - I do have a question related to this

 

I removed an added back my libraries to read them with the XML plugin which is set to have priority above the Nfo reader. I don't have "Save artwork and metadata into media folders" because I don't want Emby to save anything in my media folders. In fact I don't want it to ever write anything there, so the Emby server only has read access to my media libraries.

 

When the server is adding back my libraries I notice that there is a lot of error messages similar to this one (one per .nfo so it's A LOT of them):

 

2018-03-22 13:06:26.035 Error ProviderManager: Error in metadata saver

*** Error Report ***

Version: 3.3.1.0

Command line: C:\Users\media\AppData\Roaming\Emby-Server\System\EmbyServer.dll C:\Users\media\AppData\Roaming\Emby-Server\System\MediaBrowser.ServerApplication.exe -service

Operating system: Microsoft Windows NT 6.2.9200.0

64-Bit OS: True

64-Bit Process: True

User Interactive: True

Processor count: 4

Program data path: C:\Users\media\AppData\Roaming\Emby-Server

Application directory: C:\Users\media\AppData\Roaming\Emby-Server\System

System.UnauthorizedAccessException: Access to the path '\\CUBESTATION-01\video\Movies (3D)\Jurassic Park (1993) [HSBS]\Jurassic Park (1993) [HSBS].nfo' is denied.

   at System.IO.FileStream.OpenHandle(FileMode mode, FileShare share, FileOptions options)

   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)

   at Emby.Server.Implementations.IO.ManagedFileSystem.GetFileStream(String path, FileOpenMode mode, FileAccessMode access, FileShareMode share, FileOpenOptions fileOpenOptions)

   at MediaBrowser.XbmcMetadata.Savers.BaseNfoSaver.SaveToFile(Stream stream, String path)

   at MediaBrowser.XbmcMetadata.Savers.BaseNfoSaver.Save(BaseItem item, CancellationToken cancellationToken)

   at MediaBrowser.Providers.Manager.ProviderManager.SaveMetadata(BaseItem item, ItemUpdateType updateType, IEnumerable`1 savers)

System.UnauthorizedAccessException

   at System.IO.FileStream.OpenHandle(FileMode mode, FileShare share, FileOptions options)

   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)

   at Emby.Server.Implementations.IO.ManagedFileSystem.GetFileStream(String path, FileOpenMode mode, FileAccessMode access, FileShareMode share, FileOpenOptions fileOpenOptions)

   at MediaBrowser.XbmcMetadata.Savers.BaseNfoSaver.SaveToFile(Stream stream, String path)

   at MediaBrowser.XbmcMetadata.Savers.BaseNfoSaver.Save(BaseItem item, CancellationToken cancellationToken)

   at MediaBrowser.Providers.Manager.ProviderManager.SaveMetadata(BaseItem item, ItemUpdateType updateType, IEnumerable`1 savers)

 

Why is Emby trying to open my .nfo's in write mode even when the settings is not to save anything to my media folders?

 

And since the Xml Reader now has priority, why does it try to open my .nfo's at all?

[Luke 37185]

Double check. You must have nfo saving enabled.

[chjohans 32]

What setting is that?

 

I do have the Nfo "Metadata saver" enabled as it's enabled by default, but I assumed that since I don't have "Save artwork and metadata into media folders" then Emby would not write to my media folders.

 

I have not noticed these error messages in my log before today.

[chjohans 32]

@@Luke - will the "Nfo saver" try to write to .nfo's in my media folders even if "Save artwork and metadata into media folders" is not checked?

 

If so it's not logical to me, but it would explain what I see.

[Luke 37185]

No, it wouldn't.

[chjohans 32]

Ok. I've checked and double checked my settings, and "Save artwork and metadata into media folders" is disabled for all my libraries. But yet Emby is trying to write .nfo's in my media folders. Less frequent right now, but once per media folder when I added back my libraries.

 

It logged about 88MB text with the kind of error messages as in my first post, let me know if you want the full log as it's too big to upload here.

[Luke 37185]

it is a per library setting so make sure to check that for each library.

[chjohans 32]

it is a per library setting so make sure to check that for each library.

 

Yes I know, and yes I checked per library. Guaranteed, it's off for all libraries but still trying to write .nfo's in all my media folders.

 

Speaking of settings and support. I suggest you implement something like a "support" button that copies essential server settings to a file and/or to the clipboard. That way it could be included with error reports, and it would be easier for devs like yourself to determine if it's really a bug or just some setting thing.

[chjohans 32]

Emby is still trying to write to my .nfo's, the number of times it tries is somewhere in the hundreds each day.

@@Luke - You asked me to check the settings, I did and they none of my libraries settings allows writing to my media folders. But yet Emby tries to do that.

 

How can I get this to stop?

[Luke 37185]

How are you certain that emby is writing to your nfos?

[chjohans 32]

I am 100% certain that it does not, since it does not have write access to my library. But it's logging hundreds of attempts every day, please see my post #15 (https://emby.media/community/index.php?/topic/57206-emby-xml-plugin-does-not-recognize-3d-tags-nfo-reader-duplicates-id/?p=559145) for the actual error message. I have hundreds more, every day, if you need more examples.