mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
Intermittent 'database is locked', webui/jellyfin becomes unresponsive #6819
Reference in New Issue
Block a user
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 @SLemons13 on GitHub (Mar 11, 2025).
Description of the bug
Intermittent 'database is locked' errors despite following all troubleshooting steps found on github issues/forums. Very similar behavior to issue #12312, though it does not seem to be caused by library scans. I see an error about the database being locked in the logs, the web ui becomes unresponsive, and memory usage will begin to balloon until the container is stopped. Has been happening for that last couple months, I can't find a correlation to any particular task/action which causes it. Have been dealing with this from version 10.10.3-10.10.6
Reproduction steps
What is the current bug behavior?
I see an error about the database being locked in the logs, the web ui becomes unresponsive, and memory usage will begin to balloon until the container is stopped.
What is the expected correct behavior?
No stability issues
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.10.6
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
I tried setting JELLYFIN_SQLITE__disableSecondLevelCache=true, changed parallel encoding and library scan instances to 1, as well as set trickplay threads to 1. Also tried allocating fewer cores to the container. I am not sure what causes this behavior. There are lots of MediaSegment DB commands as seen in the debug logs, and throughout the debug logs the DB response time can be as high as 10,000ms. This seems incredibly slow on an SSD. I am not sure if the slow DB is caused by Jellyfin having some other error, or if the DB being overwhelmed is causing the unresponsiveness.
System specs:
CPU: 64 core Epyc 7702
RAM: 512GB
Storage: RAID 1 WD Ultrastar DC SN200 3.2TB PCIe SSDs
@felix920506 commented on GitHub (Mar 11, 2025):
Please remove playback reporting plugin and see if issue persists.
@SLemons13 commented on GitHub (Mar 11, 2025):
Oh it seems that was it. The webui in general is 5x faster now without playback reporting. The log still has a database lock error every few minutes, though no performance issues coupled with them. Is these errors normal and data is written when the DB unlocks?
@SLemons13 commented on GitHub (Mar 13, 2025):
The issue still persists without the playback reporting plugin. Memory and CPU usage had spiked around 9pm when JF became unresponsive. It had the CPU cores allocated pinned at 100%. That time coincides with when I set a task for Trickplay generation to start. Not sure if that is related. Memory usage seems to hit 12GB every time this happens. Here is the log
log_20250312.log
@SLemons13 commented on GitHub (Mar 13, 2025):
Happened again. Got the debug logs along with memory usage. The debug logs start at 05:20:12.634.
log_20250313.log
@telnetdoogie commented on GitHub (Mar 29, 2025):
@SLemons13 I recently moved some containers into a VM and was mounting the folders for docker via NFS. I saw a LOT of this behavior with SQLite DBs in my docker containers and apparently DB locks and problems are pretty typical in SQLite when the file is not on a local physical device. Do you happen to be accessing the jellyfin data folder over the network (SMB / NFS share)?
I just moved my *arr stacks over to postgres DBs and it has resolved the issue so SQLite DBs over a shared folder is definitely a contributor for similar behavior...
What's the physical location of your volumes in relation to where you're running the container?
@SLemons13 commented on GitHub (Mar 29, 2025):
@telnetdoogie All data and metadata local on a pair of mirrored SSDs. No VMs in this use case, just bare metal TrueNAS and running docker from that.
@SLemons13 commented on GitHub (Apr 2, 2025):
I could have attributed this issue to the wrong cause. This one occurred during a library scan. possibly related to #13708. I copied my data over to an instance running tag 2025021706 and it has been completely stable with way less memory usage. Always hovering around ~750mb.
log_20250401.log
@kambala-decapitator commented on GitHub (Apr 23, 2025):
from time to time I've started observing the media player (I use dedicated app on macOS) taking like a couple of minutes to advance to next song. Today I checked logs when it occurred again and also noticed
database is locked. I think it started after upgrading to v10.10.x (currently running v10.10.5 on Debian 11), don't remember having any issues on v10.9.x.Click to expand log
@JPVenson commented on GitHub (Apr 24, 2025):
Do you run any script that modfies the permissions on the jellyfin directory?
@kambala-decapitator commented on GitHub (Apr 24, 2025):
I don't
@JPVenson commented on GitHub (Apr 24, 2025):
your config folder is located on a local device not on a network share?
@gnattu commented on GitHub (Apr 24, 2025):
I think we have to bring back the old write connection lock to EFCore, at least for the SQLite backend. So that all operations that will write to the database has to wait for the other thread to finish before creating its own connection. If I understand our current EFCore implementation correctly, each a lot of thread will create its own Dbcontext and each context will have its own connection and that will make SQLite unhappy on slower IO or larger database. As long as the current access pattern is not changed I think locked database is unavoidable with SQLite.
@JPVenson commented on GitHub (Apr 24, 2025):
@gnattu there are a lot of conflicting infos out there regarding that. From what i have gathered, our Sqlite does do optimistic concurrent locking and retries when it observes other connections writing in parallel. From my testing pooling actually increases the number of locks on Windows but reduces them on linux so thats that and even with our previous locking, we had the same issue.
Overall as we have WAL enabled this should not happen in the first place but all points for me towards either and issue with sqlitepcl or an general issue with some external factors. The only real possibility would be if we actually work on a DbContext in parallel as that would 100% cause this issue, but i am fairly certain we do not.
Implementing to test it should be rather easy to do as we now exclusively go over EFCore and locking the SaveChanges method should do the trick if somebody wants to try.
@kambala-decapitator commented on GitHub (Apr 24, 2025):
yes, local device. Media files reside on a usb attached HDD.
if it matters, local device's internal HDD is quite old (and not that fast).
@SLemons13 commented on GitHub (Apr 24, 2025):
I had convinced myself it was some database issue on my end since my instance has been running for a little over 2 years, so I decided to start fresh. Set up a fresh instance on the same system and switched over to it. Exact same behavior is occurring on the fresh install.
@JPVenson commented on GitHub (May 6, 2025):
do you feel confident enough to compile a version of jellyfin yourself to test someting?
if so try compiling https://github.com/jellyfin/jellyfin/pull/14047 and setting the setting in
database.xml<LockingBehavior>Pessimistic</LockingBehavior>and see if that helps with the database locked issues@JPVenson commented on GitHub (Jul 2, 2025):
Issue will be fixed in 10.11 and can be tested in RC2 though various methods. Follow the release docs to see more.
@SLemons13 commented on GitHub (Oct 10, 2025):
This issue still persists on 10.11 RC8 for me unfortunately, albeit a bit less frequent now. Tried both optimistic and pessimistic locking behaviors.
@gnattu commented on GitHub (Oct 10, 2025):
If even a pessimistic locking can’t resolve this issue for you, you might have to wait until a genuine alternative DBMS like pgsql to be supported. I highly doubt that your database is approaching the limit of what SQLite can handle with current Jellyfin database schema and access pattern
@kambala-decapitator commented on GitHub (Oct 10, 2025):
Haven't experienced it any more on v10.10.5
@SLemons13 commented on GitHub (Oct 10, 2025):
My library is larger but I don't think it's beyond what some other user have. jellyfin.db is 1.4GB at the moment. The crashes happens with 3+ concurrent streams and/or a library scan. Both at the same time makes it very likely. Something like trickplay generation running as well will make it even more frequent. I don't know what I can try to mitigate this. I tried putting the DB onto PCIe based Optane drives to minimize any read/write latency and it made no difference.
@JPVenson commented on GitHub (Oct 10, 2025):
try setting the parallel scan task limit to something more reasonable like 1/2 your core count. If you have 4 or less cores set it to 1
@SLemons13 commented on GitHub (Oct 10, 2025):
Parallel scan task limit and parallel image encoding limit have been set to 1 since this issue was opened unfortunately.
@JPVenson commented on GitHub (Oct 10, 2025):
If that is the case and you are running 10.11RC8 with your config on a local device (Not a network share) there seems to be something fundamentally at issue with your setup that interfears with sqlites operation but i cannot tell you what. the Parallel scan task limit = 1 disables all concurrency and the Strict locking behavor essentially does that on a global level.
@SLemons13 commented on GitHub (Oct 15, 2025):
Figured it out. I switched from TrueNAS to Rocky linux and the problem continued after re-importing my zpools. I then tried reformatting the drives to XFS and moved the JF data back on. Works fine now using NoLock on XFS. Seems like EFCore didn't like ZFS. I had even disabled filesystem compression and checksums, enabled write caching, and set the block size to match sqlite which should have sped up ZFS quite a bit. Haven't seen a database lock error in 3 days now. They do still happen when trying to use the new database backup function but I'll live with it.
@JPVenson commented on GitHub (Oct 15, 2025):
that is not related to efcore. you should never run sqlite on the ZFS filesystem. That is a known limitation
@SLemons13 commented on GitHub (Oct 15, 2025):
Since TrueNAS only supports ZFS, and Jellyfin is using sqlite which you're saying should never be run on ZFS, should the TrueNAS SCALE installation documentation be updated to warn users that there may be inherent unavoidable performance issues due to using ZFS?
@darkpixel commented on GitHub (Dec 16, 2025):
@JPVenson I did a bit of Googling and only came up with one link that looked relevant to "Don't use sqlite on ZFS" and it was a dead/gone ycombinator link. Can you provide any more information? I have a handful of sqlite databases running on ZFS with no issue....except for this intermittent database issue with Jellyfin.
@darkpixel commented on GitHub (Dec 18, 2025):
Finally found a bit more info in bug #15101