Problem with persons files in metadata folder

[maximilianh75 19]

I experimenting certain problems adding actors

Only the photo save in people folder, the xml file of metadata not saved, If i lost my db file or get corrupted how reconstruct de actor data without xml???

[Luke 37215]

Hi there, I'm sorry I really don't understand what you're trying to communicate.

 

Can you please describe in more detail and include some examples? Thanks !

[maximilianh75 19]

The Actor data not saved in xml or nfo file in METADATA folder

When actor is added to DB the photograph of an actor is add to meta data key folder

Example : 

 

E:\metadata\People\A\Amber Jayne

 

When I save data only photograph save in the folder, the xml with metadata I manually added not been saved, Before a xml file was saved in correct actor folder.

What ever if the db file store al metadata get corrupted How I reconstruct the people metadata

Folder only save PHOTO, PERSON.xml not saved anymore

Edited December 31, 2016 by maximilianh75

[maximilianh75 19]

The Actor data not saved in xml or nfo file in METADATA folder

When actor is added to DB the photograph of an actor is add to meta data key folder

Example : 

 

E:\metadata\People\A\Amber Jayne

 

When I save data only photograph save in the folder, the xml with metadata I manually added not been saved, Before a xml file was saved in correct actor folder.

What ever if the db file store al metadata get corrupted How I reconstruct the people metadata

Folder only save PHOTO, PERSON.xml not saved anymore

And not save xml file with metadata of person like in image down here

[maximilianh75 19]

Hi there, I'm sorry I really don't understand what you're trying to communicate.

 

Can you please describe in more detail and include some examples? Thanks !

I Put more info that you asking for.

Please say my if you undertstand the problem??

[Happy2Play 8351]

You will need to post a server log.  Haven't noticed any issues with people and there metadata being saved to custom path,

[Luke 37215]

Ok, now I understand. Thank you for clarifying. Is there an issue within Emby or are you just monitoring the folders?

[maximilianh75 19]

My fear is if i have a trouble with the DB File who contain the data of the persons I have no way to reconstruct it. In a example I do a clean install and re generate all the DB, if the data not exist in the movie db org I'm in troubles

Inclusive if I add some movies to the movie db some items appear only in emby like Tags for persons.

This files appear in some older versions of emby and saved like XML file extension. But emby not use anymore that kind o file, maybe this is the reason or maybe it's an issue.

When I could I upload the log

 

Thanks for your time

[maximilianh75 19]

Ok, now I understand. Thank you for clarifying. Is there an issue within Emby or are you just monitoring the folders?

I just monitoring the folder because i add tags for persons (ACTORS) and other things like synopsis

 

This Tags must be save in xml or nfo file to be restored if i re install what ever happend to emby if I can't backup de library.db or this one it's broken. For other sideThe movie DB not acept tags

or some items that you offer in metadata editor for persons that can't be reconstructed by id number 

 

This is only an example of something could happend if the db file not working anymore.

The same thing for custom collections, there is no way to reconstruct them, the only way is backup de LIBRARY.DB. But if you decide to make a big change and db file turns obsolete i'm screw

 

My question is it;s an emby limitation or a bug or you decide not save anymore this xml files in persons????

 

P.S: Another thing I note is the folder structure it's now the same of a movie open an extrafanart folder for background image of actors. I never notice this feature

Edited December 31, 2016 by maximilianh75

[maximilianh75 19]

You will need to post a server log.  Haven't noticed any issues with people and there metadata being saved to custom path,

I never use custom path, I use network path until 2014 that fit perfect with SMB that use in kodi. 

Ex:\\SERVERNAME\E

I'm not detected an issue because the persons data are writed correctly to DB file and work fine

[Luke 37215]

You should find a new way of doing this because people metadata is on demand now, when it's needed. We no longer do it in advance as it just causes the people refresh to take hours and hours.

[maximilianh75 19]

You should find a new way of doing this because people metadata is on demand now, when it's needed. We no longer do it in advance as it just causes the people refresh to take hours and hours.

Ok the only way is adding the data to TMDB

Thanks a Lot 

Good End of 2016

Better 2017!!!

Edited December 31, 2016 by maximilianh75

[Luke 37215]

Happy new year

[Kensey 0]

You should find a new way of doing this because people metadata is on demand now, when it's needed. We no longer do it in advance as it just causes the people refresh to take hours and hours.

Are you saying that the person.xml files are no longer used?

[Happy2Play 8351]

No, just that Emby does not blanket download all the information.  Emby will gradually get the information while browsing via the client.

[Kensey 0]

OK... but going back to part of the OP's 2nd post... If I manually edit a person and hit save, no xml file is created/modified.

 

Or, if I create the person.xml file and do a refresh of that person, it doesn't read from the data from the file.

[Happy2Play 8351]

It is system related.  OP needs to verify that Emby is actually pointed to the custom path shown "E:\metadata\People".  Look at the Dashboard-use the drop down arrow for "Paths".  Since no logs were posted there is no way for us to know if the configuration is correct.

[Kensey 0]

OK... I probably should have been more explicit, in that I too am having the issue.

 

Having just double checked, the path is certainly correct (though if it was wrong I assume images would also not be working).

 

Here is a log snippet of loading & saving a person...

2017-01-01 20:03:59.1751 Info HttpServer: HTTP Response 200 to ::1. Time: 191ms. http://localhost:8096/emby/Search/Hints?userId=af0fd08a1929b7e93332cf1c6648d869&searchTerm=angelson&limit=30
2017-01-01 20:03:59.1991 Info HttpServer: HTTP GET http://localhost:8096/emby/Items/ee8f46a1469b855bd4be3bf32433457f/Images/Primary?maxHeight=342&maxWidth=228&tag=deae8ba5fd98e038f6962d391e4c82fd&quality=90. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:03:59.3051 Info HttpServer: HTTP Response 200 to ::1. Time: 106ms. http://localhost:8096/emby/Items/ee8f46a1469b855bd4be3bf32433457f/Images/Primary?maxHeight=342&maxWidth=228&tag=deae8ba5fd98e038f6962d391e4c82fd&quality=90
2017-01-01 20:04:01.2406 Info HttpServer: HTTP GET http://localhost:8096/emby/Users/af0fd08a1929b7e93332cf1c6648d869/Items/ee8f46a1469b855bd4be3bf32433457f. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:04:01.4226 Info HttpServer: HTTP Response 200 to ::1. Time: 182ms. http://localhost:8096/emby/Users/af0fd08a1929b7e93332cf1c6648d869/Items/ee8f46a1469b855bd4be3bf32433457f
2017-01-01 20:04:01.4326 Info HttpServer: HTTP GET http://localhost:8096/emby/Items/ee8f46a1469b855bd4be3bf32433457f/Images/Primary?maxHeight=360&tag=deae8ba5fd98e038f6962d391e4c82fd&quality=90. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:04:01.4476 Info HttpServer: HTTP GET http://localhost:8096/emby/Users/af0fd08a1929b7e93332cf1c6648d869/Items?SortBy=SortName&SortOrder=Ascending&IncludeItemTypes=Series&Recursive=true&Fields=AudioInfo%2CSeriesInfo%2CParentId%2CPrimaryImageAspectRatio%2CBasicSyncInfo%2CAudioInfo%2CSeriesInfo%2CParentId%2CPrimaryImageAspectRatio%2CBasicSyncInfo&Limit=10&StartIndex=0&CollapseBoxSetItems=false&PersonIds=ee8f46a1469b855bd4be3bf32433457f. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:04:01.4596 Info HttpServer: HTTP GET http://localhost:8096/emby/Items/ee8f46a1469b855bd4be3bf32433457f/ThemeMedia?userId=af0fd08a1929b7e93332cf1c6648d869&InheritFromParent=true. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:04:01.4596 Info HttpServer: HTTP Response 200 to ::1. Time: 9ms. http://localhost:8096/emby/Items/ee8f46a1469b855bd4be3bf32433457f/ThemeMedia?userId=af0fd08a1929b7e93332cf1c6648d869&InheritFromParent=true
2017-01-01 20:04:01.4596 Info HttpServer: HTTP Response 200 to ::1. Time: 23ms. http://localhost:8096/emby/Users/af0fd08a1929b7e93332cf1c6648d869/Items?SortBy=SortName&SortOrder=Ascending&IncludeItemTypes=Series&Recursive=true&Fields=AudioInfo%2CSeriesInfo%2CParentId%2CPrimaryImageAspectRatio%2CBasicSyncInfo%2CAudioInfo%2CSeriesInfo%2CParentId%2CPrimaryImageAspectRatio%2CBasicSyncInfo&Limit=10&StartIndex=0&CollapseBoxSetItems=false&PersonIds=ee8f46a1469b855bd4be3bf32433457f
2017-01-01 20:04:01.4996 Info HttpServer: HTTP GET http://localhost:8096/emby/Items/1cfe60f379449a19689fc4105b01685d/Images/Primary?maxHeight=342&maxWidth=228&tag=a3249be4f9e0cd3466f945b1599cb54c&quality=90. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:04:01.5336 Info HttpServer: HTTP Response 200 to ::1. Time: 102ms. http://localhost:8096/emby/Items/ee8f46a1469b855bd4be3bf32433457f/Images/Primary?maxHeight=360&tag=deae8ba5fd98e038f6962d391e4c82fd&quality=90
2017-01-01 20:04:01.6046 Info HttpServer: HTTP Response 200 to ::1. Time: 106ms. http://localhost:8096/emby/Items/1cfe60f379449a19689fc4105b01685d/Images/Primary?maxHeight=342&maxWidth=228&tag=a3249be4f9e0cd3466f945b1599cb54c&quality=90
2017-01-01 20:04:11.5662 Info HttpServer: HTTP GET http://localhost:8096/emby/Users/af0fd08a1929b7e93332cf1c6648d869/Items/ee8f46a1469b855bd4be3bf32433457f. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:04:11.5662 Info HttpServer: HTTP GET http://localhost:8096/emby/Items/ee8f46a1469b855bd4be3bf32433457f/MetadataEditor. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:04:11.7502 Info HttpServer: HTTP Response 200 to ::1. Time: 184ms. http://localhost:8096/emby/Users/af0fd08a1929b7e93332cf1c6648d869/Items/ee8f46a1469b855bd4be3bf32433457f
2017-01-01 20:04:11.7502 Info HttpServer: HTTP Response 200 to ::1. Time: 188ms. http://localhost:8096/emby/Items/ee8f46a1469b855bd4be3bf32433457f/MetadataEditor
2017-01-01 20:04:15.8123 Debug Dlna: Search Request Received From 10.0.0.86:50159, Target = ssdp:all
2017-01-01 20:04:15.8123 Debug Dlna: Search Request Received From 10.0.0.86:50160, Target = ssdp:all
2017-01-01 20:04:15.9215 Debug Dlna: Search Request Received From 10.0.0.86:50159, Target = ssdp:all
2017-01-01 20:04:15.9215 Debug Dlna: Search Request Received From 10.0.0.86:50160, Target = ssdp:all
2017-01-01 20:04:16.0307 Debug Dlna: Search Request Received From 10.0.0.86:50159, Target = ssdp:all
2017-01-01 20:04:16.0307 Debug Dlna: Search Request Received From 10.0.0.86:50160, Target = ssdp:all
2017-01-01 20:04:17.8401 Info HttpServer: HTTP POST http://localhost:8096/emby/Items/ee8f46a1469b855bd4be3bf32433457f. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:04:17.8401 Debug App: Saving C:\Users\Admin\AppData\Roaming\MediaBrowser-Server\metadata\People\G\Genevieve Angelson to database.
2017-01-01 20:04:18.4241 Debug ProviderManager: Saving D:\Television\Good Girls Revolt to Nfo.
2017-01-01 20:04:18.4591 Debug LibraryMonitor: Changed detected of type Changed to D:\Television\Good Girls Revolt\tvshow.nfo
2017-01-01 20:04:18.4591 Debug LibraryMonitor: Ignoring change to D:\Television\Good Girls Revolt\tvshow.nfo
2017-01-01 20:04:18.4591 Debug LibraryMonitor: Changed detected of type Changed to D:\Television\Good Girls Revolt\tvshow.nfo
2017-01-01 20:04:18.4591 Debug LibraryMonitor: Ignoring change to D:\Television\Good Girls Revolt\tvshow.nfo
2017-01-01 20:04:18.4591 Debug LibraryMonitor: Changed detected of type Changed to D:\Television\Good Girls Revolt\tvshow.nfo
2017-01-01 20:04:18.4591 Debug LibraryMonitor: Ignoring change to D:\Television\Good Girls Revolt\tvshow.nfo
2017-01-01 20:04:18.4591 Debug LibraryMonitor: Changed detected of type Changed to D:\Television\Good Girls Revolt\tvshow.nfo
2017-01-01 20:04:18.4591 Debug LibraryMonitor: Ignoring change to D:\Television\Good Girls Revolt\tvshow.nfo
2017-01-01 20:04:18.4681 Info HttpServer: HTTP Response 204 to ::1. Time: 628ms. http://localhost:8096/emby/Items/ee8f46a1469b855bd4be3bf32433457f
2017-01-01 20:04:18.6021 Info HttpServer: HTTP GET http://localhost:8096/emby/Users/af0fd08a1929b7e93332cf1c6648d869/Items/ee8f46a1469b855bd4be3bf32433457f. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:04:18.7661 Info HttpServer: HTTP Response 200 to ::1. Time: 164ms. http://localhost:8096/emby/Users/af0fd08a1929b7e93332cf1c6648d869/Items/ee8f46a1469b855bd4be3bf32433457f
2017-01-01 20:04:18.7781 Info HttpServer: HTTP GET http://localhost:8096/emby/Users/af0fd08a1929b7e93332cf1c6648d869/Items?SortBy=SortName&SortOrder=Ascending&IncludeItemTypes=Series&Recursive=true&Fields=AudioInfo%2CSeriesInfo%2CParentId%2CPrimaryImageAspectRatio%2CBasicSyncInfo%2CAudioInfo%2CSeriesInfo%2CParentId%2CPrimaryImageAspectRatio%2CBasicSyncInfo&Limit=10&StartIndex=0&CollapseBoxSetItems=false&PersonIds=ee8f46a1469b855bd4be3bf32433457f. UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 OPR/42.0.2393.94
2017-01-01 20:04:18.7961 Info HttpServer: HTTP Response 200 to ::1. Time: 18ms. http://localhost:8096/emby/Users/af0fd08a1929b7e93332cf1c6648d869/Items?SortBy=SortName&SortOrder=Ascending&IncludeItemTypes=Series&Recursive=true&Fields=AudioInfo%2CSeriesInfo%2CParentId%2CPrimaryImageAspectRatio%2CBasicSyncInfo%2CAudioInfo%2CSeriesInfo%2CParentId%2CPrimaryImageAspectRatio%2CBasicSyncInfo&Limit=10&StartIndex=0&CollapseBoxSetItems=false&PersonIds=ee8f46a1469b855bd4be3bf32433457f
2017-01-01 20:04:31.7610 Debug NetworkManager: Querying interface: Wireless Network Connection. Type: Wireless80211. Status: Up
2017-01-01 20:04:31.7610 Debug NetworkManager: Querying interface: VirtualBox Host-Only Network. Type: Ethernet. Status: Up
2017-01-01 20:04:31.7610 Debug NetworkManager: Querying interface: Loopback Pseudo-Interface 1. Type: Loopback. Status: Up

[Happy2Play 8351]

Okay, I see what you are saying.  Had to do some digging on my test server to see this.  @@Luke is people metadata all database driven now, making all people.xml's obsolete?  As there are no reader/writer options and making changes to a person via Edit Info doesn't save to existing people.xml metadata.
 
 

Edited January 1, 2017 by Happy2Play

[Abobader 2956]

Good day,

 

I can confirm that for the delay of creating the xml files for actors.

 

My best

[Luke 37215]

This is correct. person.xml is not being used.  being able to avoid reading and writing tens of thousands of xml files is one of the things that is allowing the people refresh task to be much faster than ever before.

[pünktchen 1261]

But then we need a way to export those people meta data otherwise after a server crash the whole download/editing thing starts all over again.

[Luke 37215]

Actually it doesn't because we download people metadata on demand when you click on a person and open the person detail screen. Not everytime, but depending on how old the data in the database is. Therefore, you don't really need to backup anything.

[pünktchen 1261]

Of course one needs a backup. Simpliest reason is, when people are misidentified.

[Luke 37215]

That seems like it would be unrelated.