Issue with Actor Metadata (not all actors) v4.9.5.0

[antilog17 2]

I just saw an updated version was available so I'll update and try again, but since I collected logging, I thought I would post anyway. Some actors seem to have corrupted database entries. Not sure how or why, but some actors don't get data downloaded and the they show up as a broken image. In addition, if you click on the actor, it goes to a page saying Authentication Failed instead of an actor profile. I've tried to delete the actor from all associated entries, refresh Metadata scheduled task and then refresh series metadata in hopes of cleaning up the entry, but it didn't work. I've attached screenshots and logs the the following process:

1) From the Series page, click the corrupted actor. EmbyActorIssueStep1.png

Log File: EmbyLogFromStartToAfterStep1-434027.txt
Log file is all the logging that added from prior to step 1. 434027 is the item ID for the actor (for convenience)

2) Click the back arrow to go back to series. EmbyActorIssueStep2.png

3) Click the uncorrupted actor. EmbyActorIssueStep3.png

Log File: EmbyLogFromStep1ToAfterStep3-141487.txt
Log file is all the logging that got added after the previous log file until Step 3.

EmbyActorIssueStep4.png
This is just the image of the page that loads after the click of Step 3

EmbyLogFromStartToAfterStep1-434027.txt EmbyLogFromStep1ToAfterStep3-141487.txt

[visproduction 374]

Christian Kane(I) is the current imdb name for this actor. 

There is also a Christian Kane(III), but not a (II) (2).

Imdb is also listing identical actor names with talent from earlier years, who have passed by adding their brith and death dates.
  John Smith(1931-1995)

Maybe the actor look up code needs to be tweaked to work with these changes at imdb and other sites.  Just a guess.

[antilog17 2]

The actor is marked across multiple series (also in Leverage and The Librarians) on my server so it's sort of all recognizing the same person. I did manually delete the actor from all series. Scan library metadata to make sure he was "gone" (he didn't show up in Emby search results) and refreshed the series. I ended back at the starting point. For me, I don't understand why the link takes to a page that says Authorization failed. 

Also of interest, from the web interface, on the actor, if you click the triple dot button and select Edit Metadata, it opens a blank form for editing series metadata. If you do the same thing for a working actor entry, you get a proper actor metadata form filled out. See images below.

EmbyActorIssue2-1.png
This is the triple dot button I'm talking about on the web interface. This is from the TV Series main page.

You can see the difference in 2-3 v 2-4. I wonder if Emby somehow has the itemId tied to wrong object type (hence opening the completely wrong form).

EmbyActorIssue2-3.png
The red box is to highlight the spinning blue circle indicating Emby is processing. That shows up and just continues to spin if you "Edit Metadata" on a corrupted actor entry.

[Luke 43118]

Hi, when you see this, try refreshing the metadata on the movie or series that the actor belongs to and that should hopefully get a new image.

[antilog17 2]

3 minutes ago, Luke said:

Hi, when you see this, try refreshing the metadata on the movie or series that the actor belongs to and that should hopefully get a new image.

I can confirm this did not work, but I haven't updated Emby to latest server. I will try that later tonight and report the results. If it happens again, should I also provide logging the way I did before?

[Luke 43118]

It will work just fine, but only after you've seen the broken image placeholder. Then it gets cleared out of the database and a new image can take that slot.

Prior to you seeing that, the actor will have an image url stored in the database. The server doesn't know yet that it's not valid, and it won't know until you try to view it. Therefore, a metadata refresh will not replace it.

[marriedman 110]

3 hours ago, visproduction said:

Christian Kane(I) is the current imdb name for this actor. 

There is also a Christian Kane(III), but not a (II) (2).

Imdb is also listing identical actor names with talent from earlier years, who have passed by adding their brith and death dates.
  John Smith(1931-1995)

Maybe the actor look up code needs to be tweaked to work with these changes at imdb and other sites.  Just a guess.

This is one of many reasons I don't have Emby do metadata scraping. You can't trust online sources many times. During my actor manager app development I have discovered many of the IMDb have the Roman numberals or grave-marker dates. Then there is TVDB with same name actors getting merged into one profile. I'll stick with my NFO's.

 

[antilog17 2]

47 minutes ago, Luke said:

It will work just fine, but only after you've seen the broken image placeholder. Then it gets cleared out of the database and a new image can take that slot.

Prior to you seeing that, the actor will have an image url stored in the database. The server doesn't know yet that it's not valid, and it won't know until you try to view it. Therefore, a metadata refresh will not replace it.

It didn't work. I literally tried it and reported back that it didn't work. I have also updated the server and it is still happening. Also, it's not just an image. I would ask to review my posts, but the link doesn't even go to a proper page (The Authorization Failed page from the second screen shot in my original post). I think something associates the itemId for the actor as a different object type (not an actor, basically).

[Luke 43118]

What makes you think it didn't work?

[Luke 43118]

Also the authentication error is being returned by your smb share:

2026-09-16 09:58:28.367 Error UserLibraryService-0HNOBD8PTDKNV:00000074: Error processing request
	*** Error Report ***
	Version: 4.9.5.0
	Command line: /share/CACHEDEV1_DATA/.qpkg/EmbyServer/system/EmbyServer.dll -programdata /share/CACHEDEV1_DATA/.qpkg/EmbyServer/programdata -ffdetect /share/CACHEDEV1_DATA/.qpkg/EmbyServer/bin/ffdetect -ffmpeg /share/CACHEDEV1_DATA/.qpkg/EmbyServer/bin/ffmpeg -ffprobe /share/CACHEDEV1_DATA/.qpkg/EmbyServer/bin/ffprobe -pidfile /var/run/emby-server.pid -defaultdirectory /share/CACHEDEV1_DATA/Public -updatepackage emby-server-qnap_{version}_x86_64.qpkg -noautorunwebapp
	Operating system: Linux version 5.10.60-qnap (root@mini-builder-01) (x86_64-QNAP-linux-gnu-gcc (toolchain config: [gcc-4.9.2 binutils-2.25 glibc-2.21]) 4.9.2, GNU ld (G
	OS/Process: x64/x64
	Framework: .NET 8.0.25
	Runtime: share/CACHEDEV1_DATA/.qpkg/EmbyServer/system/System.Private.CoreLib.dll
	Processor count: 8
	Data path: /share/CACHEDEV1_DATA/.qpkg/EmbyServer/programdata
	Application path: /share/CACHEDEV1_DATA/.qpkg/EmbyServer/system
	System.IO.IOException: System.IO.IOException: Authentication Failed.

 

[Luke 43118]

Also are you really on firefox 76? for some reason it is sending HEAD requests before every single GET, which is filling up your server log with 404 responses. I've done some brief investigation and it seems it was never normal for firefox to do that, so could be an option set on the browser, or an extension. I don't know if that's contributing to your issue but it's certainly making the logs harder to read.

[antilog17 2]

6 hours ago, Luke said:

What makes you think it didn't work?

I did the series refresh, waited for a bit, refreshed the series page in browser and the actor is still in such a state. I even searched in the search bar and sure enough, the actor shows still with the broken image placeholder and the same result of clicking on the actor page leading to the "Authorization failed". Interesting fact to note, is that the actor does not have an entry in the metadata/people folder. There is no folder for him or any file with his name in the people folder. This gives me a thought. Let me try manually adding a placeholder actor for the series (I'll name the entry Kane). Then use the identify option to identify him based on TheMovieDB id number and go from there.

5 hours ago, Luke said:

Also are you really on firefox 76? for some reason it is sending HEAD requests before every single GET, which is filling up your server log with 404 responses. I've done some brief investigation and it seems it was never normal for firefox to do that, so could be an option set on the browser, or an extension. I don't know if that's contributing to your issue but it's certainly making the logs harder to read.

I am not on Firefox. In fact, I am on Chrome. This is interesting, but does it lead to an explanation why some actors have the issue and others don't. Logically thinking, if those 404 and authentication failures are happening all the time, why is it only specific actors that result in it? I'll look through the logs myself tonight (didn't have time during the day).

[antilog17 2]

Sorry, I think I need to specify more details, because there is some confusion. This is entirely my fault. I apologize.

My Emby server is running directly on a QNAP Station that has an intel chip (not ARM). The NAS itself contains the video files so Emby is effectively self-contained to the QNAP NAS. I do have a File Explorer session opened from the Windows laptop to the NAS, but that is directly via SMB, not through Emby.

When I access the server via browser, my browser is directly accessing Emby on the NAS, so Windows as an OS is never involved. The error you pointed out is in direct response to the GetByItemid request.

 

Quote

2026-09-16 09:58:28.346 Debug SqliteItemRepository: GetitemById Person 434027 Christian Kane
2026-09-16 09:58:28.367 Error UserLibraryService-0HNOBD8PTDKNV:00000074: Error processing request
    *** Error Report ***
    Version: 4.9.5.0
    Command line: /share/CACHEDEV1_DATA/.qpkg/EmbyServer/system/EmbyServer.dll -programdata /share/CACHEDEV1_DATA/.qpkg/EmbyServer/programdata -ffdetect /share/CACHEDEV1_DATA/.qpkg/EmbyServer/bin/ffdetect -ffmpeg /share/CACHEDEV1_DATA/.qpkg/EmbyServer/bin/ffmpeg -ffprobe /share/CACHEDEV1_DATA/.qpkg/EmbyServer/bin/ffprobe -pidfile /var/run/emby-server.pid -defaultdirectory /share/CACHEDEV1_DATA/Public -updatepackage emby-server-qnap_{version}_x86_64.qpkg -noautorunwebapp
    Operating system: Linux version 5.10.60-qnap (root@mini-builder-01) (x86_64-QNAP-linux-gnu-gcc (toolchain config: [gcc-4.9.2 binutils-2.25 glibc-2.21]) 4.9.2, GNU ld (G
    OS/Process: x64/x64
    Framework: .NET 8.0.25
    Runtime: share/CACHEDEV1_DATA/.qpkg/EmbyServer/system/System.Private.CoreLib.dll

whereas the other log file just shows a working response for the other actor
 

Quote

2026-09-16 10:00:09.474 Debug SqliteItemRepository: GetitemById Person 141487 Caroline Loncq
2026-09-16 10:00:09.475 Debug UserLibraryService-0HNOBD8PTDKNV:00000079: http/1.1 Response 200 to host5. Time: 1ms. GET http://192.168.0.207:51000/emby/Users/ef3440085f044ffd99d79d354304cf9e/Items/141487?fields=ShareLevel&ExcludeFields=VideoChapters,VideoMediaSources,MediaStreams&X-Emby-Client=Emby Web&X-Emby-Device-Name=Chrome Windows&X-Emby-Device-Id=49a90ac8-215f-4f64-a0f7-8eb8547c3896&X-Emby-Client-Version=4.9.5.0&X-Emby-Token=x_secret5_x&X-Emby-Language=en-us. 
2026-09-16 10:00:09.475 Debug WebAppService-0HNOBD8PTDKO0:00000077: http/1.1 GET http://192.168.0.207:51000/web/favicon.ico. Source Ip: host5, UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36

 

[antilog17 2]

Found the cause!

I really screwed the pooch on this one, but just a little surprised the recovery mechanism from this isn't better. So long ago, I guess I had actor metadata stored for this actor in metadata\People\C\Christian Kane\. I think that was a very old path structure that was defined by some really old tools. After learning that there was generally a new way that Emby handled the metadata and that while linux supported both "people" and "People" folders in the metadata folder, Windows was getting confused if I navigated myself. I figured since the mechanism changed, I deleted the "People" folder thinking for any actors now missing, Emby would refresh and pull them down again, but it looks like for some actors, it didn't work. (Bold in the quote below is a path that no longer exists).

Quote

2026-09-16 23:42:59.296 Error ImageService-0HNOKDKNBRSMH:0000000D: Error processing request
	*** Error Report ***
	Version: 4.10.0.40
	Command line: /share/CACHEDEV1_DATA/.qpkg/EmbyServer/system/EmbyServer.dll -programdata /share/CACHEDEV1_DATA/.qpkg/EmbyServer/programdata -ffdetect /share/CACHEDEV1_DATA/.qpkg/EmbyServer/bin/ffdetect -ffmpeg /share/CACHEDEV1_DATA/.qpkg/EmbyServer/bin/ffmpeg -ffprobe /share/CACHEDEV1_DATA/.qpkg/EmbyServer/bin/ffprobe -pidfile /var/run/emby-server.pid -defaultdirectory /share/CACHEDEV1_DATA/Public -updatepackage emby-server-qnap_{version}_x86_64.qpkg
	Operating system: Linux version 5.10.60-qnap (root@mini-builder-01) (x86_64-QNAP-linux-gnu-gcc (toolchain config: [gcc-4.9.2 binutils-2.25 glibc-2.21]) 4.9.2, GNU ld (G
	OS/Process: x64/x64
	Framework: .NET 8.0.28
	Runtime: share/CACHEDEV1_DATA/.qpkg/EmbyServer/system/System.Private.CoreLib.dll
	Processor count: 8
	Data path: /share/CACHEDEV1_DATA/.qpkg/EmbyServer/programdata
	Application path: /share/CACHEDEV1_DATA/.qpkg/EmbyServer/system
	System.IO.IOException: System.IO.IOException: Authentication Failed.
	   at EzSmb.Transports.Connection..ctor(PathSet pathSet, ParamSet paramSet)
	   at EzSmb.Node.GetNode(String path, ParamSet paramSet, Nullable`1 isDirectory)
	   at Emby.Server.Implementations.IO.SmbFileSystem.GetNode(String path, FileSystemCredentials credentials, Nullable`1 isDirectory)
	   at Emby.Server.Implementations.IO.SmbFileSystem.OpenRead(String path, FileSystemCredentials credentials)
	   at Emby.Server.Implementations.IO.ManagedFileSystem.OpenRead(String path)
	   at Emby.Server.Implementations.IO.ManagedFileSystem.CopyFileUsingStreams(String source, String target, Boolean overwrite)
	   at Emby.Server.Implementations.IO.ManagedFileSystem.CopyFile(String source, String target, Boolean overwrite)
	   at Emby.Drawing.Skia.SkiaEncoder.GetTempFile(String path, Boolean isError)
	   at Emby.Drawing.Skia.SkiaEncoder.GetSKFileStream(String path)
	   at Emby.Drawing.Skia.SkiaEncoder.EncodeImage(String inputPath, String outputPath, Boolean autoOrient, Nullable`1 orientation, Int32 quality, ImageProcessingOptions options, ImageFormat selectedOutputFormat)
	   at Emby.Drawing.ImageProcessor.ProcessImage(ImageProcessingOptions options, CancellationToken cancellationToken)
	   at Emby.Api.Images.ImageService.GetImage(ImageRequest request, Int64 itemId, BaseItem item, Boolean isHeadRequest)
	   at Emby.Server.Implementations.Services.ServiceController.GetTaskResult(Task task)
	   at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost httpHost, IServerApplicationHost appHost, IRequest httpReq, IResponse httpRes, IStreamHelper streamHelper, RestPath restPath, String responseContentType, CancellationToken cancellationToken)
	   at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IRequest httpReq, RestPath restPath, String urlString, String localPath, String contentTypeInPath, CancellationToken cancellationToken)
	Source: Emby.Server.Implementations
	TargetSite: Void .ctor(EzSmb.Paths.PathSet, EzSmb.Params.ParamSet)
	Path: \\KSMEDIANAS\HTPC\MediaBrowser\metadata\People\C\Christian Kane\poster.jpg

I did try completely removing Christian Kane from Emby, enabling the vacuum database option and deleting cache after a shutdown. But a series refresh picked up the bad path again (must be saved the database itself). Is it possible to add a request to Emby that when handling actors or other people, if a file is not located, clear out the database entry for that bad field? My dummy placeholder didn't quite work and it looks like I may have permanently corrupted these entries.

[Luke 43118]

Thanks for following up. You may want to look at the logs at all the cases of firefox/76 in the user agent string and hunt down what is sending those requests to your server.