[PR #4541] [CLOSED] Optimize database scheduled task #10151

New Issue

OVERLORD · 2026-02-07T06:14:56+03:00

OVERLORD commented

2026-02-07 06:14:56 +03:00

📋 Pull Request Information

Original PR: https://github.com/jellyfin/jellyfin/pull/4541
Author: @ferferga
Created: 11/22/2020
Status: ❌ Closed

Base: master ← Head: vacuum-task

📝 Commits (2)

cfe00da Create "OptimizeDatabase" scheduled task
65a35ee Remove VACUUM at boot time

📊 Changes

4 files changed (+106 additions, -5 deletions)

View changed files

📝 Emby.Server.Implementations/Data/BaseSqliteRepository.cs (+0 -3)
📝 Emby.Server.Implementations/Localization/Core/en-US.json (+3 -1)
📝 Emby.Server.Implementations/Localization/Core/es.json (+3 -1)
➕ Emby.Server.Implementations/ScheduledTasks/Tasks/OptimizeDatabase.cs (+100 -0)

📄 Description

Before, we ran VACUUM at each start (#1455). Although it solved the problem partially, it isn't the best solution for long-running instances. It also freezes the boot process for a while and it can hang it altogether, in case the filesystem is running out of space.

With a scheduled task, this can be ran periodically at user demand, while also keeping server running in case of any error.

I tested this while running scanning tasks and browsing the library with multiple users and I've never hit any concurrency issue

Additional details

Although this might pose a concurrency problem, our current journaling mode and the fact that library is still in it's own database should not cause any issues in case we want this for 10.7.
In addition to this, I've been testing vacuuming in different connections with my pi-hole instance multiple times this week:

I replicated the pragmas used by Jellyfin.
Ran a DNS benchmark (so database got plenty of activity)
Connected using sqlite3 cli and issued VACUUM command.

I tried multiple combinations of this and nver had a single issue. I read also a lot of the documentation and I got to the conclusion that, as long as there's one connection that handles transactions and one connection that runs vacuum without a transaction, everything is fine atomic-wise. Anyway, I'm leaving library.db as it's going to be deprecated sooner than later and it's better to stay in the safe side.

I wanted to use EFCore for this but database context is not accesible outside Jellyfin namespace. Anyway, I don't think doing it directly with SQLitePCL is such a bad idea as, once support for other backends is added, we would need to set a check so this trigger only works in SQLite backends. With SQLitePCL we have this done already.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/jellyfin/jellyfin/pull/4541 **Author:** [@ferferga](https://github.com/ferferga) **Created:** 11/22/2020 **Status:** ❌ Closed **Base:** `master` ← **Head:** `vacuum-task` --- ### 📝 Commits (2) - [`cfe00da`](https://github.com/jellyfin/jellyfin/commit/cfe00da863156c450934dd0b59231b18f2734b85) Create "OptimizeDatabase" scheduled task - [`65a35ee`](https://github.com/jellyfin/jellyfin/commit/65a35ee074ca2c34ed95ccb2b90e3c17191ff425) Remove VACUUM at boot time ### 📊 Changes **4 files changed** (+106 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `Emby.Server.Implementations/Data/BaseSqliteRepository.cs` (+0 -3) 📝 `Emby.Server.Implementations/Localization/Core/en-US.json` (+3 -1) 📝 `Emby.Server.Implementations/Localization/Core/es.json` (+3 -1) ➕ `Emby.Server.Implementations/ScheduledTasks/Tasks/OptimizeDatabase.cs` (+100 -0) </details> ### 📄 Description Before, we ran VACUUM at each start (#1455). Although it solved the problem partially, it isn't the best solution for long-running instances. It also freezes the boot process for a while and it can hang it altogether, in case the filesystem is running out of space. With a scheduled task, this can be ran periodically at user demand, while also keeping server running in case of any error. **I tested this while running scanning tasks and browsing the library with multiple users and I've never hit any concurrency issue** ### Additional details * Although this might pose a concurrency problem, our current journaling mode and the fact that library is still in it's own database should not cause any issues **in case we want this for 10.7**. * In addition to this, I've been testing vacuuming in different connections with my pi-hole instance multiple times this week: 1. I replicated the pragmas used by Jellyfin. 2. Ran a DNS benchmark (so database got plenty of activity) 3. Connected using ``sqlite3`` cli and issued VACUUM command. I tried multiple combinations of this and **nver had a single issue**. I read also a lot of the documentation and I got to the conclusion that, as long as there's **one connection that handles transactions** and **one connection that runs vacuum without a transaction**, everything is fine atomic-wise. Anyway, **I'm leaving library.db as it's going to be deprecated sooner than later and it's better to stay in the safe side**. * I wanted to use EFCore for this but database context is not accesible outside Jellyfin namespace. Anyway, I don't think doing it directly with SQLitePCL is such a bad idea as, once support for other backends is added, we would need to set a check so this trigger only works in SQLite backends. With SQLitePCL we have this done already. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

OVERLORD added the pull-request label 2026-02-07 06:14:56 +03:00

OVERLORD closed this issue

2026-02-07 06:14:57 +03:00

OVERLORD referenced this issue

2026-02-07 06:54:20 +03:00

[PR #10151] Fix performance loss of QSV HDR tone-mapping on Windows #12353

Sign in to join this conversation.

Branches Tags

master

release-10.11.z

renovate/skiasharp-monorepo

JPVenson-patch-1

renovate/morestachio-5.x

release-10.9.z

openapi-cache

release-10.10.z

explicit-load

explicit-load-v2

feature/entity-framework

only-count-folder-item

fix/ci-workflow-refactor

release-10.8.z

release-10.7.z

EraYaN-add-management-interface

release-10.6.z

release-10.5.z

release-10.4.z

release-10.3.z

release-10.2.z

release-10.1.0

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#10151