Repository navigation
SQLITE3_DISABLE_EMBY_FANOUT_REWRITE #3
Description
Activity
observability recorded a homepage query using the new WithOuterItemIds/resume fan-out rewrite: 564,448 ms — about 9 minutes 24 seconds.
The logs also explicitly show emby_fts_rewrite event=rewrite_applied mode=fanout+resume. That duration fully explains the endless homepage spinner while the lighter dashboard and administrative endpoints continue working.
And to be sure, you have run the optimize script first? It has a few indexes for both Plex & Emby that are required for the rewrites to function properly.
Nope haha woops
Alright, do a pass with the optimize script so those indexes get added then check for the slowness again. Let me know if it's still there.
Additional data point from a large Emby deployment:
- Mod:
2026.07.20-r2(linux/amd64, x86-64-v3 artifact) - Emby:
4.9.3.0on LSIO - Rewrite setting at the time:
SQLITE3_DISABLE_EMBY_FTS_REWRITE=0 - The host-side
optimize_media_servers.shhad not been run. I confirmed that theidx_dshadow_*Emby indexes declared by that script are absent. The normal EmbyidxItemLinks2_*andidxAncestorIds2_*indexes are present.
Observed sequence from the mod's observability logs:
2026-07-20T21:10:30.384Z emby_fts_rewrite event=rewrite_applied target=emby mode=fanout+links_search source_corr=f944ca4a95def1dc corr=579299e6eb692360 2026-07-20T21:15:18.752Z slow_query db="/config/data/library.db" elapsed_ms=288368.000 sql_expanded_hash=f639985627a270daThe expanded statement was the rewritten nested
EXISTSform overItemLinks2andAncestorIds2, ending withGROUP BY A.Type. The two ancestor IDs represented two ordinary media-folder rows; paths and user data omitted.Impact was broader than the initiating browse/search request: while this statement ran, unrelated playback-info responses completed in 38–117 seconds and HLS/direct-stream requests accumulated. Several requests completed together as soon as the 288-second query returned. There were no
SQLITE_BUSY/database-lock errors, database integrity errors, host I/O errors, or memory pressure.Workaround applied:
SQLITE3_DISABLE_EMBY_FTS_REWRITE=1After recreating Emby, the same
r2SQLite build remained loaded, rewrite events stopped, and no new slow-query events appeared during the initial live-traffic observation. Public health requests returned in roughly 0.5–1.2 ms.This likely reinforces the existing prerequisite noted above: the fanout rewrites are unsafe on a large library before the optimization script/index pass. It may be worth making the mod fail closed (or emit a prominent warning and skip fanout rewrites) when the required
idx_dshadow_*indexes are absent.- Mod:
I can confirm it is still there as well
There's already a few fail-open checks for some of the more problematic rewrites but I guess they can be improved. Don't expect it anytime soon however.
This project is mostly meant for those who use both the optimization script (for indexes & general DB maintenance) and the rewrites together, not really either or.
Reacted by SS
I have deployed an Emby server with this added, but since then I have found that the homescreen will just spin on long transactions never letting the homepage load. This will usually happen when items are being scanned in, though I cannot verify if that is the trigger for this.