Emby keeps trying to write to my .nfo's when it should not!

[chjohans 32]

This is an "offspring" from my post here: https://emby.media/community/index.php?/topic/57206-emby-xml-plugin-does-not-recognize-3d-tags-nfo-reader-duplicates-id/

 

A couple of weeks ago I removed an added back my libraries to read them with the XML plugin which is set to have priority above the Nfo reader, t osolve a problem with the Nfo Reader and compatibility with my .nfo files.

 

I DO NOT "Save artwork and metadata into media folders" because I don't want Emby to save anything in my media folders. I have checked and double checked and triple checked this upon Luke's request. This setting is OFF for all my libraries.

 

In fact I don't want it to ever write anything in my library folders, so the Emby server only has read access to my media libraries.

 

When the server is scanning 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 - you were saying in the other thread that I must have .nfo saving enabled, but I do not, checked and checked again per library, confirmed and guaranteed. I don't know how else to put this to make it clearer.

 

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. And Luke confirmed this in the other thread.

 

This issue is really bothersome as it's totally overwhelming in my log files and they grow to 60-70MB in size every day. I have not counted but the number of .nfo's it's trying to write to every day is more than a thousand, and I suspect it's trying to write to all or nearly all of my .nfo's every day. Every error message logged is similar to the one above.

 

I suspect that most people will not deny Emby write access to their media folders and obviously this issue is visible only if you do. But please do something about this highly unwanted behavior.

 

Let me know if you want a log file, I don't post one with this as it's huge and the error messages is the same as the one in the example above, but obviously it complains about different .nfo's for each error message.

[Luke 37289]

Please try again with the next release of emby server, thanks.

[chjohans 32]

OK thanks Luke, will post back once the new server is released. Unless you ask me to try a beta release I'll just wait for the stable release.

[serpi 73]

Disabling the nfo saver (as it seems, you do not need it) should also solve for problem.

 

At least for me, no nfo is saved/changed.

I have disabled the nfo saver but enabled saving in folder (for auto created thumbs).

 

If it works for you, you do not need to wait for the next release (or play with unstable beta).

 

Ciao, Alfred

[chjohans 32]

Thanks Alfred!

 

But as a courtesy to Luke, since he has been trying so solve this, I will leave it as it is for now and see if the new server fix this. If not I will just disable the Nfo Reader, as you said I don't need it anyhow.

[serpi 73]

If not I will just disable the Nfo Reader, as you said I don't need it anyhow.

 

You have to disable the nfo saver, not the reader, and this for all the media types, you do not want emby to save the nfo files.

 

This, for example, are my settings for movies:

 

As I see, waiting for the next (stable) release of emby should be pretty much longer than just changing some settings ;-)

 

Ciao, Alfred

[chjohans 32]

Yes, thanks, saver of course to prevent saving

 

And you're right, it's a simple setting to change so I'll just disable it right away to get rid of the pollution in my logfiles. I can always enable it back and test that it's not trying to write to my .nfo's when the next server is released

[Happy2Play 8377]

But disabling the saver option only forces any write action directly to the database.

[moviefan 184]

But disabling the saver option only forces any write action directly to the database.

 

Yah.  And then you end up with all of your information saved into Emby's database with no way of backing up or reverting should anything go wrong.

[serpi 73]

Yah.  And then you end up with all of your information saved into Emby's database with no way of backing up or reverting should anything go wrong.

 

Well, there's always the backup plugin 

It already saved me once, when suddenly the ssd in my emby server wasn't accessible anymore (I will never buy an Intel ssd again!).

 

As I understood, chjohans doesn't want write anything in .nfo files, as he already has .xml files?!

 

Ciao, Alfred

[serpi 73]

But disabling the saver option only forces any write action directly to the database.

 

I would think, emby will always write to the database, no matter if you have additionally activated the .nfo saver.

 

Ciao, Alfred

[Happy2Play 8377]

I would think, emby will always write to the database, no matter if you have additionally activated the .nfo saver.

 

Ciao, Alfred

 

Correct but if you have to restore/reinstall your server the database no longer exists and all your customization from that database are gone.

[chjohans 32]

All of this is not a problem for me, I just want Emby to stop writing to my nfo's. My metadata is initially downloaded by MCM (to my media directories), and I have Emby set up not to allow writing to my libraries, and in fact the EMby server does not even have write access. I want it to write everything it want s to save to the database, and there is nothing there that I can't afford to loose in case I have to import my media libraries over again. All my (initial) metadata is still in the media directories and a when added to Emby these will be read.

[moviefan 184]

Well, there's always the backup plugin 

It already saved me once, when suddenly the ssd in my emby server wasn't accessible anymore (I will never buy an Intel ssd again!).

 

Except the backup plugin doesn't save any pictures, or local metadata, or nearly anything within the DB.  

 

It just saves basic config information and watched status.

 

Intel makes great SSDs btw.  Just sayin...

[Canaletto 2]

Error ProviderManager: Error in metadata saver

Hi,

 

I have this same error in some cases on maped read-only disks.

 

No problem on a maped drive SMB3, on the other hand on a cloud drive (MontainDuck or other cloud drive software), I am forced to mount in RW otherwise it is impossible to read the video that launches and stops right away and causes this error in the log.

 

The library will not save any information on this drive. And in principle Emby is not supposed to write anything about resource disks ...

 

lionel

[Luke 37289]

Error ProviderManager: Error in metadata saver

Hi,

 

I have this same error in some cases on maped read-only disks.

 

No problem on a maped drive SMB3, on the other hand on a cloud drive (MontainDuck or other cloud drive software), I am forced to mount in RW otherwise it is impossible to read the video that launches and stops right away and causes this error in the log.

 

The library will not save any information on this drive. And in principle Emby is not supposed to write anything about resource disks ...

 

lionel

 

 

Hi, I'm not quite sure what problem you're trying to report, but if you don't want Emby to write NFO files, then simply disable that feature in library settings. It's actually off by default anyway.

[Canaletto 2]

Hi, I'm not quite sure what problem you're trying to report, but if you don't want Emby to write NFO files, then simply disable that feature in library settings. It's actually off by default anyway.

 

NFO writing is disabled for this library. But if the drive is RO the video does not start. If I pass the drive in RW movie starts.

 

It clearly means that at one point Emby tries to write or tests if he can write.

[Luke 37289]

We'd have to look at an example. Please see how to report a problem. thanks.

[Canaletto 2]

We'd have to look at an example. Please see how to report a problem. thanks.

 

I am aware that this is a special case that is closely related to the MontainDuck disk. I will continue in RW and see if it works properly before raising the problem with the logs.

 

Merci pour votre aide :-)