Auto Box Sets attempts to write NFO file

[CoolDreamZ 1]

Despite having setup the server not to write metadata to NFO files I am seeing errors in the logs that suggest Auto Box Sets is attempting to write collection IDs to the NFO files

[ebr 14947]

The plug-in doesn't write anything to files but, without more information we can't be sure what is going on.

 

Is there an actual problem?  Are you getting files that shouldn't be there?

[CoolDreamZ 1]

I am having a problem (see the post Auto Box Sets removing members of a collection) - here is an example from the log (I have debug switched on so the log is approx 1Gb)

 

2015-12-20 04:01:33.5888 Info Auto Box Sets: Auto Box Sets Adding TmdbCollectionId of 321063 to The Golden Voyage of Sinbad
2015-12-20 04:01:34.2032 Error ProviderManager: Error in metadata saver
        *** Error Report ***
        Version: 3.0.5781.5
        Command line: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -restartpath /usr/lib/emby-server/restart.sh
        Operating system: Unix 3.16.0.55
        Processor count: 4
        64-Bit OS: True
        64-Bit Process: True
        Program data path: /var/lib/emby-server
        Mono: 4.2.1 (Stable 4.2.1.102/6dd2d0d Thu Dec  3 04:04:55 UTC 2015)
        Application Path: /usr/lib/emby-server/bin/MediaBrowser.Server.Mono.exe
        Access to the path "/v2/Films/The Golden Voyage of Sinbad.nfo" is denied.
        System.UnauthorizedAccessException
          at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) <0x7f461f95e060 + 0x005ed> in <filename unknown>:0
          at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize) <0x7f461f95dd20 + 0x0004d> in <filename unknown>:0
          at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare,int)
          at CommonIO.ManagedFileSystem.GetFileStream (System.String path, FileMode mode, FileAccess access, FileShare share, Boolean isAsync) <0x406bfda0 + 0x000bd> in <filename unknown>:0
          at MediaBrowser.XbmcMetadata.Savers.BaseNfoSaver.SaveToFile (System.IO.Stream stream, System.String path) <0x40a40210 + 0x00115> in <filename unknown>:0
          at MediaBrowser.XbmcMetadata.Savers.BaseNfoSaver.Save (IHasMetadata item, CancellationToken cancellationToken) <0x40a31d60 + 0x000ab> in <filename unknown>:0
          at MediaBrowser.Providers.Manager.ProviderManager+<SaveMetadata>c__async3.MoveNext () <0x408380a0 + 0x00e30> in <filename unknown>:0

[ebr 14947]

Looks like there may be some sort of hole in the metadata saver (Luke - I am just calling LibraryManager.UpdateItem with a type of MedataEdit) but two questions:

 

1) Did you manually add that item to your collection?

2) May I please see at least the entire section of the log that contains the Auto Box Sets refresh?

[CoolDreamZ 1]

1) No - it was added by Auto Box Sets

2) I'll have a look, it may still be too large as the box set refresh log entries are interspersed with the library scan entries

 

(also, why is Auto Box Sets attempting to update the item metadata? doesn't the library scanner maintain the tmdb collection id?)

Edited December 20, 2015 by CoolDreamZ

[ebr 14947]

(also, why is Auto Box Sets attempting to update the item metadata? doesn't the library scanner maintain the tmdb collection id?)

 

Because sometimes the tmdb information is either incomplete or not what you want.  So, if you add an item to an existing tmdb collection manually, It will add the tmdb ID to that item so that the next run of the plug-in won't turn around and remove it.

[CoolDreamZ 1]

Ah, that might explain the issue. As per my other post my NFO files are readonly (I want to maintain my metadata in Kodi - a decision I might have to change!). Within a particular collection (e.g Sinbad) some of these NFO files have Kodi collections e.g. <set>The Sinbad Collection</set> and some do not, none of them have tmdbcollection IDs (I mistakenly thought Kodi would store these but it uses the Collection Name instead of the ID). I suspect this is causing the library scanner to get confused with items appearing to be in a set on one iteration and not on the next. Autobox sets fixes the problem after a few manual iterations until the next library scan....

[Luke 37153]

Looks like there may be some sort of hole in the metadata saver (Luke - I am just calling LibraryManager.UpdateItem with a type of MedataEdit) but two questions:

 

1) Did you manually add that item to your collection?

2) May I please see at least the entire section of the log that contains the Auto Box Sets refresh?

 

Try using the next highest designation for UpdateType. Using Edit it's equivalent to editing in the metadata manager. The next highest one i think is metadata download.

 

Of course - this will create another side effect. In the future if that nfo ever changes, we'll re-import and the data that didn't make it into the nfo before will be lost.

[ebr 14947]

Try using the next highest designation for UpdateType. Using Edit it's equivalent to editing in the metadata manager. The next highest one i think is metadata download.

 

Of course - this will create another side effect. In the future if that nfo ever changes, we'll re-import and the data that didn't make it into the nfo before will be lost.

 

But why would doing this cause a metadata saver that is disabled to attempt to fire?

 

It seems Edit is exactly what I want - I am changing one piece of information just as if they did it in the metadata editor.

[Luke 37153]

Despite settings again you use the metadata editor it saves to metadata. That was due to feedback some months back

[CoolDreamZ 1]

I did a little experiment using the built-in metadata editor to update the collection ID and can confirm the behaviour is as follows:

 

1. With a readonly NFO file I get the same error in the log as described in this post, the collection ID is persisted in the emby database and the NFO file is untouched

2. With a writeable NFO file I do not get the error and the NFO file is updated along with the emby database

 

I have disabled "metadata saving to media folders" at the server and emby is not respecting this setting which makes me wonder what the purpose of that setting is ! A secondary issue is that this seems to be causing the problem described elsewhere i.e. items are being removed from collections by Auto Box Sets.

 

I manage my metadata using other tools and I don't want emby changing any of it and so, in addition to the server setting, I also made my media files readonly to ensure that this is the case.

[Luke 37153]

The core Emby server does respect the setting. 

[ebr 14947]

I did a little experiment using the built-in metadata editor to update the collection ID and can confirm the behaviour is as follows:

 

1. With a readonly NFO file I get the same error in the log as described in this post, the collection ID is persisted in the emby database and the NFO file is untouched

2. With a writeable NFO file I do not get the error and the NFO file is updated along with the emby database

 

I have disabled "metadata saving to media folders" at the server and emby is not respecting this setting which makes me wonder what the purpose of that setting is ! A secondary issue is that this seems to be causing the problem described elsewhere i.e. items are being removed from collections by Auto Box Sets.

 

I manage my metadata using other tools and I don't want emby changing any of it and so, in addition to the server setting, I also made my media files readonly to ensure that this is the case.

 

As Luke explained above, this is by design.  If you manually edit the metadata and save it, then we do write to the file so that those changes are not lost on the next refresh.

[CoolDreamZ 1]

IMHO I don't see much point in the server setting if it is only respected by the core emby server, it is very misleading. At the very least I think some text should be added to the UI to make it more obvious that it does not apply to manual (or Autobox Set) metadata edits. You may also want to require NFO files (where present) to be writeable for Autobox sets to function correctly.

[ebr 14947]

This isn't really an Auto Box Sets issue.  As you pointed out above, the editor behaves the exact same way (because the plug-in is using the same method).

 

The issue is that you have told the system NOT to store metadata with your media and not to save it in files but then you do have metadata files with your media.  Our system then has the ability to modify that metadata and it will always give priority to metadata files.

 

Then, when you tell the system to edit your metadata we are in a quandry.  We can either NOT save that data and have it be lost on the next refresh or we can, in this one instance, go ahead and write the edits to the file so that the edits are not lost.

 

There isn't a perfect answer but this is a rare situation and we chose what we felt was the lessor of the evils.

 

Now, as far as the plug-in is concerned, it could take the approach that Luke suggested and use a mode that will not try to write to the file but that is just going to create the same situation - changes will not persist due to your specific configuration.

 

The plug-in description does note (in bold) that it relies on the internal metadata functions of the server.