Emby Chronic Metadata Constipation Syndrome™ 💩

[AJAYSWebDesign 8]

Emby Chronic Metadata Constipation Syndrome™

I've noticed a recurring problem with Emby when refreshing metadata in a large library (approximately 44,000 media files).
Emby seems to become progressively slower at processing metadata refreshes, sometimes reaching the point where very little useful work appears to be happening.

To investigate, I developed a PowerShell monitoring utility, affectionately named the Emby HDD Stethoscope™, which monitors Emby's process disk I/O, including read/write throughput, operations per second and periods of inactivity.

Recently, I initiated a metadata refresh on a particularly large folder. Activity eventually slowed considerably, suggesting the refresh was largely complete.

I then ran my Emby Performer Poster Uploader™, a Python utility that checks whether Emby has registered Person records from local metadata and uploads corresponding artwork.

Result: ZERO posters uploaded, with 223 people still not registered in Emby.

So I restarted Emby Server and repeated the refresh on exactly the same folder.

And suddenly, Emby found its second wind!

The Stethoscope™ showed dramatically increased activity, with repeated bursts of 5–20 MB/s and peaks exceeding 1,600 I/O operations per second.

After considerably less time, I ran the same poster uploader again.

Before restart: 0 posters uploaded.

After restart: 90 posters uploaded.

Same hardware. Same files. Same metadata. Same utilities.

The significant difference? A server restart.

While this doesn't conclusively establish the cause, it strongly suggests Emby can become bogged down when processing large libraries.

It's almost as though restarting says:

"Hey Emby! Stop whatever it is you think is important, clear the decks, and get on with the metadata refresh I actually asked you to perform!"

The diagnosis

I've decided this condition deserves its own medical classification:

Emby Chronic Metadata Constipation Syndrome™

Symptoms:

• Sluggish metadata movement

• Severe database congestion

• Prolonged periods of apparent inactivity

• Temporary relief following a server restart

Recommended treatment: A regular reboot to get things moving again.

A question for the developers

Is there a known issue with metadata processing becoming progressively less efficient in very large libraries?

Could background tasks, database contention or processing queues explain this behaviour?

And why does restarting the server appear to make such a dramatic difference?

I'd genuinely welcome a technical explanation.

Of course, based on previous experiences reporting bugs, I'm half expecting the familiar:

"Thanks for reporting this. We're aware of the issue and may address it sometime in the future."

Which sometimes feels like the software-support equivalent of "Move along, nothing to see here."

Reporting bugs can occasionally feel like criticising Trump at a press conference — you arrive with evidence and somehow leave feeling like you're the problem for raising it!

Final thoughts

I'm not suggesting Emby is full of ****. I'm merely observing that restarting it seems to get things moving again.

I'd report this as a bug, but based on previous experience, I suspect nobody will give a ****.

Hopefully, this time, somebody will!

 

 

Edited Sunday at 07:47 AM by seanbuff
language

[Luke 43402]

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

[HawkXP71 133]

Does your process monitory list the memory in use of the server executable as well. 

My bet, it's a resource leak caused by relying on garbage collection in a tight loop