NFO files not getting created on scan in home video library

[Luke 42078]

Well nobody said the entire nfo is not being read. His comment is only about watch state.

[K22R8CT 25]

Got it, thanks.

Then only one more question because it's hard to test myself:

Is "date added" reset when media with a different extension replaces the original because I use NFOs or would it happen regardless?

[Luke 42078]

18 hours ago, Anon28109 said:

Got it, thanks.

Then only one more question because it's hard to test myself:

Is "date added" reset when media with a different extension replaces the original because I use NFOs or would it happen regardless?

It would happen regardless because it's a new file, unless there is an nfo file containing the value.

[NortherNerd 3]

I think this is the right place to post this.  I'm getting ready to move to a new NAS.  I want to port my Emby database as best I can.  I've already installed the backup plugin.  From previous forum questions, I notice that the prompt "Save artwork into media folders" is NOT checked.  So I think that means that the artwork and other metadata is store in an Emby database.

I have a few questions:

1. Is there a way to now force Emby to take the metadata stored in it's database and write it to the media folders?
2. Assuming the answer to #1 is no, can I move the metadata database from the old NAS to the new one?  I had a look at the /varpackages/EmbyServer/var/metadata directory, and I'm worried that the coding is such that on a new NAS, the databse would be out of sync with the new storage location for the media.
3. Any advice on the best way to move to a new NAS and keep as much of my Emby setup in tact as possible?

Thanks,

[ebr 16177]

Hi.  If you wait until 4.8 releases to do this (hopefully very soon) then I think you will be able to do this move as painlessly as possible.

You would fully upgrade to 4.8 then take a new backup and then restore that on the new machine and you should be good to go.

[CasaAtardecer 27]

I wish I had the problem of funny business goings on with Emby writing nfos. My installation will read them without difficulty, but will not create/write/update an nfo stored with the media. Yes, all the toggles are perfectly set and manual refresh of whole library doesn’t force the nfo to appear or update. Tried every scenario combination: Still no love.

[K22R8CT 25]

10 hours ago, CasaAtardecer said:

but will not create/write/update an nfo stored with the media

Reads but can't write sounds like a permission issue -

Although if it won't *create* them but it will create other files (bif's, etc.) then it's probably something else.

[Luke 42078]

22 hours ago, CasaAtardecer said:

I wish I had the problem of funny business goings on with Emby writing nfos. My installation will read them without difficulty, but will not create/write/update an nfo stored with the media. Yes, all the toggles are perfectly set and manual refresh of whole library doesn’t force the nfo to appear or update. Tried every scenario combination: Still no love.

Hi @CasaAtardecer the previous user is most likely right . The server could be trying to create nfo files, but is being denied write access. We'd have to look at a specific example:

How to Report a Problem

Thanks.

[CasaAtardecer 27]

Thank you for the speculations regarding server write permissions. Checked them and they look correct for the app read AND write permissions. Here's the error log, which seems to point to a local port not being set, but that doesn't seem to be true either. The NFO absolutely exists locally because Emby can read it without any difficulty, but just refuses to write to it. Any troubleshooting ideas you can offer please?

"2025-01-10 09:41:59.340 Error ProviderManager: Error in metadata saver
    *** Error Report ***
    Version: 4.9.0.34
    Command line: /volume1/@appstore/EmbyServer/system/EmbyServer.dll -programdata /var/packages/EmbyServer/var -ffdetect /var/packages/EmbyServer/target/bin/ffdetect -ffmpeg /var/packages/EmbyServer/target/bin/ffmpeg -ffprobe /var/packages/EmbyServer/target/bin/ffprobe -nolocalportconfig -ignore_vaapi_enabled_flag -pidfile /var/packages/EmbyServer/var/EmbyServer.pid -defaultdirectory /volume1/Public -updatepackage emby-server-synology72_{version}_x86_64.spk
    Operating system: Linux version 4.4.302+ (root@build5) (gcc version 12.2.0 (GCC) ) #72806 SMP Thu Sep 5 13:44:44 CST 2024
    OS/Process: x64/x64
    Framework: .NET 8.0.10
    Runtime: volume1/@appstore/EmbyServer/system/System.Private.CoreLib.dll
    Processor count: 4
    Data path: /var/packages/EmbyServer/var
    Application path: /volume1/@appstore/EmbyServer/system
    System.IO.IOException: System.IO.IOException: Create Handle Failed: Photos\PhotoLibrary\1992\1992 03 05. NTStatus: FILE_DOES_NOT_EXIST
       at EzSmb.Transports.Shares.Handlers.Bases.HandlerBase..ctor(SmbType smbType, ISMBFileStore store, String path, HandleType handleType, NodeType nodeType, HandleArgs args)
       at EzSmb.Transports.Shares.Bases.ShareBase.CreateFolder(Node node, String folderName)
       at EzSmb.Node.CreateFolder(String folderName, String relatedPath)
       at Emby.Server.Implementations.IO.SmbFileSystem.CreateDirectory(String path)
       at NfoMetadata.Savers.BaseNfoSaver.SaveToFile(Stream stream, String path, LibraryOptions libraryOptions, CancellationToken cancellationToken)
       at NfoMetadata.Savers.BaseNfoSaver.Save(BaseItem item, LibraryOptions libraryOptions, CancellationToken cancellationToken)
       at Emby.Providers.Manager.ProviderManager.SaveMetadata(BaseItem item, LibraryOptions libraryOptions, ItemUpdateType updateType, IMetadataSaver[] savers, CancellationToken cancellationToken)
    Source: Emby.Server.Implementations
    TargetSite: Void .ctor(EzSmb.Params.Enums.SmbType, SMBLibrary.Client.ISMBFileStore, System.String, EzSmb.Transports.Shares.Handlers.Enums.HandleType, EzSmb.NodeType, EzSmb.Transports.Shares.Handlers.HandleArgs)"

[Luke 42078]

Hi, what exactly did you check?

[CasaAtardecer 27]

Hello. The Synology NAS user accounts all have read/write permissions enabled. The Emby profile user account settings allow NFOs for media (these settings don't appear to differentiate between read and write, or isolate the read permission from the write permission). I'm not aware of any other server level user permissions that are blocking Emby's attempt to write to it. The error log references local ip and port settings, which I've also checked to ensure they are toggled/filled correctly. It makes no difference whether I use the mobile UI, the browser UI or the local UI, edits to the media local stored NFOs don't update. I guess I should also mention that the LOCKFROMEDITING toggle is OFF. Does that answer the question? Thanks.   

[CasaAtardecer 27]

Hello. Hope you are well. Does an Emby installation require a uniquely created/named/allowed/etc. user account to work with Synology NAS (DS920+) or is the UI relying solely upon the user credentials to gain access to my selected library folder paths? If the latter is the case, are there Emby-specific settings that need to be created/added/edited/etc. to the user account whose login credentials are gaining access to my selected library folder paths? I have searched the community forums and internet for Synology-specific Emby installation guidelines and have not been successful in learning anything that is helpful. Thanks.

[CasaAtardecer 27]

On 1/10/2025 at 10:32 AM, Luke said:

Hi, what exactly did you check?

Hi. Thanks for the reply and question. Since the error log appears to be all about trying to access the local path using smb protocol, I ensured this specific protocol, indeed, ALL protocols, are enabled/allowed/RW permitted by the user account whose login credentials are being used by Emby for access to my library path. Rechecked EVERY Synology-based setting for user access permissions and they are correct. Still, Emby won’t create/edit a local media-stored nfo, but reads them without any difficulty. There has got to be a solution. Thank you. The error log is shown in my earlier post.

[Happy2Play 9780]

3 minutes ago, CasaAtardecer said:

Hi. Thanks for the reply and question. Since the error log appears to be all about trying to access the local path using smb protocol, I ensured this specific protocol, indeed, ALL protocols, are enabled/allowed/RW permitted by the user account whose login credentials are being used by Emby for access to my library path. Rechecked EVERY Synology-based setting for user access permissions and they are correct. Still, Emby won’t create/edit a local media-stored nfo, but reads them without any difficulty. There has got to be a solution. Thank you. The error log is shown in my earlier post.

In the end it will be not using smb paths and mounting the paths locally as there are dozens of topics with issues with smb.

 

[CasaAtardecer 27]

1 hour ago, Happy2Play said:

In the end it will be not using smb paths and mounting the paths locally as there are dozens of topics with issues with smb.

 

“In the end, it will not be using SMB paths” what does that mean? Smb is the protocol stated in front of all the IP addresses used for accessing library paths, and also stated in the error logs. I’m confused.

[Happy2Play 9780]

4 minutes ago, CasaAtardecer said:

“In the end, it will not be using SMB paths” what does that mean? Smb is the protocol stated in front of all the IP addresses used for accessing library paths, and also stated in the error logs. I’m confused.

It means the Emby is choking on the path you are using.

System.IO.IOException: Create Handle Failed: Photos\PhotoLibrary\1992\1992 03 05. NTStatus: FILE_DOES_NOT_EXIST

 

Edited January 14, 2025 by Happy2Play

[CasaAtardecer 27]

2 hours ago, Happy2Play said:

It means the Emby is choking on the path you are using.

System.IO.IOException: Create Handle Failed: Photos\PhotoLibrary\1992\1992 03 05. NTStatus: FILE_DOES_NOT_EXIST

 

Hello. Thanks for the insight and recommendation. Let us suppose that my selected library path is accessible via Emby's mobile UI, Roku's Emby app UI, and Emby's browser UI without difficulty: No issues reading locally stored video file NFOs. No issues reading embedded photo file metadata. Presumably all this carefree READING access is courtesy of smb protocol, since it is listed everywhere. How again is Emby "choking" on it? If the selected library path shouldn't be smb-based, what should it be? Thanks.

[Luke 42078]

HI, please attach the complete emby server log file. thanks.