Local Actor (Cast) Photos method for emby 4.8.0+

[gbcox 13]

Hi, I tripped upon this posting and I'm completely confused:

https://emby.media/community/index.php?/topic/63331-how-to-backup-people-images-with-beta-going-onwards/

Currently, for local actor (cast) photos, I simply put the actor/role information in the nfo file for the video.  Then the actual actor photo goes into the ../metadata/people/actor_name directory as portrait.jpg and folder.jpg.  I also create a person.nfo file in the ../actor_name directory. 

With emby 4.8.0 that still seems to be working fine.

Is something changing?  I read the above linked post and am completely confused.  Is there a better way or another recommended way to do this?

If there has already been a post on this and I missed it, just let me know.  Thanks very much!!!

Edited June 22, 2022 by gbcox

[Luke 42216]

Hi, when the actor has a Tmdb id or Imdb, then that id will become part of the actor folder name in order to avoid collisions of multiple actors with the same name.

[gbcox 13]

I am trying to determine whether something changed in the way Emby handles local people images.

On 4.8.0, this used to work properly for me. I could place the person image in the person’s folder under metadata/people, and if I later replaced that image, a metadata refresh would pick up the change and the updated image would display.  I'm now on 4.10.04.

That no longer seems to be the case.

What I am seeing now is this:

• If I manually add a person photo through the web UI, Emby saves it as folder.jpg in that person’s folder under metadata/people.
• That appears to confirm the location is correct.
• However, if I then overwrite that same folder.jpg on disk with a different image, Emby does not display the replacement image.
• Instead, the person image goes blank again.

So at least on my system, this no longer behaves the way it used to. Previously, replacing the local image and refreshing metadata was sufficient. Now it is not.

Has something changed in how local people images are cached or refreshed? Is directly replacing folder.jpg no longer expected to work? If so, what is the current recommended method for updating local people images outside the web editor?

[Luke 42216]

11 hours ago, gbcox said:

I am trying to determine whether something changed in the way Emby handles local people images.

On 4.8.0, this used to work properly for me. I could place the person image in the person’s folder under metadata/people, and if I later replaced that image, a metadata refresh would pick up the change and the updated image would display.  I'm now on 4.10.04.

That no longer seems to be the case.

What I am seeing now is this:

• If I manually add a person photo through the web UI, Emby saves it as folder.jpg in that person’s folder under metadata/people.
• That appears to confirm the location is correct.
• However, if I then overwrite that same folder.jpg on disk with a different image, Emby does not display the replacement image.
• Instead, the person image goes blank again.

So at least on my system, this no longer behaves the way it used to. Previously, replacing the local image and refreshing metadata was sufficient. Now it is not.

Has something changed in how local people images are cached or refreshed? Is directly replacing folder.jpg no longer expected to work? If so, what is the current recommended method for updating local people images outside the web editor?

Hi, if you tamper with the contents of the server metadata folder, then you need to either manually refresh metadata on the person or run the scan metadata folder scheduled task afterwards.

 It’s a big folder. The server does not do any automated scanning on it to see if you might have done something to it.

[gbcox 13]

Hi Luke,

I do have a workaround and can script around this, so I am not blocked. That is not really the point.

The point is that something changed, the manual scan advice does not solve it, and the current behavior for people is not consistent with the behavior for movies.

What used to work for me was straightforward: I could manage local people images directly in the metadata folder, refresh metadata, and Emby would pick up the change. That no longer works.

What I am seeing now is this:

• If I manually place a folder.jpg into a person’s metadata folder, using the exact naming and location Emby itself uses, Emby does not reliably honor it.
• If I add the image through the web interface, Emby writes folder.jpg into that same folder and it displays correctly.
• If I then replace that same folder.jpg on disk with a different valid image, Emby does not handle the replacement properly. The image either does not update or goes blank.
• In my testing, scan/refresh behavior does not resolve this and may remove manually managed files instead.

So yes, I have a workaround. I can convert the image to base64 and use the API to load it, and that works because Emby then creates the folder.jpg file itself.

But that just raises a bigger question: why is there now a mandatory API Kabuki dance specifically for actor art?

Requiring admin authentication for a metadata-changing API call is one thing. Requiring base64 conversion and an API-only path for person images, while movie posters and video NFO files still follow a logical local file-first workflow, is another. From the user side, that is an obvious inconsistency.

One of the main reasons many of us use Emby is to curate private or local-heavy libraries that do not exist on TMDb or IMDb. I have scripts that build titles, actors, and metadata into NFO files for hundreds of non-mainstream entries. For movies, local metadata still works in a direct and sensible way. For people, it now appears that local filesystem management is no longer treated as authoritative in the same way.

That is the actual issue here. Not whether I can hack around it, but that the workflow for people has changed while the workflow for movies apparently has not.

And that leads to the documentation problem: if the intended workflow for people is now “base64 the image, authenticate as admin, POST it through the API, and let Emby create folder.jpg itself,” then that is a major workflow change and it is not clearly documented as such.

Related to that, is person.nfo even still a meaningful part of the supported workflow for people metadata? There are enough signs now that people NFO/image handling is no longer behaving like the older local workflow, but I do not see that stated clearly anywhere.

So my questions are simple:

Was this workflow change for people intentional?

If so, why is people artwork now handled differently from movie artwork?

And is person.nfo still actually supported as a reliable local metadata mechanism for people, or not?

[Luke 42216]

Quote

the manual scan advice does not solve it,

What manual scan are you referring to?