emby just nuked all my metadata for a Library

[blim5001 8]

I come back every so often to try Emby again, but sadly I am disappointed.

Emby's scanning behaviour seems (to be polite) somewhat odd.

I have just spent the last day and half scanning a library and I am now currently just watching the log files as it deletes 1000's of metadata entries as it is destroying the library I have just added.

No I did not delete the library, I simply added an additional folder to it.

At the moment I am waiting to see what happens when it finally gets to the end of deleting all the entries.

So my question... is this expected or has something gone wrong somewhere.

I would have thought that adding a new folder should not cause this.

(Disclaimer: The files are on google drive, but the mount is still working fine)

Edit:
So it finally finished deleting and now it has to started to scan again. This seems bonkers, why should adding an additional folder delete all the existing metadata!

 

 

Edited April 5, 2021 by blim5001

[ebr 16199]

1 hour ago, blim5001 said:

why should adding an additional folder delete all the existing metadata!

Hi.  It won't.  Can you please describe exactly what you did and then also attach the server log here?

Thanks.

 

[blim5001 8]

I was probably doing 2 things at once which was probably not a good idea.

While looking at the log while scanning I noticed my Music library was pointing to the wrong (an old) path,

2021-04-05 14:56:17.535 Error App: Error in GetFilteredFileSystemEntries isPhysicalRoot: False IsVf: False
	*** Error Report ***
	Version: 4.5.4.0
	Command line: /volume1/@appstore/EmbyServer/system/EmbyServer.dll -programdata /volume1/Emby -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 -updatepackage emby-server-synology_{version}_x86_64.spk
	Operating system: Linux version 3.10.105 (root@build3) (gcc version 4.9.3 20150311 (prerelease) (crosstool-NG 1.20.0) ) #25426 SMP Mon Dec 14 18:47:29 CST 2020
	Framework: .NET Core 3.1.8
	OS/Process: x64/x64
	Runtime: volume1/@appstore/EmbyServer/system/System.Private.CoreLib.dll
	Processor count: 4
	Data path: /volume1/Emby
	Application path: /volume1/@appstore/EmbyServer/system
	System.IO.DirectoryNotFoundException: System.IO.DirectoryNotFoundException: Could not find a part of the path '/volume1/media/_mounts/rclonemountFiles/plex/Music'.
	   at System.IO.Enumeration.FileSystemEnumerator`1.CreateDirectoryHandle(String path, Boolean ignoreNotFound)
	   at System.IO.Enumeration.FileSystemEnumerator`1.Init()
	   at System.IO.Enumeration.FileSystemEnumerable`1..ctor(String directory, FindTransform transform, EnumerationOptions options, Boolean isNormalized)
	   at System.IO.Enumeration.FileSystemEnumerableFactory.FileSystemInfos(String directory, String expression, EnumerationOptions options, Boolean isNormalized)
	   at System.IO.DirectoryInfo.InternalEnumerateInfos(String path, String searchPattern, SearchTarget searchTarget, EnumerationOptions options)
	   at Emby.Server.Implementations.IO.ManagedFileSystem.GetFileSystemEntries(String path, Boolean recursive)
	   at MediaBrowser.Controller.Providers.DirectoryService.GetFileSystemEntries(String path)
	   at MediaBrowser.Controller.IO.FileData.GetFilteredFileSystemEntries(IDirectoryService directoryService, String path, IFileSystem fileSystem, IServerApplicationHost appHost, ILogger logger, ItemResolveArgs args, Int32 flattenFolderDepth, Boolean resolveShortcuts)
	   at Emby.Server.Implementations.Library.LibraryManager.ResolvePath(FileSystemMetadata fileInfo, IDirectoryService directoryService, IItemResolver[] resolvers, Folder parent, LibraryOptions libraryOptions)
	Source: System.IO.FileSystem
	TargetSite: IntPtr CreateDirectoryHandle(System.String, Boolean)
2021-04-05 14:56:17.535 Error App: Error in GetFilteredFileSystemEntries isPhysicalRoot: False IsVf: False
	*** Error Report ***
	Version: 4.5.4.0
	Command line: /volume1/@appstore/EmbyServer/system/EmbyServer.dll -programdata /volume1/Emby -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 -updatepackage emby-server-synology_{version}_x86_64.spk
	Operating system: Linux version 3.10.105 (root@build3) (gcc version 4.9.3 20150311 (prerelease) (crosstool-NG 1.20.0) ) #25426 SMP Mon Dec 14 18:47:29 CST 2020
	Framework: .NET Core 3.1.8
	OS/Process: x64/x64
	Runtime: volume1/@appstore/EmbyServer/system/System.Private.CoreLib.dll
	Processor count: 4
	Data path: /volume1/Emby
	Application path: /volume1/@appstore/EmbyServer/system
	System.IO.DirectoryNotFoundException: System.IO.DirectoryNotFoundException: Could not find a part of the path '/volume1/media/_mounts/rclonemountFiles/plex/Music'.
	   at System.IO.Enumeration.FileSystemEnumerator`1.CreateDirectoryHandle(String path, Boolean ignoreNotFound)
	   at System.IO.Enumeration.FileSystemEnumerator`1.Init()
	   at System.IO.Enumeration.FileSystemEnumerable`1..ctor(String directory, FindTransform transform, EnumerationOptions options, Boolean isNormalized)
	   at System.IO.Enumeration.FileSystemEnumerableFactory.FileSystemInfos(String directory, String expression, EnumerationOptions options, Boolean isNormalized)
	   at System.IO.DirectoryInfo.InternalEnumerateInfos(String path, String searchPattern, SearchTarget searchTarget, EnumerationOptions options)
	   at Emby.Server.Implementations.IO.ManagedFileSystem.GetFileSystemEntries(String path, Boolean recursive)
	   at MediaBrowser.Controller.Providers.DirectoryService.GetFileSystemEntries(String path)
	   at MediaBrowser.Controller.IO.FileData.GetFilteredFileSystemEntries(IDirectoryService directoryService, String path, IFileSystem fileSystem, IServerApplicationHost appHost, ILogger logger, ItemResolveArgs args, Int32 flattenFolderDepth, Boolean resolveShortcuts)
	   at Emby.Server.Implementations.Library.LibraryManager.ResolvePath(FileSystemMetadata fileInfo, IDirectoryService directoryService, IItemResolver[] resolvers, Folder parent, LibraryOptions libraryOptions)
	Source: System.IO.FileSystem
	TargetSite: IntPtr CreateDirectoryHandle(System.String, Boolean)
2021-04-05 14:56:18.492 Debug BaseItem: Removed item: /volume1/media/gDriveMedia/Clips/folder5
2021-04-05 14:56:18.493 Info App: Removing item from database, Type: Folder, Name: folder5, Path: /volume1/media/gDriveMedia/Clips/folder5, Id: 484481
2021-04-05 14:56:18.904 Info App: Deleting path /volume1/Emby/metadata/library/d7/d753c1ce0b7c2e9fbefb0013aa1bb197
2021-04-05 14:56:18.905 Info App: Deleting path /volume1/Emby/metadata/library/36/360760fc632fcf91f6550ab2cd0dbcee
2021-04-05 14:56:18.905 Info App: Deleting path /volume1/Emby/metadata/library/f6/f62153b384173ffce873006fd0f69549
2021-04-05 14:56:18.905 Info App: Deleting path /volume1/Emby/metadata/library/91/91753b435c4375651dc3f16181e2d1cc
...
...

so I deleted that as well.

It was just after that error that the deletions started.

But if this is something that should not happen, then that's good.

I would rather not post the logs for that library, but will create a test library and investigate with that to see if I can replicate the issue.

 

[Luke 42086]

That would be great, thanks !

[Carlo 4561]

Emby was most likely removing all the files pointing to the old path that don't exist anymore.

Once you correct the path it will add those media items back.

[blim5001 8]

That was my original thought, but as all the freshly scanned metadata disappeared before my eyes this was sadly not the case.

I think I had/have messed up the database.

My data locations for my libraries had got quite messy over time after various mount changes, there were symlinks all over the place, So thought I would try and get it all organised

I was trying to avoid a complete rescan, so I used a post here about changing paths in the database.

Not sure if that is a bit out of date or does not consider if you have multiple folders for a library, as I did find some references to the mounts in the data column of one of the tables, which was not mentioned in the post.

I know, I should have searched the database more thoroughly.

But after initially changing the paths it all appeared to be work, all the media would play and showed the correct location, it was only when I started scanning, it all started going a bit wrong.

[Carlo 4561]

If you still have the server logs post it or PM it to me and we would be happy to take a look and let you know what we see.
You could try taking a look at them yourself as finding deleted items is pretty easy.

[blim5001 8]

Thanks, I think I am good now.

I think it might have been an issue with the root paths in the json in the data column of the DB table.

Those were still pointing to the old locations.

I have run a few full scans and it all appears ok again now

[Carlo 4561]

If you notice anything wacky moving forward, send me a PM and I can remote in and give you a hand.

But it sounds like you have things under control now so congrats!