Identify not working

[crusher11 1101]

1 minute ago, speechles said:

But at least they reverse their HDD decision. 

Huh?

[speechles 2055]

3 minutes ago, crusher11 said:

Those are 20/5/3 for me at the moment.

You might want to make it 5/5/3 and see if that speeds it up. With 20 connections you need more memory.

[Happy2Play 9780]

2 minutes ago, speechles said:

Understand. There is only so much they allow. But at least they reverse their HDD decision. There is only so much you can do. I had options thankfully.

@Happy2Playinteresting. Thanks for that bit of info. That would explain the memory spike.

Comment in another topic.

On 10/2/2025 at 2:59 PM, Luke said:

We need to add more settings to the db screen but there's up to 5 connections now, so whatever cache size you use, it will be for each connection. So it could be X5. So factor that into whatever size you choose.

 

2 minutes ago, crusher11 said:

Those are 20/5/3 for me at the moment.

Wonder it your setup would be better being 5/5/3?  But currently you have to manually edit file or update via the api.

[speechles 2055]

3 minutes ago, crusher11 said:

Huh?

Synology...

https://www.tomshardware.com/pc-components/nas/synology-walks-back-controversial-compatibility-policy-for-2025-nas-units-third-party-hdd-and-ssd-support-returns-with-diskstation-manager-7-3-update

[crusher11 1101]

No difference after changing max connections.

[brothom 177]

I also noticed some issues where scheduled tasks would "impede" requests to refresh meta data or identify media.
In my case, refreshing/identifying would take place after (all) scheduled tasks that were running had completed so in some cases this can take a long time. 

Previously these actions would be run immediately but now seem to be pushed into background tasks?

[crusher11 1101]

Even just opening the "add to collections" dialog takes like 10 seconds. Search results take 20 seconds to show up. The whole server is just uselessly slow.

[brothom 177]

7 minutes ago, crusher11 said:

Even just opening the "add to collections" dialog takes like 10 seconds. Search results take 20 seconds to show up. The whole server is just uselessly slow.

That sounds like a different issue though. Are you sure there aren't multiple instance of Emby running or something like that?

When was the last time you restarted the server and do you run Emby as a service?

[crusher11 1101]

2 hours ago, brothom said:

Are you sure there aren't multiple instance of Emby running

Yes.

2 hours ago, brothom said:

When was the last time you restarted the server

Restarting doesn't help; it's just as sluggish immediately after booting.

2 hours ago, brothom said:

do you run Emby as a service?

I don't know what that means.

[brothom 177]

23 hours ago, crusher11 said:

I don't know what that means.

@crusher11That probably means no, but if you're on Windows, did you follow this guide: https://emby.media/support/articles/Run-as-Windows-Service.html?

Are you connecting to your Emby server locally or through the internet?

Does connecting to Emby locally make it "faster"? 

If you're doing something, like adding an item to a collection, what happens on the server?
Do the CPU's or RAM or Disk also go to 100%?

[pwhodges 2012]

He's on Synology, as per another active thread.

Paul

[Luke 42077]

On 10/12/2025 at 4:21 AM, crusher11 said:

And an hour or so later, it's all correctly identified.

embyserver (2).txt 27.34 MB · 2 downloads

One way to improve the perofrmance of your server would be to consider reducing the large number of plugins that you have installed.

[crusher11 1101]

On 10/15/2025 at 11:33 PM, Luke said:

One way to improve the perofrmance of your server would be to consider reducing the large number of plugins that you have installed.

I've had the same plug-ins installed for years. 

[richt 94]

10 hours ago, crusher11 said:

I've had the same plug-ins installed for years. 

Just an observation -- Assuming you recently upgraded Emby, it is a new version of Emby and one or more of the plugins may not be working correctly with the changes to Emby.

Edited October 17, 2025 by richt

[crusher11 1101]

Updating to 4.9.2.4 seems to have resolved the issues with search, the Add to Collections menu, etc. Haven't had the need to manually identify anything since the update though.

[crusher11 1101]

Can confirm Identify/Refresh Metadata is still filling out a couple of fields and then sitting around doing nothing. No idea how long I'm going to have to wait for the rest of the metadata to load in. Even the limited data that has loaded in so far took like half an hour to come through.

embyserver.txt

[crusher11 1101]

Renamed the files of the recordings I was trying to identify, and ran a scan. Now none of them have any metadata at all.

Since I updated in an attempt to resolve this and the issue is persisting, this thread ought to be moved to the testing area.

embyserver (1).txt

[crusher11 1101]

Half an hour later and the first of the three has finally been scanned in. Still no sign of the other two.

embyserver (2).txt

[crusher11 1101]

Anyone?

[crusher11 1101]

The issue appears to be isolated to my Recordings library. 

[Luke 42077]

What do you mean by no sign of the other two?

[crusher11 1101]

4 hours ago, Luke said:

What do you mean by no sign of the other two?

I changed the filenames of three of my recordings, and ran a scan of the recordings library. They all appeared immediately with just the filename and no metadata. Over half an hour later, one of them finally got metadata and triggered the “media added” notification. As of the time of me posting that log, I was still waiting for the other two items to get their metadata and trigger as added.

All metadata was already present locally, as they'd been scanned in when they were first recorded and I store that data in NFO files with my media. Artwork is also stored with my media. It should not take over half an hour to scan anything in. And, indeed, on all other libraries I've added things to recently scanning things in works almost instantly, even when they're brand new and metadata has to be downloaded.

[visproduction 315]

FYI  Movie rate limits:
https://www.themoviedb.org/talk/5322c4aac3a3685725004c94
I think this may cause multiple actor image requests to fail, which may give the results that are complained about in this post.

• 30 requests every 10 seconds per IP
• Maximum 20 simultaneous connections per IP

 

[crusher11 1101]

Thirty minutes is long enough to make 5,400 requests, which should be more than enough for a single film.

[crusher11 1101]

And in fact, as previously noted all metadata was already present locally, so there was no need to make any requests to TMDB at all.

And again, this issue only affects the recording library. All other libraries that I've added anything to recently pick it up in seconds, even when it's a brand new film and online metadata and images need to be retrieved.

Edited November 14, 2025 by crusher11