Emby Beta 4.10.0.15+: Crashing due to Out of Memory on DS918+ Package Center Install

[DarWun 363]

Since updating to Beta 4.10.0.15 I've been experiencing server shutdowns due to excessive Emby memory utilization at least once a week. This is something I've experienced intermittently in the past (every couple of months). But the frequency of the occurrence has increased to once a week. I've reviewed other posts in this thread about memory issues on the Synology platform, and none of the advice provided addresses the issue as I am seeing it. Recommendations from the Emby team in the previous posts are to uninstall certain plugins to reduce memory utilization. I have two of those plugins installed...Statistics and Playback Reporting. But the memory issue I'm seeing has nothing to do with those plugins as far as I can tell.

The attached log is from the most recent out of memory event. I initiated a library scan from the scheduled tasks after adding a couple of videos to my library. Emby memory usage on the NAS immediately went from 900MB to 1.62GB. That memory was not released after the scan completed. I do not believe the plugins that the Emby team has previously asked to be uninstalled to troubleshoot memory issues had anything to do with the memory usage. Memory usage jumped entirely due to the initiation of the library scan. The server became sluggish and unresponsive. Eventually Emby shutdown.

The image below shows the memory usage jump upon initialization of the "Scan media library" task. Memory usage before initiating the library scan was 70%. It increased to 90%+ upon initiating the scan.

I'm not sure how to help troubleshoot this issue. I have not had memory issues running Emby on my Synology NAS previous to Beta 4.10.0.15. Since upgrading to that version, my server is shutting down at least once a week due to out of memory issues.

 

 

embyserver-63918665956.txt

Edited July 5 by DarWun

[DarWun 363]

Coincidentally, the NAS was updated to DSM Version 7.4-90075 two days prior to the update to Emby Beta 4.10.0.15. I thought that was worth pointing out.

 

Edited July 5 by DarWun

[Luke 42726]

HI, please try removing these plugins:

	Bulky 1.0.20.0
	Chapter API 1.4.0.0
	Credits Detector 2.6.2.0
	Episode Refresh 1.0.0.1
	Intros Backup 1.0.0.6
	Playback Reporting 2.1.0.7
	Statistics 3.4.2.0
	TimeLordMovies 19.8.3.1105
	TimeLordTV 19.8.3.1105
	Transcoding Tests 4.8.5.0
	Xml Metadata 3.5.1.0

Then restart the server and see how things compare.

[DarWun 363]

22 hours ago, Luke said:

HI, please try removing these plugins:

	Bulky 1.0.20.0
	Chapter API 1.4.0.0
	Credits Detector 2.6.2.0
	Episode Refresh 1.0.0.1
	Intros Backup 1.0.0.6
	Playback Reporting 2.1.0.7
	Statistics 3.4.2.0
	TimeLordMovies 19.8.3.1105
	TimeLordTV 19.8.3.1105
	Transcoding Tests 4.8.5.0
	Xml Metadata 3.5.1.0

Then restart the server and see how things compare.

These plugins have been installed for over a year (or several years in most cases) without an issue. They may be causing the incremental memory increase over time that has been reported by others. I've been rebooting my server every few weeks to address this. I fail to see how they could be responsible for a sudden increase in memory usage by Emby when a library scan is initiated. Jumping from 900Mb of memory usage to 1.62GB after initiating a scan...how could those plugins be causing that?

Most of those plugins identified are only run manually on my server. They do not run otherwise. My issue is that when I initiate a library scan, memory usage occasionally (once a week after updating to Beta 4.10.0.15) jumps significantly causing Emby to shutdown. I don't see how that could be a result of the plugins.

@sa2000In this post:

you stated that "For excessive memory usage investigations, I normally would use a script to record memory usage by Emby Server ... ". Can you provide that script?

Edited July 7 by DarWun

[sa2000 789]

7 hours ago, DarWun said:

These plugins have been installed for over a year (or several years in most cases) without an issue

It could still be plugin like "TimeLordTV" requiring a lot of memory because of number of seasons or episodes in specific shows.

On 05/07/2026 at 02:38, DarWun said:

Since updating to Beta 4.10.0.15 I've been experiencing server shutdowns due to excessive Emby memory utilization at least once a week.

What version was in use before this ?  

7 hours ago, DarWun said:

you stated that "For excessive memory usage investigations, I normally would use a script to record memory usage by Emby Server ... ". Can you provide that script?

I will provide you the script and it needs to be running in an ssh session on the NAS. I normally would like to have the memory usage covering from the launch time of emby server up to the time when it becomes too high and the emby server ends up unresponsive or gets killed by the OS with OOM kill. So the SSH session needs to remain running - with the script starting to log memory usage before the initial relaunch of emby server and up to the time of failures.  Together with the script memory usage logging, I would like to have the emby server running with debug logging enabled - enabled before the relaunch. Logs are kept for 3 days by default - so if the issue arises within the 3 days then we do not need to make any changes to extend that logs retention period

Enable ssh on the NAS, login using tools such as PuTTY and navigate to a directory where the script will write the memory usage log to

Then execute the script

(echo "PID,time,VmPeak,VmSize,VmLck,VmPin,VmHWM,VmRSS,VmData,VmStk,VmExe,VmLib,VmPTE,VmSwap"; while :; do PID=$(pidof EmbyServer | awk '{print $1}'); [ -z "$PID" ] && { sleep 1; continue; }; printf "%s," "$PID"; date "+%F %T" | tr '\n' ','; awk '/^VmPeak|^VmSize|^VmLck|^VmPin|^VmHWM|^VmRSS|^VmData|^VmStk|^VmExe|^VmLib|^VmPTE|^VmSwap/ {gsub(/ kB/, "", $2); gsub(/[ \t]/, "", $2); printf "%s,", $2}' /proc/$PID/status | sed 's/,$//'; echo; sleep 1; done) | tee -a "$(cat /etc/hostname)_emby_memory_log_$(date +%F).csv"

That will display to the screen as well as logging to a csv file - named: "<hostname>_emby_memory_log_<date>.csv" in the current directory

With this run then enable debug logging on embyserver  and then relaunch emby server

When the issue arises, abort the script (control & c) and provide all the embyserver log files (embyserver-xxxxx.txt files and embyserver.txt) and the csv file

Having said that, it would be worth trying first without the TimeLordTV plugin 

 

[sa2000 789]

7 hours ago, DarWun said:

(once a week after updating to Beta 4.10.0.15)

I do not believe that a weekly need to restart is excessive whilst there is the issue with scanning large libraries.

I am still interested to know what version was in use before that. 

[DarWun 363]

On 7/7/2026 at 5:47 AM, sa2000 said:

It could still be plugin like "TimeLordTV" requiring a lot of memory because of number of seasons or episodes in specific shows.

What version was in use before this ?  

I will provide you the script and it needs to be running in an ssh session on the NAS. I normally would like to have the memory usage covering from the launch time of emby server up to the time when it becomes too high and the emby server ends up unresponsive or gets killed by the OS with OOM kill. So the SSH session needs to remain running - with the script starting to log memory usage before the initial relaunch of emby server and up to the time of failures.  Together with the script memory usage logging, I would like to have the emby server running with debug logging enabled - enabled before the relaunch. Logs are kept for 3 days by default - so if the issue arises within the 3 days then we do not need to make any changes to extend that logs retention period

Enable ssh on the NAS, login using tools such as PuTTY and navigate to a directory where the script will write the memory usage log to

Then execute the script

(echo "PID,time,VmPeak,VmSize,VmLck,VmPin,VmHWM,VmRSS,VmData,VmStk,VmExe,VmLib,VmPTE,VmSwap"; while :; do PID=$(pidof EmbyServer | awk '{print $1}'); [ -z "$PID" ] && { sleep 1; continue; }; printf "%s," "$PID"; date "+%F %T" | tr '\n' ','; awk '/^VmPeak|^VmSize|^VmLck|^VmPin|^VmHWM|^VmRSS|^VmData|^VmStk|^VmExe|^VmLib|^VmPTE|^VmSwap/ {gsub(/ kB/, "", $2); gsub(/[ \t]/, "", $2); printf "%s,", $2}' /proc/$PID/status | sed 's/,$//'; echo; sleep 1; done) | tee -a "$(cat /etc/hostname)_emby_memory_log_$(date +%F).csv"

That will display to the screen as well as logging to a csv file - named: "<hostname>_emby_memory_log_<date>.csv" in the current directory

With this run then enable debug logging on embyserver  and then relaunch emby server

When the issue arises, abort the script (control & c) and provide all the embyserver log files (embyserver-xxxxx.txt files and embyserver.txt) and the csv file

Having said that, it would be worth trying first without the TimeLordTV plugin 

 

Thanks @sa2000! I'll post back with my results.

[DarWun 363]

@sa2000Quick update before running the script. I experienced another OOM event this morning, almost "exactly" five (5) days after the previous occurrence. 

As for my update history, prior to running Beta 4.10.0.15 I was running Beta 4.10.0.14. I updated to Beta 4.10.0.15 on June 18. I had the first OOM event on June 23. The next event occurred on June 25 followed by an event on July 3 and then again on July 8 (today).

Here is the full chronology of my update history since the beginning of May 2026:

I did not experience OOM events until updating to Beta 4.10.0.15. Unfortunately, I updated to DSM Version 7.4-90075 around the same time (June 16). So I can't rule out that the DSM update is not the issue.

In all cases the OOM event occurred first thing in the morning after adding shows recorded from the previous night to the library. Upon initiating a library scan, memory usage by Emby jumped significantly (once doubling from 900MB to 2GB). That brought total system memory usage to 95% (approx.). Even if Emby did not automatically shutdown on it's own after that occurred, I had to shut it down forcefully as it did not release the memory and became unresponsive.

I'm about to uninstall plugins before getting the script up and running. I'll post back as soon as I have anything new to report!

Edited Thursday at 12:07 AM by DarWun

[DarWun 363]

It got very close to an OOM memory event 14hrs after initiating the script. After initiating a library scan, memory usage by Emby went from 1.18GB to 1.8GB (approx). There was still enough ram available so Emby was able to recover. It was a bit sluggish. But still responsive. I'm not sure what caused the spike.

[sa2000 789]

This does happen on large libraries and if you are getting an OOM only once  a week, I would not consider that to be excessive whilst Emby Server has this issue with how memory is allocated. 

You have not indicated if you have removed / disabled the TimeLordTV plugin to see if it is a factor

[DarWun 363]

5 hours ago, sa2000 said:

This does happen on large libraries and if you are getting an OOM only once  a week, I would not consider that to be excessive whilst Emby Server has this issue with how memory is allocated. 

You have not indicated if you have removed / disabled the TimeLordTV plugin to see if it is a factor

I removed all the plugins in the list Luke provided, including TimeLordTV and TimeLordMovies. Memory usage by Emby hasn't actually changed much from prior to uninstalling the plugins. It started out at around 300MB and over the next five or six hours it climbed to somewhere between 900MB and 1.2GB where it sat for most of yesterday. It's currently sitting at 1.3GB after 24hours. This is pretty much normal behavior. Emby's memory usage suddenly jumping to 2GB+ when a library scan is initiated...that only started occurring in the last month. I'm not sure if what I have is considered a large library by the standards of other Emby users. 

Usually I only do a server reboot when a new Emby Beta version is released. Although recently that has meant the server is rebooted once a week due to frequent releases, in the past when releases were less frequent I definitely went two or more weeks between restarts without an OOM event occurring.

Anyway, thanks for your input!

Edited Friday at 01:34 PM by DarWun

[sa2000 789]

1 minute ago, DarWun said:

I removed all the plugins in the list Luke provided, including TimeLordTV and TimeLordMovies. Memory usage by Emby hasn't actually changed much from prior to uninstalling the plugins. It started out at around 300MB and over the next five or six hours it climbed to somewhere between 900MB and 1.2GB where it sat for most of yesterday. It's currently sitting at 1.3GB after 24hours. This is pretty much normal behavior. Emby's memory usage suddenly jumping to 2GB+ when a library scan is initiated.

what is the interval for scheduled task: Scan Media Library

[DarWun 363]

11 minutes ago, sa2000 said:

what is the interval for scheduled task: Scan Media Library

The "Scan media library" task is scheduled to run every six hours. That was the interval I seem to recall others recommended when I first setup the server may years ago. Usually I'll run it manually as well when new media is added or removed from the library.

Not sure if this is worth mentioning, but I've only seen the spike in memory usage when I run the "Scan media library" task manually. So far, I have never seen it happen when the tasks runs automatically according to the schedule.

Edited Friday at 01:47 PM by DarWun

[sa2000 789]

1 minute ago, DarWun said:

he "Scan media library" task is scheduled to run every six hours. That was the interval I seem to recall others recommended when I first setup the server may years ago. Usually I'll run it manually as well when new media is added or removed from the library.

Two things to try

- Change the interval to 8 hours and see if that is sufficient time for previously allocated memory to get released by the memory garbage collector in .Net

- When running manually, instead of running the scheduled task, just run the scan for the specific library

Of course you will need to restart Emby Server to establish if these changes make a difference

 

[DarWun 363]

15 minutes ago, sa2000 said:

Two things to try

- Change the interval to 8 hours and see if that is sufficient time for previously allocated memory to get released by the memory garbage collector in .Net

- When running manually, instead of running the scheduled task, just run the scan for the specific library

Of course you will need to restart Emby Server to establish if these changes make a difference

 

Will do. A new Beta version dropped anyway so this will give me a chance to install it.

I'll report back with my observations.

[DarWun 363]

1 hour ago, sa2000 said:

Two things to try

- Change the interval to 8 hours and see if that is sufficient time for previously allocated memory to get released by the memory garbage collector in .Net

- When running manually, instead of running the scheduled task, just run the scan for the specific library

Of course you will need to restart Emby Server to establish if these changes make a difference

 

@sa2000This may be a stupid question, but would the database settings be worth taking a look at? I set Database cache size and Analysis row limit at 1024 and 1000, respectively, when the option to adjust them was added to Emby. That seemed to be the general consensus at the time amongst users. I've never revisited those settings until now. I've just read:

It is recommending 1.5 to 2 times the library.db size for the cache setting.

My library.db file is currently around 200MB. So 1024MB for the cache size is likely overkill. Would lowering it to 512MB (or lower) be advised?

Edited Friday at 03:11 PM by DarWun

[sa2000 789]

2 minutes ago, DarWun said:

So 1024MB for the cache size is likely overkill. Would lowering it to 512MB (or lower) be advised

i missed asking about that. For some reason I had assumed you have come across the recommendations after 4.9 came out

Yes with 5 connections to the database now as from 4.9 and with each using that amount of cache - my new recommendation is to go with the default for cache which is 128 Mb

Unless you have tons of memory

 

[DarWun 363]

1 minute ago, sa2000 said:

i missed asking about that. For some reason I had assumed you have come across the recommendations after 4.9 came out

Yes with 5 connections to the database now as from 4.9 and with each using that amount of cache - my new recommendation is to go with the default for cache which is 128 Mb

Unless you have tons of memory

 

I'm not sure if did read those recommendations when 4.9 came out. I didn't seem to be having an issue with a cache size of 1024MB. So I just kept the setting as is and moved forward obliviously.

Anyway, I'll lower the cache to 128MB.

Also, my library.db size is 200MB, not 200GB.

[DarWun 363]

After making the setting changes, nothing seems to have changed with respect to memory usage by Emby on the Synology platform. Within 6hours of restarting the server with cache reduced to 128MB, library scan changed to 12hours (instead of 8 hours as recommended), and doing only individual library scans when new media is added, memory usage is sitting at 1.2GB as per the norm. No sudden spikes in memory usage. So that is good so far.

And here is I went off script. I reinstalled several of the plugins that Luke asked to be uninstalled. Yesterday, I reinstalled TimelordTV, TimeLord Movies, and Statistics. I had library updates I was doing that required them. After doing so, the memory utilization did not change. Within 24hours, Emby was utilizing around 900MB to 1GB of memory as per the norm. This morning, I accidentally manually ran the scheduled library scan task after I added new media to my library instead of scanning the individual library. Whoops! Old habits die hard. Emby's memory utilization almost doubled immediately. This time Emby did release the memory without shutting down.

I captured the memory jump with the script running. Unfortunately, I don't have the full history from server restart to the memory jump as my PC went to sleep at some point last night and shutdown the puTTy connection. I restarted the script when I woke up this morning about 20minutes before the memory utilization jumped. Whether or not it is of use? I have no idea. But I'm providing it anyway.

Library scan started at around 8:54am.

I'll shutdown the potentially "problematic" plugins again later tonight and continue monitoring with the script enabled.

MediaStorage_emby_memory_log_2026-07-13.csv embyserver-63919547583.txt

Edited 16 hours ago by DarWun

[DarWun 363]

Another observation:  One task that causes a jump in memory usage is backup. Emby Memory usage jumps by 200MB or more every time it runs.

 

Having said that, it does appear the memory was quickly released after the backup.

Edited 16 hours ago by DarWun

[sa2000 789]

Thanks for the info

11 hours ago, DarWun said:

Having said that, it does appear the memory was quickly released after the backup.

 

12 hours ago, DarWun said:

No sudden spikes in memory usage. So that is good so far.

 

That is good

 

12 hours ago, DarWun said:

And here is I went off script. I reinstalled several of the plugins that Luke asked to be uninstalled. Yesterday, I reinstalled TimelordTV, TimeLord Movies, and Statistics. I had library updates I was doing that required them. After doing so, the memory utilization did not change. Within 24hours, Emby was utilizing around 900MB to 1GB of memory as per the norm. This morning, I accidentally manually ran the scheduled library scan task after I added new media to my library instead of scanning the individual library. Whoops! Old habits die hard. Emby's memory utilization almost doubled immediately. This time Emby did release the memory without shutting down.

Thanks

The logs do show after the 12 hourly periodic scheduled task "scan media library" with last completing at 08:06 am, you did run one at 08:53 am. Memory usage peaked during this scan with an RSS peak of 2.1 Gb. Swap memory usage peaked at just above 2.1Gb. RSS came down to a low of 478 mb

The impact of the TimeLordTV and Statistics plugins appears to be minimal - picking out the scan period:

 

And this covers the whole period captured in the memory usage log

Edited 4 hours ago by sa2000

[DarWun 363]

3 hours ago, sa2000 said:

Thanks for the info

That is good

Thanks

The logs do show after the 12 hourly periodic scheduled task "scan media library" with last completing at 08:06 am, you did run one at 08:53 am. Memory usage peaked during this scan with an RSS peak of 2.1 Gb. Swap memory usage peaked at just above 2.1Gb. RSS came down to a low of 478 mb

The impact of the TimeLordTV and Statistics plugins appears to be minimal - picking out the scan period:

And this covers the whole period captured in the memory usage log

 

Thanks for summarizing all that! Any thoughts as to what would be causing the spike in RSS and swap memory usage when initiating a library the scan manually? That has been part of my morning routine for years. Even though I didn't start actually paying attention to the memory usage using Resource Monitor until recently, I would have been aware of the spike occurring as Emby becomes sluggish and unresponsive until the scan completes (or Emby shuts down due to OOM). That was not something I started experiencing until about a month ago after updating to Emby Beta 4.10.0.15 (and DSM 7.4-90075).

 

[sa2000 789]

6 minutes ago, DarWun said:

Any thoughts as to what would be causing the spike in RSS and swap memory usage when initiating a library the scan manually? That has been part of my morning routine for years.

It is an area that needs to be looked into and how memory is used for TV Shows and Seasons scanning. I do not know if number of episodes in a season or number of seasons in a show is a factor. 

The larger the library is, the bigger impact. The shorter the time interval is between scheduled scans, the bigger impact.

I do not have an answer - it is recognized that there is an issue here and memory usage needs to be improved

 

[DiabboVerdde 5]

I'm experiencing what appears to be the same issue on a Synology NAS and wanted to share my findings in case they help.

Environment

• Synology DS1819+
• DSM 7.3.2-86009
• 32 GB RAM
• Emby Server 4.9.5.0 (Package Center installation)
• .NET 8 runtime bundled with Emby

The problem only started recently. Prior to that, this server had been running reliably for a long time.

Symptoms

After a restart, Emby starts normally using approximately 350-400 MB RSS.

Throughout the day it remains very stable, even under heavy load. I tested:

• Three simultaneous 4K streams
• A full manual library scan while streaming

During those tests, Emby's RSS never exceeded approximately 850 MB.

The interesting part is that the problem consistently starts around midnight.

At approximately midnight, Emby's memory usage begins increasing in large steps. From that point on, the resident memory continues growing throughout the night until the server eventually runs out of memory and the Linux OOM killer terminates the Emby process.

On the night I monitored it, I observed approximately:

• 0.4 GB
• 1.3 GB
• 4.3 GB
• 4.8 GB
• 7.2 GB
• eventually peaking at 28.6 GB RSS

The growth appears to occur in roughly 30-minute intervals. Suggesting a process starting at midnight being triggered again and again every 30 minutes, eating up more and more memory every time until it crashes.

During this entire period the process is mostly idle:

• CPU around 4%
• approximately 20-21 threads
• process state is generally "sleeping"

So, it looks like something is simply eating up the memory, but not doing anything meaningful.

Kernel logs

The Linux kernel consistently reports Emby using approximately 25 GB of anonymous RSS immediately before it is killed.

Example:

Out of memory: Kill process 30784 (EmbyServer)
Killed process 30784 (EmbyServer)
anon-rss:25216920kB

Monitoring

To investigate, I wrote a script that records Emby's memory every minute and ingested the data into Splunk.

The graph clearly shows:

• Emby's RSS increasing in large steps beginning around midnight.
• Total system memory usage following Emby's growth almost exactly.
• Memory continuing to increase throughout the night until the OOM event.
• Jumps occur every 30 minutes, increasing about 3GB every time, until it crashes.
• You see the moment it crashes, the sudden deallocation of all that memory. I only realized it was down about an hour later and then I brought it back manually. When it came back, memory usage returns to a constant of 350-450MB and it's not increasing at this moment.

Debug logging

With debug logging enabled, I noticed repeated library validation messages approximately every 30 minutes:

ValidatePhysicalRoots
ValidateTopLibraryFolders

The timing appears to correlate with the memory increases, although I can't yet say whether those operations are the cause or simply occur at the same time.

Plugin observation

After reading Luke's recommendation in this thread, I checked my installed plugins.

Of the plugins mentioned, the only one I had installed was Statistics 3.4.2.0. So i just removed it and I'll monitor what happens at midnight now. My logs also have many 404 errors from the TMDB plugin at the 30 minute intervals. This plugin was was not mentioned by @Lukebut it might play a part in this issue.

I also realized that I installed the Statistics plugin relatively recently, which roughly coincides with when I first started noticing this problem.

I can't say whether it's the cause, but as my next step I've removed the Statistics plugin and will monitor tonight's behavior to see whether the overnight memory growth still occurs.

If anyone would like them, I have:

• minute-by-minute RSS history
• system memory history
• debug logs
• kernel OOM logs
• graphs showing the complete overnight memory progression
• Script i devised to grab the Emby statistics minute by minute to be ingested by Splunk

Hopefully this helps determine whether we're seeing the same underlying issue.

Edited 1 minute ago by DiabboVerdde