[BUG] Intermittent SQLite lock on segments.db after scan (Emby 4.9.5.0 / TheIntroDB 1.0.8.2) #32

Bug description

The plugin intermittently reported SQLite Busy: database is locked errors while persisting chapter markers during normal scheduled scanning. Emby remained running, but plugin write operations failed. A graceful Emby restart released the lock and normal operation resumed.

This is separate from the closed #22 Preview/bounded-scan work: the failure described here occurred on the normal scan and marker-persistence path, not during Preview.

Environment

• Host: Linux Docker host based on iStoreOS/OpenWrt
• Filesystem: local ext4 (not NFS/SMB)
• Emby Server: 4.9.5.0
• TheIntroDB plugin: 1.0.8.2
• Database: TheIntroDB segments.db
• All timestamps below are local time (UTC+08:00)

Observed behavior

During one incident on 2026-08-21:

• Around 16:45, a scan log recorded 61 lookups and 61 lock errors.
• Around 17:15, a scan log recorded 95 lookups and 95 lock errors.
• Around 17:45, another scan recorded 51 lock errors.
• After the scan had finished, the database still appeared to have a read lock.
• lsof//proc/locks identified the Emby process as holding a POSIX advisory read lock on segments.db (the relevant process was Emby's server process; one observed file descriptor was FD 364).
• Stopping Emby gracefully removed the database lock immediately.
• PRAGMA integrity_check returned ok; there was no evidence of database corruption.
• No external batch rotator or other independent writer was running at the time.

After restarting Emby:

• The database passed PRAGMA integrity_check again.
• The normal plugin configuration was restored.
• A minimal one-item test completed successfully with zero database is locked errors. The API returned NotFound, which is a separate upstream data-coverage result, not a local SQLite failure.
• At a later read-only check, Emby still had normal open file handles for the database, but the current database inode had no matching entry in /proc/locks and no new lock errors had appeared after the restart.

Reproduction status

The problem has been observed in production workload, but I do not currently have a stable minimal reproduction. Repeating a minimal test after the restart did not reproduce the lock.

The issue should therefore be considered intermittent / previously observed, currently not reliably reproducible.

Expected behavior

All read sessions, repositories, and SQLite transactions opened by a scan or marker-persistence operation should be released when the operation completes, so later plugin writes can proceed without requiring an Emby restart.

Actual behavior

In the incident above, an Emby process retained a POSIX advisory read lock on the plugin database long after the scan activity that preceded the errors. Subsequent plugin persistence operations failed with database is locked until Emby was restarted.

Suspected area (not confirmed)

A code review suggests checking the lifetime of the repository/read-only session used by the scan task and marker-persistence path. In particular:

• whether a long-lived repository or SQLite read transaction survives task completion;
• whether all read sessions are disposed on every success, error, cancellation, and early-return path;
• whether independent repository-local locks can coordinate correctly when multiple plugin entry points access the same SQLite database;
• whether the SQLite connection/mutex configuration can allow a leaked read session to block later writes.

This is a hypothesis, not a confirmed root cause.

Requested investigation

Please check the repository/session disposal and add a regression test covering concurrent or sequential scan reads followed by marker/history writes. It would also be useful to add diagnostic logging that identifies when a database read session is opened and released, without logging credentials or private media URLs.

Sanitized logs and the lock timeline can be provided if needed. No credentials, API keys, tokens, private URLs, or full authenticated logs are included in this report.