Emby Server Crashing: Emby (4.9.1.90) , Debian (13.2)

[chunk1970 4]

My Emby Server has just started crashing after a few minutes of runtime.

This has only just started as it was working fine yesterday.

- No additional updates on Debian

- No additional plugins installed

Not sure whats causing the issue and would appreciate any help on resolving this.

I have Jellyfin running on the same server on port 8097 without issue

Last portion of the error logs shows.

2025-11-27 20:11:54.779 Error SqliteItemRepository: Error saving items
    *** Error Report ***
    Version: 4.9.1.90
    Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb
    Operating system: Linux version 6.12.57+deb13-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian
    OS/Process: x64/x64
    Framework: .NET 8.0.11
    Runtime: opt/emby-server/system/System.Private.CoreLib.dll
    Processor count: 8
    Data path: /var/lib/emby
    Application path: /opt/emby-server/system
    System.ArgumentOutOfRangeException: System.ArgumentOutOfRangeException: Too many characters. The resulting number of bytes is larger than what can be returned as an int. (Parameter 'charCount')
       at System.Text.UTF8Encoding.UTF8EncodingSealed.<GetMaxByteCount>g__ThrowArgumentException|7_0(Int32 charCount)
       at SQLitePCLEx.utf8z.FromString(ReadOnlySpan`1 s)
       at SQLitePCLEx.raw.sqlite3_bind_text(sqlite3_stmt stmt, Int32 index, String val)
       at SQLitePCL.pretty.BindParameterImpl.Bind(String text)
       at Emby.Sqlite.SqliteExtensions.TryBind(IStatement statement, Int32 index, String value)
       at Emby.Server.Implementations.Data.SqliteItemRepository.SaveItem(IDatabaseConnection db, BaseItem item, Int64 userDataKeyId, IStatement insertItemStatement, IStatement updateItemStatement)
       at Emby.Server.Implementations.Data.SqliteItemRepository.SaveItemsInTranscation(IDatabaseConnection db, List`1 items, MetadataRefreshOptions metadataRefreshOptions)
       at Emby.Server.Implementations.Data.SqliteItemRepository.SaveItems(List`1 items, MetadataRefreshOptions metadataRefreshOptions, Action`1 afterSave, Boolean disableForeignKeys, CancellationToken cancellationToken)
    Source: System.Private.CoreLib
    TargetSite: Void <GetMaxByteCount>g__ThrowArgumentException|7_0(Int32)
 

[chunk1970 4]

Journalctl shows the following for emby-server.service.

#Nov 27 18:15:30 KillerNas systemd[1]: emby-server.service: A process of this unit has been killed by the OOM killer.
Nov 27 18:15:30 KillerNas systemd[1]: emby-server.service: Main process exited, code=killed, status=9/KILL
Nov 27 18:15:30 KillerNas systemd[1]: emby-server.service: Failed with result 'oom-kill'.
Nov 27 18:15:30 KillerNas systemd[1]: emby-server.service: Consumed 55.525s CPU time, 13.8G memory peak, 546.9M memory swap peak.

The memory usage is massive normally its approx 700MB to 1.GB for hours of emby usage however this is consuming 12+GB in less than a minute

Journalctl kernel reported the following:

Nov 27 20:11:59 KillerNas kernel: Out of memory: Killed process 13105 (EmbyServer) total-vm:276415640kB, anon-rss:14618796kB, file-rss:1912kB>
Nov 27 20:11:59 KillerNas kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.s>
 

Hope somebody out there knows the issue and how to fix it.

[Lessaj 467]

What is your database cache size set to? If not the default, can you try setting it to 128 MB?

[chunk1970 4]

Hi,

I have tried setting it to 128MB no difference, tried 256MB no difference.

Switched on the vacuum data option, no difference.

Again, I have not installed any update system or plugins on my Debian server.

This only started Yesterday the data before the system was working perfectly.

[Lessaj 467]

@sa2000 Can help provide you some instructions to capture memory statistics. Interesting that it just started though, a lot of the 4.9 memory usage issues were immediate on upgrade.

Please also provide a full server log and not just a snippet, it's an interesting error but I'm not sure if it's related, it could be.

[sa2000 674]

That is interesting error - have not come across it before

System.ArgumentOutOfRangeException: Too many characters. The resulting number of bytes is larger than what can be returned as an int. (Parameter 'charCount')

debug log may have some clues. Could it be a massive filename?

 

Suggest this approach:

Enable debug logging on the server - see Log Files

Start a session on the linux machine to run this script - it would save the output into a csv file in the current directory, so set the current directory to what you want to use and then run it

(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 -a "$(cat /etc/hostname)_emby_memory_log_$(date +%F).csv"

With this running showing memory usage by emby server and logging it also to a text csv file, now re-launch emby server so we would have logs from the beginning

When the issue arises (note logs get purged after 3 days), download the emby server logs and stop the memory usage logging script and attach the csv file and the emby server logs (covering all logs from launch up to time of crash/oom kill)

 

[Luke 42077]

@chunk1970

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

How to Report a Problem

Thanks!

 

[Luke 42077]

@chunk1970?

[chunk1970 4]

KillerNas_emby_memory_log_2025-12-02.csv

Apologies of the delay in responding.

Embyserver log in debug mode and the memory log attached.

 

Many Thanks,

Edited by sa2000 to remove raw unsantized log

Edited December 2, 2025 by sa2000

[Luke 42077]

@chunk1970Hi, can you please attach the emby server log in it's original plain text format? Thanks !

[sa2000 674]

@LukeI will forward to you. i removed it because it had api keys

[sa2000 674]

38 minutes ago, chunk1970 said:

Embyserver log in debug mode and the memory log attached.

The crash is for some massive number of character - the only clue we have is that it may be to do with the amount of data to write to the nfo for 

/ZFS3/TVShows/Terra Nova/Terra.Nova.S01E12E13.avi Could I suggest removing Terra Nova from your filesystem - move it out of that path and see if the server runs ok and then can investigate that 2025-12-02 20:13:25.018 Debug App: EpisodeNfoProvider reports change to 7086 - /ZFS3/TVShows/Terra Nova/Terra.Nova.S01E12E13.avi 2025-12-02 20:13:25.018 Debug SqliteItemRepository: GetitemById Season 28290 Season 1 2025-12-02 20:13:25.019 Debug App: Running EpisodeNfoProvider for /ZFS3/TVShows/Terra Nova/Terra.Nova.S01E12E13.avi 2025-12-02 20:13:31.887 Debug App: Running TvdbEpisodeProvider for /ZFS3/TVShows/Terra Nova/Terra.Nova.S01E12E13.avi 2025-12-02 20:13:31.891 Debug App: TvdbEpisodeProvider returned no metadata for /ZFS3/TVShows/Terra Nova/Terra.Nova.S01E12E13.avi 2025-12-02 20:13:31.891 Debug App: Running MovieDbEpisodeProvider for /ZFS3/TVShows/Terra Nova/Terra.Nova.S01E12E13.avi 2025-12-02 20:13:31.893 Info HttpClient: GET https://api.themoviedb.org/3/tv/32754/season/1/episode/12?api_key=xxxxxxxx&append_to_response=images,external_ids,credits,videos&language=en-GB&include_image_language=en-GB,null 2025-12-02 20:13:31.978 Info HttpClient: Http response 404 from https://api.themoviedb.org/3/tv/32754/season/1/episode/12?api_key=‌xxxxxxxxx‌&append_to_response=images,external_ids,credits,videos&language=en-GB&include_image_language=en-GB,null after 84ms 2025-12-02 20:13:31.979 Debug App: MovieDbEpisodeProvider returned no metadata for /ZFS3/TVShows/Terra Nova/Terra.Nova.S01E12E13.avi 2025-12-02 20:13:31.979 Debug App: Running OmdbItemProvider for /ZFS3/TVShows/Terra Nova/Terra.Nova.S01E12E13.avi 2025-12-02 20:13:32.005 Error SqliteItemRepository: Error saving items *** Error Report *** Version: 4.9.1.90 Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb Operating system: Linux version 6.12.57+deb13-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian OS/Process: x64/x64 Framework: .NET 8.0.11 Runtime: opt/emby-server/system/System.Private.CoreLib.dll Processor count: 8 Data path: /var/lib/emby Application path: /opt/emby-server/system System.ArgumentOutOfRangeException: System.ArgumentOutOfRangeException: Too many characters. The resulting number of bytes is larger than what can be returned as an int. (Parameter 'charCount') at System.Text.UTF8Encoding.UTF8EncodingSealed.<GetMaxByteCount>g__ThrowArgumentException|7_0(Int32 charCount) at SQLitePCLEx.utf8z.FromString(ReadOnlySpan`1 s) at SQLitePCLEx.raw.sqlite3_bind_text(sqlite3_stmt stmt, Int32 index, String val) at Emby.Sqlite.SqliteExtensions.TryBind(IStatement statement, Int32 index, String value) at Emby.Server.Implementations.Data.SqliteItemRepository.SaveItem(IDatabaseConnection db, BaseItem item, Int64 userDataKeyId, IStatement insertItemStatement, IStatement updateItemStatement) at Emby.Server.Implementations.Data.SqliteItemRepository.SaveItemsInTranscation(IDatabaseConnection db, List`1 items, MetadataRefreshOptions metadataRefreshOptions) at Emby.Server.Implementations.Data.SqliteItemRepository.SaveItems(List`1 items, MetadataRefreshOptions metadataRefreshOptions, Action`1 afterSave, Boolean disableForeignKeys, CancellationToken cancellationToken) Source: System.Private.CoreLib TargetSite: Void <GetMaxByteCount>g__ThrowArgumentException|7_0(Int32)

[sa2000 674]

By the way - the memory logging appears to have stopped at 2025-12-02 20:10:30 which was before the launch of emby server at 20:12:02 for the issue that was being reproduced.

The script should detect change of PID number - so not sure if you stopped it at 20:10:30

Anyway, it is not needed for this issue now

 

[chunk1970 4]

Thanks All,

For some reason that .nfo file was 840MB.

Deleted / Refreshed and all good now.

Much appreciated all

[Luke 42077]

Thanks for following up.