Adding a new Podcast to Emby results on freeze entire NAS. V4.9

[DarkStar1977 119]

Emby Team.

I don't know what you've made with 4.9 but is completely overloading a PR4100 NAS that worked perfectly on version 4.8.

The new version is consuming RAM and CPU resources like hell and even sometimes crashing EmbyServer service iself, making the unit to overheat and launch warnings that temperture it too high, freezing the NAS completely with no other way to recover to force a shutdown by pressing the power button, taking more than 20 seconds to load the "edit" page for images in all content, and the last one, adding a new podcast source, making freeze the NAS forcing me to press the power button to shutdown.

Every time you press the button to shutdown you risk to damage the information on the NAS and takes more than 20 minutes to restart to check data integrity and coherence.

I'm attaching the last log, but please check this version because it's clear is not optimized for this Hardware at all and must have been stayed as beta for longer time.

Thanks.

Before Shutting down:

embyserver-63896316744.txt

After rebooting,

hardware_detection-63896316778.txt embyserver (3).txt

Edited October 17, 2025 by DarkStar1977

[Luke 42077]

Hi, I would suggest removing these plugins:

2025-10-17 16:52:28.674 Info App: Loading statistics, Version=3.4.2.0, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/Statistics.dll
2025-10-17 16:52:28.674 Info App: Loading InfuseSync, Version=1.5.2.0, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/InfuseSync.dll
2025-10-17 16:52:28.675 Info App: Loading ChapterApi, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/ChapterApi.dll
2025-10-17 16:52:28.675 Info App: Loading playback_reporting, Version=2.1.0.7, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/playback_reporting.dll
2025-10-17 16:52:28.675 Info App: Loading EpMetaRefresh, Version=1.0.0.1, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/EpMetaRefresh.dll
2025-10-17 16:52:28.675 Info App: Loading ClassificationMapper, Version=1.0.0.4, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/ClassificationMapper.dll
2025-10-17 16:52:28.675 Info App: Loading XmlMetadata, Version=3.5.1.0, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/XmlMetadata.dll

Then restart the server and see how things compare.

[DarkStar1977 119]

4 hours ago, Luke said:

Hi, I would suggest removing these plugins:

2025-10-17 16:52:28.674 Info App: Loading statistics, Version=3.4.2.0, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/Statistics.dll
2025-10-17 16:52:28.674 Info App: Loading InfuseSync, Version=1.5.2.0, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/InfuseSync.dll
2025-10-17 16:52:28.675 Info App: Loading ChapterApi, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/ChapterApi.dll
2025-10-17 16:52:28.675 Info App: Loading playback_reporting, Version=2.1.0.7, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/playback_reporting.dll
2025-10-17 16:52:28.675 Info App: Loading EpMetaRefresh, Version=1.0.0.1, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/EpMetaRefresh.dll
2025-10-17 16:52:28.675 Info App: Loading ClassificationMapper, Version=1.0.0.4, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/ClassificationMapper.dll
2025-10-17 16:52:28.675 Info App: Loading XmlMetadata, Version=3.5.1.0, Culture=neutral, PublicKeyToken=null from /mnt/HD/HD_a2/emby/plugins/XmlMetadata.dll

Then restart the server and see how things compare.

@Lukethe answer to a problem with a new version cannot be remove the plugins always. If upgrading results on losing funtionalities (plugins) to keep the software stable .... well does not seems so professional.

All this plugins are triggered by scheduled tasks except infuse that only works when a infuse client is connected and Playback reporting that runs when you execute the plugin, none of those are applicable no scheduled tasks were running no infuse clients were connected and of course I did not click on Playback reporting.

So, try again ...

[sa2000 673]

Lets try and understand when the memory increases when a new podcast is added

I see that you are not running scheduled "Library Media Scan" tasks - that is good to have disabled whilst there is a memory usage issue - for which there are a number of forum threads. It was found that users with large libraries could end up with memory exhaustion after repeated and frequent library media scans

I have a script that you can us in an ssh session (through tools such as PuTTY) to log memory usage for Emby Server every second 

Have a share on the NAS where you can write this memory usage log to and then copy to your PC at the end of the test for gathering diagnostics - you can use WinSCP or a network share accessible to the PC for transferring the file - assuming you have set permissions ok for that area

So setup ssh on the NAS and login to the sshd account using PuTTY. set the current directory to where you want the output of the script to save the file to

This is the script to run

(echo "PID,time,VmPeak,VmSize,VmLck,VmPin,VmHWM,VmRSS,RssAnon,RssFile,RssShmem,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|^RssAnon|^RssFile|^RssShmem|^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 "$(cat /etc/hostname)_emby_memory_log_$(date +%F).csv"

Leave this script running. It will output the memory usage when an EmbyServer process is running to a csv file in the current directory of the ssh session. 

The filename will be "<hostname>_emby_memory_log_<date>.csv"

Leave debug logging enabled on the emby server as you have now

Restart the emby server to get fresh logs created

Wait for it to get initialized and settle down. Then start the test of adding a podcast. When the issue arises and the process is OOM Killed by the WD OS, gather the diagnostics

Download all the emby server log files covering whole period since launch

Copy out the memory logging csv file from the NAS

See if you can also in an ssh session look for "/var/log/kern.log" and "/var/log/kern.log.1"

copy out these files - you will need to use sudo to copy to an area that is accessible to you. Also once copied, use sudo chown and sudo chmod to change permissions and ownership of the copied files to allow you to copy to the PC from an area accessible to the PC through WinSCP or network share

Note down when the podcast was added and provide that information as well with the diagnostics

 

 

 

[DarkStar1977 119]

6 hours ago, sa2000 said:

Lets try and understand when the memory increases when a new podcast is added

I see that you are not running scheduled "Library Media Scan" tasks - that is good to have disabled whilst there is a memory usage issue - for which there are a number of forum threads. It was found that users with large libraries could end up with memory exhaustion after repeated and frequent library media scans

I have a script that you can us in an ssh session (through tools such as PuTTY) to log memory usage for Emby Server every second 

Have a share on the NAS where you can write this memory usage log to and then copy to your PC at the end of the test for gathering diagnostics - you can use WinSCP or a network share accessible to the PC for transferring the file - assuming you have set permissions ok for that area

So setup ssh on the NAS and login to the sshd account using PuTTY. set the current directory to where you want the output of the script to save the file to

This is the script to run

(echo "PID,time,VmPeak,VmSize,VmLck,VmPin,VmHWM,VmRSS,RssAnon,RssFile,RssShmem,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|^RssAnon|^RssFile|^RssShmem|^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 "$(cat /etc/hostname)_emby_memory_log_$(date +%F).csv"

Leave this script running. It will output the memory usage when an EmbyServer process is running to a csv file in the current directory of the ssh session. 

The filename will be "<hostname>_emby_memory_log_<date>.csv"

Leave debug logging enabled on the emby server as you have now

Restart the emby server to get fresh logs created

Wait for it to get initialized and settle down. Then start the test of adding a podcast. When the issue arises and the process is OOM Killed by the WD OS, gather the diagnostics

Download all the emby server log files covering whole period since launch

Copy out the memory logging csv file from the NAS

See if you can also in an ssh session look for "/var/log/kern.log" and "/var/log/kern.log.1"

copy out these files - you will need to use sudo to copy to an area that is accessible to you. Also once copied, use sudo chown and sudo chmod to change permissions and ownership of the copied files to allow you to copy to the PC from an area accessible to the PC through WinSCP or network share

Note down when the podcast was added and provide that information as well with the diagnostics

 

 

 

I'm happy to run any test needed, but the memory consumption is happening all the time.

Now, no activity on the emby server:

NAS Memory usage:

So it's consuming more than a half of installed memory on this device (4GB) just doing nothing ...

Ir's not limited to podcasts, as I explained since v.4.9, the memory consumption is crazy when the server is doing nothing, when you do anything, just a simple metadata refresh, the CPU peaks to 70%, load "edit images" for any item, takes near to 7 seconds, refreshing the home screen, takes +10 seconds.

The funny thing is that if I restart the Emby server, all drops down to 10-20% usage and the interface is speed up after the restart, but as hours are passing and the emby server is up and running, starts to consume RAM for no reason and even sometimes crash the entire process having to restart if from the NAS application interface.

I'm pretty sure, the podcasts is one more thing that makes it hang up, but is not the reason.

I'm happy if you need to run the script but I believe is something else.

 

[sa2000 673]

3 minutes ago, DarkStar1977 said:

I'm happy to run any test needed, but the memory consumption is happening all the time.

We need to understand what actions make memory go up faster. Hence @Luke's suggestion to see what it is like without the added plugins

On my WD MyCloudPR4100 memory was reaching 3Gb daily with scheduled Scan Media Library every 4 hours. Switching to weekly it is now at only 1Gb after more than a day. So I will probably just need once or twice a week restart of the Emby Server process - whilst we have this issue with high memory use.

So what I am after is establishing how soon after launch we reach 2Gb and 3G and look for clues in the debug log files and second by second RSS / Swap memory usage log

You can start with just normal running for a couple of days and then I can have a look at the diagnostics and suggest next step

It would still be good to know on a vanilla install without added plugins, how emby server uses memory - so that could be another 2 days test

Note that the script can be left running and it would detect any PID changes after Emby Server restarts. If you do need to restart the script, make sure you make a change to the output filename if the restart is on the same day - best to make sure the PC running the script does not restart / shutdown and leave it running all the time - until completion of all tests

 

 

 

[DarkStar1977 119]

8 minutes ago, sa2000 said:

We need to understand what actions make memory go up faster. Hence @Luke's suggestion to see what it is like without the added plugins

On my WD MyCloudPR4100 memory was reaching 3Gb daily with scheduled Scan Media Library every 4 hours. Switching to weekly it is now at only 1Gb after more than a day. So I will probably just need once or twice a week restart of the Emby Server process - whilst we have this issue with high memory use.

So what I am after is establishing how soon after launch we reach 2Gb and 3G and look for clues in the debug log files and second by second RSS / Swap memory usage log

You can start with just normal running for a couple of days and then I can have a look at the diagnostics and suggest next step

It would still be good to know on a vanilla install without added plugins, how emby server uses memory - so that could be another 2 days test

Note that the script can be left running and it would detect any PID changes after Emby Server restarts. If you do need to restart the script, make sure you make a change to the output filename if the restart is on the same day - best to make sure the PC running the script does not restart / shutdown and leave it running all the time - until completion of all tests

 

 

 

I'm reluctant to remove the plugins because I spent a lot of time configuring it at my "taste", additionally, the Playback reporting plugin has an historic data since the server was deployed for first time that I don't want to lose by removing it.

Is there any way to disable the plugins, without removing it ?

This will be very helpful for testing if a plugin is the cause of any issue without the "uninstall"/"install" process...

Edited October 24, 2025 by DarkStar1977

[DarkStar1977 119]

BTW, this is coming from the "Statistics" plugin, in case helps on sizing of my libraries:

[sa2000 673]

1 hour ago, DarkStar1977 said:

Is there any way to disable the plugins, without removing it ?

I have never tried it but for the plugins that are not part of the emby release and were added by you, moving out the dll files to another location could achieve this

/mnt/HD/HD_a2/emby/plugins

The configurations would I guess stay in there - but to be on the safe side, you could make a copy of the configurations directory to another directory but keeping it in place - so would be just the dll's that get moved out

/mnt/HD/HD_a2/emby/plugins/configurations

And probably safer still - if there are any scheduled tasks for the plugins, you could edit them before you move the plugins dll's - so that they do not run

When re-instating the dll's after the test, make sure pernissions and ownership as before

so save a copy of the output from "ls -ail" for each of the directories

 

Edited October 24, 2025 by sa2000