mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-23 23:20:51 +01:00
SQLite core dump on systems without SSE4.1 #7523
Labels
No labels
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
EFjellyfin.db
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/jellyfin#7523
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gokberkkocak on GitHub (Oct 23, 2025).
Description of the bug
After upgrading from 10.10.7 to 10.11.0, I realised my jellyfin almost immediately crashes with a core dump. I thought this might be related to db migration and tried on a clean install as well and it's still happening. It happens when a library scans starts I believe. The jellyfin process starts dumping core after staying running for a while.
I checked
dmesgand there I can see some entries related tolibe_sql3:Coredumps also indicate that they are coming from
libe_sqlite3. One of the coredumps:coredump.txt
Also a full run log:
log.txt
Reproduction steps
What is the current bug behavior?
Crash
What is the expected correct behavior?
Not to crash
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
No response
Specify the build version
10.11.0
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
jellyfin-serverpackage not git or manual install methods. The specific package isjellyfin-server-10.11.0-1trap invalid opcodemight indicate that the CPU is not supporting an instructionlibe_sqlite3is trying to execute. My CPU is indeed old on this headless machine (Intel(R) Atom(TM) N2800 (4) @ 1.86 GHz) and does not support stuff likeSSE4instructions. As long as,libe_sqlite3is compiled with x86_64 (not x86_64-v2 or higher) or, has proper architecture detection, this shouldn't be a problem. Hope this brings us closer to find an answer.@mkortstiege commented on GitHub (Oct 23, 2025):
Same issue here on Debian 12 using official packages.
@frafram commented on GitHub (Oct 23, 2025):
Same issue on Debian 13 / Intel(R) Atom(TM) CPU N2800.
@amkay commented on GitHub (Oct 24, 2025):
Same here with the official Docker image running on an old AMD Athlon 64 X2 5600+.
@domq commented on GitHub (Oct 25, 2025):
Upon closer inspection on my Ubuntu Noble,
/usr/lib/jellyfin/bin/libe_sqlite3.sois an optimized build that uses theblendvpdinstruction in a handful of places. That instruction is part of SSE4.1 and doesn't exist on my Intel(R) Atom(TM) CPU D510 and I assume, CPUs of other people in this thread.objdump -d /usr/lib/jellyfin/bin/libe_sqlite3.so | awk '/^([0-9a-f]+) <.*>:/ {func=$0} /blendvpd/ {print func}'sudo apt install cpuid; cpuid | grep 'SSE4.1'SSE4.1 extensions = false SSE4.1 extensions = false SSE4.1 extensions = false SSE4.1 extensions = falseA possibly important precision is that in my case, the Jellyfin server does not crash at startup, but rather at some random point while clicking my way through Swiftfin on my Apple TV. I assume that thes sqlite3 code paths in question are sufficiently off-the-beaten-path, (and my CPU sufficiently vintage) that the issue could have escaped detection until now.
@uihp commented on GitHub (Oct 25, 2025):
My Jellyfin started refusing connection after I enter
/web/#/details?id=page, then got503 Service Unavailablestatus code, the response text indicates Jellyfin just restarted (butdocker inspectshows the container didn't restart), I think it may be related to this issueMy CPU is
Intel(R) Celeron(R) CPU E3500 @ 2.70GHz, running on OpenMediaVault with docker composebtw, because of the database change, I failed to return to the 10.10.7, I decided to start from scratch for the workaround and to wait for fix update
@uihp commented on GitHub (Oct 25, 2025):
good inspection, I'm trying to replace this with one from the old version to see if my problem is caused by this
@uihp commented on GitHub (Oct 25, 2025):
well, I replaced
/usr/lib/jellyfin/bin/libe_sqlite3.sowith the one in10.10.7and the problem disappered. It can be the temporary workaround. I don't need to start from scratch at least@alesxx commented on GitHub (Oct 26, 2025):
How does one do that? Do i need to build a custom docker image or can it be replaced at runtime?
@alesxx commented on GitHub (Oct 26, 2025):
Ok, I have managed to build a custom image that copies the
libe_sqlite3.sofrom the10.10.7version, as @uihp suggested.This is my
Dockerfile:And run the build with the following command:
After a few minutes of testing, everything seems to work (even stuff that was previously broken - such as scanning the library).
@TiagoMuek commented on GitHub (Oct 27, 2025):
Did the same process as @uihp and @alesxx suggested and it resolved all my issues related to the library
My processor is a AMD Turion(tm) II Neo N54L Dual-Core Processor and it also doesnt support the SSE 4.1 extensions
@Shadowghost commented on GitHub (Oct 27, 2025):
I checked the changes in the upstream libraries used by EF Core and found only one change that might be the reason of this:
In sqlite 3.45.0 they enabled an optimization flag by default and starting EF Core 9 (used by Jellyfin 10.11) SQLitePCL 2.1.10 is the minimum required version which ships 3.46.1
IMHO it's very likely the cause of your issues and sadly we can't do anything about this. If you want to check if my assumption is correct, you can download an older version here (extract and copy the
libe_sqlite3.sofrom the correct folder insideruntimes) - the last version with pre-3.45 sqlite is 2.1.7.@alesxx commented on GitHub (Oct 27, 2025):
There are a lot of older CPUs that don't have SSE 4.1 extensions and it would be a real shame if this cannot be resolved.
Couldn't this optimization flag be disabled somehow? Or maybe the upstream library simply checks for the existance of SSE 4.1 extensions before using them.
@Echupk commented on GitHub (Oct 27, 2025):
How to do this on a compose file ?
I'm doing mine with portainer and stack method like this:
"services:
jellyfin:
image: ghcr.io/linuxserver/jellyfin:latest
container_name: jellyfin-new
environment:
- PUID=1001
- PGID=100
- TZ=Europe/Paris
volumes: etc."
@Shadowghost commented on GitHub (Oct 27, 2025):
If we can confirm that this is indeed caused by the upgraded sqlite version, an issue can be filed upstream.
But since this is a change in the sqlite defaults, we'd need to have compelling arguments for upstream to explicitly disable the compile flag when building. Chances for that are frankly slim.
@gokberkkocak commented on GitHub (Oct 27, 2025):
Thanks for the detailed response. I can see that sqlite3 3.45 specific change can be the reason
SSE4.1instructions to be present for that sqlite3 build. However, if we putSQLitePCLaside, my same old hardware is running native sqlite3.50.4on all sorts of different programs and everything is functioning fine. I don't think sqlite3 would have backwards incompatibility problems with older hardware. So I think the issue is the SQLitePCL's sqlite3 build in this case.I'm not a dotnet person but looking at the dependencies of SQLitePCL, it is using its their own 3rd party build system SourceGear provider builds and that is where the sqlite3 is probably getting compiled at x86_64-v2+ including SSE4.1 instructions. We should elevate the issue over to SQLitePCL. I will try to do so if/when I get the time but if anyone wants to go ahead, please by all means.
@alesxx commented on GitHub (Oct 27, 2025):
One very important distinction is that you are using the docker images from
linuxserverand I am using the officialjellyfinimage.Important: you cannot simply switch from
linuxservertojellyfinimages, since the configuration is different and it will surely break if you leave everything else as-is.You will have to modify my
Dockerfileso that it uses the correct images (both the:latestand the:10.10.7versions). Be sure to check the absolute file path for thelibe_sqlite3.so, as it may be in a different location.After that, If you build the image with the command from my post, it will create an image with the name
jellyfin-fixedin your local docker image repository, which means that you simply change the image that will be used in yourdocker-compose.ymlfilefrom:
to:
@gokberkkocak commented on GitHub (Oct 27, 2025):
Looking at arch linux PKGBUILD for sqlite3 3.50.4 (that I'm running natively on the old hardware) - I cannot see that the flag is being disabled and I run this version of sqlite3 without issues. Let me know if my understanding is flawed in any place.
There is the possibility of this regression being present at 3.45 and fixed later on at some point. I will look into sqlite3 in-between change logs to see something catches the eye.
@Shadowghost commented on GitHub (Oct 27, 2025):
@gokberkkocak it's possible that the sqlite makefile properly handles this case but .NET uses pre-build libraries, so if those are build on a system supporting SSE 4.1 (which is very likely) the resulting artifacts would require it.
@gokberkkocak commented on GitHub (Oct 27, 2025):
Looking at jellyfin 10.11.0 provided
libe_sqlite3.so:gives:
this indicates the presence of the SSE4.1 instructions are present - credits to @domq.
The same appears on
libe_sqlite3.sodistributed withSQLitePCLRawnuget package of 2.1.11.Also gives:
Later the project switches towards SourceGear.sqlite3 that compiles towards 3.50.4:
and same result:
So the fault actually does not directly lie on SourceGear only.
Additionally, I know it's kind of apples to oranges comparison but let's apply the same analysis on native
sqlite3version 3.50.4 that gets used system-wide vialibsqlite3.so.No result.
To me, this smells like
SQLitePCL's doing via its distributed binaries.@Shadowghost commented on GitHub (Oct 27, 2025):
@gokberkkocak feel free to file an issue with the upstream library and your findings! I had a quick look and couldn't really figure out how their build infra works.
@alesxx commented on GitHub (Oct 31, 2025):
Has anyone tried the new Jellyfin version (10.11.1) with the
libe_sqlite3.sofrom10.10.7?Not sure it I should try and patch the new version or if I should wait for the proper fix, which may take a while...
@TiagoMuek commented on GitHub (Oct 31, 2025):
I am running the 10.11.1 with the sqlite from 10.10.7 using the process to build the docker image discussed above
@manf0001 commented on GitHub (Nov 1, 2025):
I am running 10.11.1 on a TrueNAS scale setup with an Intel Atom C3758 CPU. Did you find that replacing the libe-sqlite3.so with the one from 10.10.7 also speed up library scans? Everytime I do a library scan when adding something new, it can take like 45 -60 mins and the system is almost unusable.. where my self or other users can't even navigate or select something to play until the scan is finished running.
@bmacao commented on GitHub (Nov 2, 2025):
Can anyone provide the libe_sqlite3.so from 10.10.7 to anyone running jellyfin outside docker ?
Unable to use until a fix is available :(
@gokberkkocak commented on GitHub (Nov 4, 2025):
You can grab it from the 10.10.7 release yourself:
@bmacao commented on GitHub (Nov 5, 2025):
Thank you.
Best Regards
@phmg701 commented on GitHub (Nov 21, 2025):
Hello, coming from #15000 and read everything, thanks guys!
You guys are all on Linux, but I am on Windows (please be kind) and I would like to test replacing 10.11.3 DLLs with the ones from 10.10.7, although being on a system sporting an i5-12400, equipped with SSE up to 4.2
Now comes the funny part: which DLL is it?
10.10.7 (dir sqlite.dll):
10.11.3 (dir sqlite.dll):
My guess is e_sqlite3.dll
Thanks!
@ggibby commented on GitHub (Dec 3, 2025):
A friendly Redditor referred me here since I'm having similar issues on older Windows hardware.
Where can I find the 10.10.x.x installs for my system?
@jeffbrl commented on GitHub (Dec 3, 2025):
I am not running jellyfin on Windows but I suspect you can download the previous version as you can with linux. In the conversation history, you can see that the file is
e_sqlite3.dll.https://github.com/jellyfin/jellyfin-server-windows/releases