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 Sunday at 02:10 AM 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 Sunday at 07:33 PM by DarWun

[Luke 42706]

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 Tuesday at 02:21 AM by DarWun

[sa2000 787]

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 787]

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 yesterday 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 787]

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 2 hours ago by DarWun

[sa2000 787]

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 2 hours ago by DarWun

[sa2000 787]

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 59 minutes ago by DarWun

[sa2000 787]

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.