mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-07-16 05:43:54 +03:00
RC2 LimitedConcurrencyLibraryScheduler 'database is locked' #7133
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 @ptr727 on GitHub (Jul 1, 2025).
Description of the bug
Installed fresh new JF docker RC2, added movie library, observe lots of 'database is locked' errors on log.
E.g.
Reproduction steps
docker.io/jellyfin/jellyfin:10.11.0-rc2.What is the current bug behavior?
DB locked errors in logs.
What is the expected correct behavior?
No DB errors.
Jellyfin Server version
Master
Specify commit id
No response
Specify unstable release number
RC2
Specify version number
No response
Specify the build version
10.11.0-rc2
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
No response
Additional information
System is:
Supermicro H13SSL-N
AMD EPYC Genoa 9334 QS (32 x core, 64 x thread)
384GB RAM
ZFS on SSD's for config and cache, ZFS on spinning disks for media.
log_20250630.log
@felix920506 commented on GitHub (Jul 1, 2025):
What database locking mode do you have set?
@JPVenson commented on GitHub (Jul 1, 2025):
also please fill out the full system spec section of the bug report.
Did you read the section about adjusting the parallel limit in our release docs? if not, please do so.
@ptr727 commented on GitHub (Jul 1, 2025):
I don't know, I installed clean and ran, I did not know that I need to change settings before I can use JF?
I'll update with more details.
No, I did not know that I had to make changes before it would work.
I found the released notes, I see it mentions something about library scan limits, and new DB options, but not the actual options.
Please point me to said options?
P.s. as a vanilla user I do kinda expect the out of the box new install defaults to just work.
@JPVenson commented on GitHub (Jul 1, 2025):
i would too. Realitiy is that we still dont know why only for some users this is an issue, only 2/60 of our team members report this issue but we still dont understand why this is happening for those.
For the mayority of users adapting this setting will not be nessesary, but its the correct one to help with that issue.
I am still writing the offical docs for that db lock option and will update the release doc soon.
@ptr727 commented on GitHub (Jul 1, 2025):
Ok, still don't know what "this setting" is, happy to test it out when you want it tested.
In the general/performance section all settings are default / blank.
Btw, I added the system info, note the large number of CPU cores and fast storage, are there any options that default based on CPU core count?
@JPVenson commented on GitHub (Jul 1, 2025):
ok very quick detour, i will elaborate in chat if you want.
The "Parallel scan task limit" in <10.11 had a bug that lead to runaway parallism based on core counts. with our new architecture that overwhelmed the sqlite implementation and cause this locking issue. The new one works far better but can still overwhelm the database.
Thats where the locking setting comes into play. I added a new section in our release docs explaining that.
@ptr727 commented on GitHub (Jul 1, 2025):
I repeated a fresh setup, same procedure, add one library, default options, but I changed database.xml to
<LockingBehavior>Optimistic</LockingBehavior>.Instead of exceptions for locked DB being logged, I now get lots of:
@JPVenson commented on GitHub (Jul 1, 2025):
with your CPU i would also highly recommend setting the parallel scan limit to something reasonable like 6 or 7.
Those log messages are good, they tell you its working
@ptr727 commented on GitHub (Jul 1, 2025):
What is the default?
@theguymadmax commented on GitHub (Jul 1, 2025):
Dashboard -> General - Parallel library scan tasks limit:
"Maximum number of parallel tasks during library scans. Setting this to 0 will choose a limit based on your systems core count. WARNING: Setting this number too high may cause issues with network file systems; if you encounter problems lower this number."
So in your case you're running 32 parallel scan tasks.
From the release notes:
"For Users that had previously issues with DB lockups, we recommend choosing a value that is below your number of cores available and adjust from there based on your own testing."
@ptr727 commented on GitHub (Jul 2, 2025):
I see, that seems like maybe not the best choice, maybe default to a more conservative and reliable value like max of cores or 4.
And if Optimistic is the more reliable DB choice, then maybe that could also be the default.
Users could always go and change things, but out of the box defaults in my humble opinion should favor reliability.
@JPVenson commented on GitHub (Jul 2, 2025):
Optimistic can cause replay issues and very low counts will impact the scan performance significantly. Worsining it for everyone is a bad solution too if just 2/60 or so actually need to change it. Worsening everything for 58 out of 60 people is the wrong way.
Those small numbers of installs that experience issues will either read the docs or find help in our chat and will be able to solve this issue then. For the 10.11 release we will expand our jellyfin.org/docs with those informations.
@ptr727 commented on GitHub (Jul 2, 2025):
Other than "parallel library scan tasks limit" and "parallel image encoding limit", under the performance section, are the other places I have to change?
E.g. I see in system.xml
LibraryMetadataRefreshConcurrencyshould I change that, where is it in the UI?P.s. looked in source, could not find anywhere this is used, just declared in the XML schema?