All Activity

No idea what went wrong but something prevented it from being downloaded. I've reuploaded it to the catalog as version v5.7.3.0 and it seems to work now. Sorry about it all! This last version has been a bit of a sh*tshow and i hate to have to make people reboot their servers multiple times!

I do not plan on upgrading MB or CPU anytime soon. The gpu you suggested above would probably be something I will look at. I still have room for 2 more drives in current setup. My server is really just for Emby. I would like to set up automation for torrents however, I do not have the time or knowledge for a arr stack yet.

There is a reports plugin that compiles this data for all your movies already. I have found that you can change the default from 100 to all then export to excel and do some excel ju-jitsu. By that I mean using the data filter tool in excel. All that takes 5 minutes vs. trying to develop a script that takes hours or days. Fun if your just trying to learn, but re-inventing the wheel seems a bit much. Just sayin.

@yockerHi! Hope you're doing well. I wanted to check in and see if you might know what’s going on with your plugin. For a little while now, I’ve been constantly getting notifications saying a new version of EmbyIcons was installed and that Emby needs to restart. I’ve restarted Emby several times and even rebooted the entire NAS, but the notification keeps popping up. Any idea what might be causing this or how to fix it?

Any update on this? I am not able to sideload on my GM so I don’t think I have a workaround either

I have a powerful machine and disk, but more importantly, the language chosen in both of those checkboxes says nothing to the sort of what you just said, and both as written is unqualified and as you have written is unqualified. I suspect a top of the line intel i9 is better than "some systems" .... I'd argue, it is better than MOST systems. An RTX5080 is better than most GPUs..... a 500TB+ disk setup with all high end (albiet 7200RPM) disks, is better than avg.... unless someone is using SSD...... is still better than avg..... Again, all language that is unqualified, and again, ****** WITH THE CHECKBOX CHECKED, implies "it might crash ****** not....... that with the checkbox unchecked, it WILL CRASH. Respectuflly, does this explain why I am painting the f*****ed eitherway, and neither toggle is definitive?

This looks interesting, but what I'm not clear on is how to install it on both an Emby and a 2016 Samsung TV. I think it would be good to clarify this on the website. Can someone tell me how to install it on both an Emby and a 2016 smart TV? Do I need a Premiere account to install it?

I ran the query against my instance with api_key and it accepted it. I ran the exact script with my own variable too and it worked, I just changed the api_key name I mentioned. You should be able to manually run a curl with the path looking like this: EDIT: Could be HTTP instead as well, I used "https://path.to.my.emby" for the variable, but "http://ip.address:port" should work too.

I don’t quite understand this point. Watching a movie won’t delete it from the library, or are you filtering the library by unwatched and it is still showing even though it has been watched? Can explain the steps to reproduce and how you have the library folder view/sorting/filtering configured?

It's true this may have been an issue from a previous server version (I've been using Emby for a while). I don't really have a way to test this on a fresh install but even when I manually delete the album containing the "incorrect" artist identification, after a rescan the issue persists. I agree that nailing down the original cause would be hard to do, mostly just throwing this out there. If anything, I am more so interested in how to get Emby to clean up / recognize any incorrect artist identifications

Hi, we are looking into this. Thanks.

Correct. It is server-wide.

Going over your first issue again, it's hard to say what might have happened when this content was first imported into your database. Do you have a way of testing this with a fresh install, or with all new content where the tracks, album and artists have never been in your server database before? Otherwise we're kind of guessing about how it got that way, whether be through some defect in an older server version, various tinkering you might have done, etc.

Hi. And...

Edit: This is the 3rd post explaining how to do and revert the patches. The 2nd post (the one explaining the 2nd fix) got limited or something and is hidden until mods or someone approves it. Emby 4.10.x search-freeze workarounds — how to apply and revert each patch These are the workarounds referenced in my two bug reports (the "recent searches query freezes the server" thread and the "SearchTerm slowness / degenerate planner statistics" thread). They fixed, on our server (~191,000-item library): the whole server freezing for 1–2 minutes whenever someone opened search (100+ s → 16 ms), searches like lord taking a flat ~13 s (→ under 1 s), 1–2-letter searches from TV apps (which search per keystroke) taking 30–50 s and stalling everyone else (→ under 0.3 s). Read before starting At your own risk. These modify the live Emby database (an index and planner statistics) and system.xml. They are workarounds until the Emby team fixes this properly. Make the backups in Step 0 first. Applies to the 4.10.x beta schema (tables MediaItems, UserDatas, AncestorIds2). If those tables don't exist in your library.db, you're on 4.9.x or older — this guide does not apply. Paths below are for the Linux .deb install (/var/lib/emby). Docker: run the commands where the config volume is mounted. Windows: the same SQL applies via any SQLite tool against library.db in your programdata folder. Commands use python3 (preinstalled on most Linux servers) so you don't need the sqlite3 CLI. If you have the CLI, the SQL statements inside work there too. Run as root. "Cookie poke": SQLite only re-plans cached queries when the schema version changes. ANALYZE and statistics edits don't change it, so after Patches 2/4 the running server keeps its old (slow) query plans until you either restart Emby or "poke" the schema version by creating and dropping a dummy index. The poke is included in the commands below. Patch 1 (real DDL) needs no poke. Never edit system.xml while Emby is running — Emby rewrites it from memory on shutdown and your edit is silently lost. Always stop → edit → start. # Patch Fixes Downtime 0 Backups — none 1 Partial index on UserDatas Search page freezing the whole server none 2 Full ANALYZE Flat ~13 s searches (bad statistics) none 3 system.xml settings Flat ~13 s searches (bad statistics) ~1 min restart 4 Statistics override for AncestorIds2 Stops Emby re-creating the bad statistics; bigger DB pool none Step 0 — Backups (do this first) Consistent snapshot of the live database (safe while Emby runs, uses SQLite's VACUUM INTO mkdir -p /root/emby-backups python3 -c " import sqlite3, time con = sqlite3.connect('file:/var/lib/emby/data/library.db?mode=ro', uri=True, timeout=60) dest = '/root/emby-backups/library-backup-' + time.strftime('%Y%m%d') + '.db' con.execute(\"VACUUM INTO '\" + dest + \"'\") con.close(); print('backup written:', dest)" Copy of the config file: cp /var/lib/emby/config/system.xml /root/emby-backups/system.xml.bak-$(date +%Y%m%d) Snapshot of the current planner statistics (lets you revert Patch 2/4 exactly): python3 -c " import sqlite3, time con = sqlite3.connect('file:/var/lib/emby/data/library.db?mode=ro', uri=True) rows = con.execute('SELECT tbl, idx, stat FROM sqlite_stat1').fetchall() dest = '/root/emby-backups/sqlite_stat1-backup-' + time.strftime('%Y%m%d') + '.sql' with open(dest,'w') as f: f.write('DELETE FROM sqlite_stat1;\n') for t,i,s in rows: f.write(f'INSERT INTO sqlite_stat1(tbl,idx,stat) VALUES({t!r},{i!r},{s!r});\n') print('stats snapshot written:', dest)" Patch 1 — Partial index for the "recent searches" query Problem it fixes: opening the search page fires Items?...WasSearched=true&SortBy=DateLastSearched before you even type. There is no index on UserDatas.DateLastSearchedInt, and the planner can pick a plan that scans your whole library with expensive per-row visibility subqueries — 100+ seconds of CPU during which everything else on the server queues. This tiny partial index (it only covers the handful of rows where the column is set) makes the plan trivially correct in every case. Apply (safe while Emby runs, ~0.2 s, takes effect immediately): python3 -c " import sqlite3 con = sqlite3.connect('/var/lib/emby/data/library.db', timeout=60) con.execute('PRAGMA busy_timeout=60000') con.execute('CREATE INDEX IF NOT EXISTS idx_custom_UserDatas_LastSearched ON UserDatas(UserId, DateLastSearchedInt) WHERE DateLastSearchedInt IS NOT NULL') con.commit(); con.close(); print('index created')" Revert: python3 -c " import sqlite3 con = sqlite3.connect('/var/lib/emby/data/library.db', timeout=60) con.execute('PRAGMA busy_timeout=60000') con.execute('DROP INDEX IF EXISTS idx_custom_UserDatas_LastSearched') con.commit(); con.close(); print('index dropped')" Verify: open search in Emby Web, then check the request time in the server log — should be milliseconds: grep 'WasSearched=true' /var/lib/emby/logs/embyserver.txt | grep -oE 'Time: [0-9]+ms' | tail -5 Survives restarts, server updates, and VACUUM. Emby doesn't know about it; drop it once an official fix ships. Patch 2 — Full ANALYZE (fix the planner statistics) Problem it fixes: Emby's default DatabaseAnalysisLimit=5000 makes its maintenance run a sampled ANALYZE. On the heavily skewed AncestorIds2 table (folder hierarchy) the sample produces wildly wrong statistics ("1 row per folder" when big folders have tens of thousands), and the planner then picks catastrophic plans for search queries. A full, unlimited ANALYZE records correct statistics. Apply (safe while Emby runs, ~1–2 s, poke included): python3 -c " import sqlite3 con = sqlite3.connect('/var/lib/emby/data/library.db', timeout=60) con.execute('PRAGMA busy_timeout=60000') con.execute('ANALYZE'); con.commit() con.execute('CREATE INDEX IF NOT EXISTS idx_custom_statspoke ON ItemExtradataTypes(Name)'); con.commit() con.execute('DROP INDEX IF EXISTS idx_custom_statspoke'); con.commit() con.close(); print('ANALYZE done + plans refreshed')" Note: running plain ANALYZE also erases Patch 4 if you applied it — the combined recipe at the end reapplies both in one go. Revert (restore the statistics snapshot from Step 0 — only useful for debugging): python3 -c " import sqlite3, glob con = sqlite3.connect('/var/lib/emby/data/library.db', timeout=60) con.execute('PRAGMA busy_timeout=60000') snap = sorted(glob.glob('/root/emby-backups/sqlite_stat1-backup-*.sql'))[-1] con.executescript(open(snap).read()); con.commit() con.execute('CREATE INDEX IF NOT EXISTS idx_custom_statspoke ON ItemExtradataTypes(Name)'); con.commit() con.execute('DROP INDEX IF EXISTS idx_custom_statspoke'); con.commit() con.close(); print('restored', snap)" Patch 3 — system.xml settings Problems these fix: the first two stop Emby's own maintenance from re-creating the bad statistics (undoing Patches 2 and 4 at every shutdown); the pool increase keeps writes (playback progress reporting) flowing when heavy queries are running. Note: a bigger pool alone does NOT stop search convoys — Emby serializes list-type queries internally — which is why Patch 4 matters. In /var/lib/emby/config/system.xml change: <DatabaseAnalysisLimit>0</DatabaseAnalysisLimit> <!-- was 5000 --> <OptimizeDatabaseOnShutdown>false</OptimizeDatabaseOnShutdown> <!-- was true --> <MaxLibraryDatabaseConnections>10</MaxLibraryDatabaseConnections> <!-- was 5; ~your CPU core count is a reasonable value --> Apply (stop → edit → start; ~1 min downtime, streams drop and auto-resume): systemctl stop emby-server nano /var/lib/emby/config/system.xml systemctl start emby-server Revert: same procedure with the original values (see your Step 0 backup of the file; prefer editing values individually over copying the whole file back, in case you changed other settings via the dashboard since). Verify the pool size after start: grep 'SqliteItemRepository: Initializing PooledDatabaseConnectionManager' /var/lib/emby/logs/embyserver.txt | tail -1 Re-check these values after Emby package updates. Patch 4 — Statistics override for AncestorIds2 (the TV-search fix) Problem it fixes: even correct statistics only store the average rows-per-folder (a few), while the top-level library folders used in per-user visibility checks hold thousands to tens of thousands of items. SQLite (without STAT4, which Emby's build lacks) can't see the skew, so inside the per-row visibility subqueries it still drives from the folder side. Every search pays ~1–10 ms per matched item — 1–2-letter searches from TV apps (thousands of matches) take 30–50 s and stall other list queries. This override deliberately overstates the folder-side cost so the planner always probes from the item side instead. The first number in the stat is your table's row count, so it's computed dynamically: Apply (safe while Emby runs, instant, poke included): python3 -c " import sqlite3 con = sqlite3.connect('/var/lib/emby/data/library.db', timeout=60) con.execute('PRAGMA busy_timeout=60000') n = con.execute('SELECT COUNT(*) FROM AncestorIds2').fetchone()[0] con.execute('UPDATE sqlite_stat1 SET stat=? WHERE tbl=? AND idx=?', (f'{n} 3000 1','AncestorIds2','idxAncestorIds2_1')) con.commit() con.execute('CREATE INDEX IF NOT EXISTS idx_custom_statspoke ON ItemExtradataTypes(Name)'); con.commit() con.execute('DROP INDEX IF EXISTS idx_custom_statspoke'); con.commit() con.close(); print(f'override applied: {n} 3000 1')" (3000 approximates the real descendant count of large library folders; the exact value isn't critical — it just needs to be much larger than the item side's few rows.) Revert (a plain full ANALYZE restores honest measured statistics): python3 -c " import sqlite3 con = sqlite3.connect('/var/lib/emby/data/library.db', timeout=60) con.execute('PRAGMA busy_timeout=60000') con.execute('ANALYZE'); con.commit() con.execute('CREATE INDEX IF NOT EXISTS idx_custom_statspoke ON ItemExtradataTypes(Name)'); con.commit() con.execute('DROP INDEX IF EXISTS idx_custom_statspoke'); con.commit() con.close(); print('override removed')" Verify it's in place (second number should be 3000): python3 -c " import sqlite3 con = sqlite3.connect('file:/var/lib/emby/data/library.db?mode=ro', uri=True) print(con.execute(\"SELECT stat FROM sqlite_stat1 WHERE idx='idxAncestorIds2_1'\").fetchone())" If the second number is small (e.g. 1 or 4), the override was erased by something running ANALYZE — see the recovery recipe below. Symptom of loss: short/common-term searches suddenly take 30–50 s again. Results measured on our server after all patches: ST 52 s → 0.08 s, the (29k matches) 27 s → 0.25 s, lord 13 s → 0.008 s, recent-searches 100+ s → a few ms. No regressions in Continue Watching / Next Up / home screens. Recovery recipe: "searches got slow again after an update/restart" Refreshes statistics properly AND reapplies the Patch 4 override, then refreshes plans: python3 -c " import sqlite3 con = sqlite3.connect('/var/lib/emby/data/library.db', timeout=60) con.execute('PRAGMA busy_timeout=60000') con.execute('ANALYZE'); con.commit() n = con.execute('SELECT COUNT(*) FROM AncestorIds2').fetchone()[0] con.execute('UPDATE sqlite_stat1 SET stat=? WHERE tbl=? AND idx=?', (f'{n} 3000 1','AncestorIds2','idxAncestorIds2_1')) con.commit() con.execute('CREATE INDEX IF NOT EXISTS idx_custom_statspoke ON ItemExtradataTypes(Name)'); con.commit() con.execute('DROP INDEX IF EXISTS idx_custom_statspoke'); con.commit() con.close(); print('stats refreshed + override reapplied')" Removing all patches when Emby ships the official fix These are workarounds. When an Emby release notes say the search/statistics issues are fixed, remove the patches in the same maintenance window as that update, so the fixed version runs with a stock schema, stock statistics, and stock config. (For ordinary updates where no fix is mentioned: keep the patches, update normally, and afterwards run the recovery recipe above plus re-check the system.xml values.) 1. While the server is still running (old version), drop the custom index (Patch 1): python3 -c " import sqlite3 con = sqlite3.connect('/var/lib/emby/data/library.db', timeout=60) con.execute('PRAGMA busy_timeout=60000') con.execute('DROP INDEX IF EXISTS idx_custom_UserDatas_LastSearched') con.commit(); con.close(); print('custom index removed')" 2. Stop Emby: systemctl stop emby-server 3. Restore system.xml defaults (Patch 3): set DatabaseAnalysisLimit back to 5000 and OptimizeDatabaseOnShutdown back to true. (MaxLibraryDatabaseConnections is ordinary performance tuning, not part of the bug — keep your higher value or restore 5, your choice.) nano /var/lib/emby/config/system.xml 4. Remove the statistics override (Patches 2/4) by refreshing statistics on the stopped database — no poke needed since every connection will be new on start: python3 -c " import sqlite3 con = sqlite3.connect('/var/lib/emby/data/library.db', timeout=60) con.execute('ANALYZE'); con.commit(); con.close(); print('statistics reset to honest values')" With the defaults restored in step 3, Emby's own maintenance manages statistics again from here on — nothing custom remains in the database or config. 5. Install the update, then start: systemctl start emby-server Verify after the update that search is still fast on the fixed version; if it is not, the patches can be reapplied from the top of this guide at any time. (The Step 0 backups are unrelated to this procedure — they exist only as a safety net in case something goes wrong while patching.)

This is ALL Co-Pilot, I don't know what I'm doing when it comes to scripts and programming. That's a good catch, I didn't see it but do now that you ask about it. I just tried that way and still got the error. Unless Tiny Media Manager doesn't give me a proper report, I'm not going to pursue this. Thank you for posting!

Have you tried api_key instead of ApiKey in the URL?

4.10.x: SearchTerm queries take 10–30 s when a term has many matches — degenerate sqlite_stat1 makes per-row visibility subqueries scan whole folder subtrees Versions observed: 4.10.0.25 beta (also present on 4.10.0.20/.23). Ubuntu 24.04, .NET 8.0.28, bundled SQLite 3.53.3. Library: ~191,000 MediaItems, ~477,000 AncestorIds2 rows, ~555,000 UserDatas rows. This is a separate issue from my other report about the "recent searches" (WasSearched/DateLastSearched) query freezing the whole server — same server, different query family and different root cause. It is likely the underlying mechanism behind the long-standing "Search Very Slow (3 minute response)" reports (topic 144128), because the cost scales with the number of FTS matches, which is what makes common/multi-word terms pathological. Symptom Typed search time scales with the number of FTS matches, at a huge per-match cost — even though the final result is tiny: SearchTerm FTS matches Server time fellow 18 0.2 s lord of the 44 12.8 s lord 272 12.7–13.7 s (measured repeatedly) the 29,266 ~27 s That is ~50 ms per matched item. Occasionally the identical request completes in 3 ms — pooled connections cache prepared statements, so each connection keeps whatever plan it compiled first ("plan lottery"; see mechanism below). Search fires 2 of these queries per keystroke (/Items + /ItemTypes), so one user typing can occupy multiple pool connections for ~13 s each. Root cause The /Items?SearchTerm=... SQL (recovered verbatim from a process core dump) joins fts_search9 MATCH @SearchTerm to MediaItems — that part is fine and fast. But for every matched row it evaluates a per-row visibility OR-chain (abbreviated): ... AND ( EXISTS (SELECT 1 FROM AncestorIds2 WHERE itemid=A.Id AND AncestorId IN (<15 allowed folder ids>)) OR EXISTS (SELECT 1 FROM ListItems JOIN ancestorids2 ON ListItems.ListItemId=ancestorids2.itemid AND ancestorids2.AncestorId IN (<15 ids>) WHERE ListItems.ListId=A.Id) OR EXISTS (SELECT 1 FROM itemPeople2 JOIN AncestorIds2 ... WHERE itemPeople2.PersonId=A.Id ...) OR EXISTS (SELECT 1 FROM ItemLinks2 JOIN ancestorids2 ... WHERE ItemLinks2.LinkedId=A.Id ...) OR EXISTS (... ItemLinks2 two-level variant ...) ) On this system sqlite_stat1 contained degenerate statistics: AncestorIds2 | idxAncestorIds2_1 | 470105 1 1 <-- claims 1 row per AncestorId Reality: 476,645 rows, 146,460 distinct AncestorIds, and an extremely skewed distribution — the top folder has 89,352 descendant rows, and the 15 folder ids in the IN-list cover ~85,000+ rows. Believing "1 row per AncestorId", the planner drives those inner EXISTS joins from ancestorids2 (AncestorId=?) — i.e. it enumerates entire folder subtrees once per matched item (EXPLAIN QUERY PLAN showed SEARCH ancestorids2 USING COVERING INDEX idxAncestorIds2_1 (AncestorId=?) as the outer side of the ListItems/ItemLinks2/ItemPeople2 subqueries). ~55 ms per row × hundreds of matches = 10–30 s per keystroke. The degenerate stats look like the output of an approximate ANALYZE (PRAGMA optimize with an analysis_limit) sampling a heavily skewed index — the totals (470105 vs current 476645) show they were produced recently on this very database, and a limited sample of AncestorIds2 easily lands in the mostly-unique region and concludes "1 row per key". If the server re-runs limited analysis periodically, good stats get regressively overwritten. Fix verified on this server A full, unlimited ANALYZE corrected the estimates (avg 4 rows/AncestorId), which flips the inner join order to the item-side (ListItems (ListId=A.Id), itemPeople2 (PersonId=A.Id), ...): lord: 13 s → ~1.0 s end-to-end lord of the: 12.8 s → ~1.0 s No regressions measured in the NextUp/Resume or other query families. Important operational detail: ANALYZE does not change the schema cookie, so pooled connections holding cached prepared statements never re-plan and keep the old behavior indefinitely. The running server only picked up the new stats after we forced a schema-cookie bump (create+drop of a dummy index). If Emby runs ANALYZE as maintenance, it should invalidate/re-prepare its cached statements afterwards, or the fix silently doesn't apply until restart. Remaining structural cost (even with correct stats) SearchTerm=the (29,266 matches) still takes ~27 s at ~1.1 ms/row, because: The query computes count(*) OVER() AS TotalRecordCount even though the client sends EnableTotalRecordCount=false — forcing full enumeration of all matches before LIMIT 50 can apply. Each row evaluates a ShareLevel scalar subquery containing ORDER BY Distance LIMIT 1 — a temp-sort per row — plus the visibility EXISTS chain. This expensive per-row form is used for users that have UserItemShares rows; the variant generated for folder-restricted users instead materializes the allowed-items set once as a CTE (WITH WithAncestors AS (...) ... A.Id IN WithAncestors) and measures ~5× cheaper per row. Suggested fixes: Honor EnableTotalRecordCount=false (skip the window count). Use the materialized-CTE visibility form for all user types instead of per-row EXISTS chains. Ship correct/full statistics (or add explicit indexes/query shapes that don't depend on stat1 being right), and re-prepare cached statements after any ANALYZE. Where the degenerate stats come from (confirmed) — and why TV clients hit this hardest Found the mechanism in the server's own configuration defaults: system.xml on this install has <DatabaseAnalysisLimit>5000</DatabaseAnalysisLimit> together with <OptimizeDatabaseOnShutdown>true</OptimizeDatabaseOnShutdown>. Every shutdown therefore runs a limited ANALYZE (analysis_limit=5000) over indexes like AncestorIds2 whose leading column is massively skewed — a 5000-row sample lands in the mostly-unique region and records "1 row per key". So even after a manual full ANALYZE fixes the stats, the next shutdown re-poisons them. Suggested fix: use analysis_limit=0 (full) for these indexes, ship static correct stats, or don't let optimize overwrite better stats. TV clients make the per-match cost catastrophic in practice: they search per keystroke starting from the first letter. Captured live (Tizen TV app, same behavior on LG): typing "STI…" fired SearchTerm=S (96,295 FTS matches on this library), then SearchTerm=ST (9,118 matches) — the ST pair of queries (/Items + /ItemTypes) each ran 52 s, and with the default MaxLibraryDatabaseConnections=5 the whole server convoyed behind them (playback progress POSTs queued up to 34 s; other users' home screens 30–40 s). One person typing on a TV remote = server-wide outage of ~1 minute, even with corrected stats, because of the O(matches) enumeration described above. Workaround verified on this server (admin-level, at your own risk) Because sqlite_stat1 only stores per-index averages (this build has no STAT4), even a correct full ANALYZE (avg 4 rows/AncestorId) cannot express that the specific folder ids used in visibility clauses are the skewed giants — so the planner keeps choosing folder-side scans inside the per-row EXISTS subqueries. Overriding the average for the AncestorId-leading index with a deliberately pessimistic value flips every visibility subquery to the cheap item-side probes: UPDATE sqlite_stat1 SET stat='476645 3000 1' WHERE tbl='AncestorIds2' AND idx='idxAncestorIds2_1'; -- then force cached statements to re-plan (ANALYZE/stat changes don't bump the -- schema cookie): create+drop any dummy index, or restart the server. Measured results on the live server (191k-item library, ~30 concurrent users): SearchTerm before after ST (2 letters, 9,118 matches) 52 s 0.08 s the (29,266 matches) 27 s 0.25 s lord (272 matches) 13 s 0.008 s No regressions observed in NextUp/Resume/home-screen query families. Note OptimizeDatabaseOnShutdown/limited ANALYZE will overwrite this row, so the override must be reapplied after any stats maintenance (we disabled OptimizeDatabaseOnShutdown). This is presented as evidence of the root cause and a stopgap — the proper fix belongs in the query/schema (see suggestions above). Reproduction guidance Large library (100k+ items) with a deep folder hierarchy (skewed AncestorIds2), a user with UserItemShares rows and a folder allow-list, and degenerate stat1 (run a limited/approximate ANALYZE to get there, or inject '470105 1 1'-style rows). Then search a term with a few hundred matches and compare against a term with <20 matches: the time difference is entirely the per-row visibility evaluation. No SQLite errors are logged at any point; the database passes PRAGMA quick_check; this is purely query-plan behavior.

Got a bit tired of waiting so I let Claude try to do a fix for this and it did it. Search is close to instant on anything I try now. There were 2 issues it fixed. Each issue is explained in its own post one after another here then a guide how to apply it and how to revert it. in case if emby team ever fixes it in their update so you can re run their update afterwards. 4.10.x: "Recent searches" query (WasSearched/DateLastSearched) freezes entire server for 1–2 minutes on large libraries Versions affected (observed): 4.10.0.20, 4.10.0.23, 4.10.0.25 (Linux/Ubuntu 24.04, .NET 8.0.28, bundled SQLite 3.53.3). Did not occur on 4.9.x. Library size: ~191,000 MediaItems, ~555,000 UserDatas rows. Symptom Opening the search page in Emby Web fires GET /Users/{id}/Items?SortBy=DateLastSearched,SortName&SortOrder=Descending&Limit=20&Recursive=true&EnableTotalRecordCount=false&WasSearched=true (the "recent searches" panel — fired before the user types anything). On our server this single query runs 87–117 seconds of pure CPU inside sqlite3_step() (one thread pinned at 100%, zero disk I/O, verified with gdb + strace). While it runs, effectively the whole server convoys behind it: complex item queries and user-data writes queue (/Sessions/Playing/Progress POSTs took 89–99s; requests observed starved up to 15 minutes across consecutive episodes), then everything flushes in the same second the query completes. To all users the server appears completely hung. Typed search itself is NOT the culprit on our server: the FTS-based SearchTerm queries measure 27–850ms standalone (they only appeared slow because they queued behind the recent-searches query). This is likely the same class of issue reported in "Search Very Slow (3 minute response)" (topic 144128). Root cause (verified) The SQL (recovered verbatim from a process core dump taken mid-freeze; abbreviated): select ..., (Select ShareLevel from UserItemShares join AncestorIds2 on AncestorIds2.AncestorId=UserItemShares.ItemId where UserItemShares.UserId=1 and UserItemShares.ShareLevel not null and AncestorIds2.ItemId=A.Id order by Distance limit 1) as ShareLevel from mediaitems A left join UserDatas on A.UserDataKeyId=UserDatas.UserDataKeyId And UserDatas.UserId=1 where A.Type in (1,2,5,6,8,...,34) AND UserDatas.DateLastSearchedInt > 0 AND (ShareLevel > 0 OR A.Type in (...) OR A.IsPublic=1) AND A.ExtraType is null AND ( EXISTS (SELECT 1 FROM AncestorIds2 WHERE itemid=A.Id AND AncestorId in (...)) OR EXISTS (ListItems join ancestorids2 ...) OR EXISTS (itemPeople2 JOIN AncestorIds2 ...) OR EXISTS (ItemLinks2 join ancestorids2 ... Type in (...)) OR EXISTS (ItemLinks2 ItemLinks2TwoLevel WHERE EXISTS (...) ...) ) Group by A.PresentationUniqueKey ORDER BY MAX(UserDatas.DateLastSearchedInt) DESC NULLS LAST, A.SortName collate NATURALSORT DESC LIMIT 20 There is no index on UserDatas.DateLastSearchedInt, so the planner cannot see that DateLastSearchedInt > 0 is extremely selective (only ~10–100 rows in the whole table ever have it set). SQLite then picks this plan (EXPLAIN QUERY PLAN from a copy of the production DB): SEARCH A USING INDEX idx_MediaItems47cd2 (type=? AND ExtraType=?) -- ~176k rows CORRELATED SCALAR SUBQUERY 1 (ShareLevel) -- incl. USE TEMP B-TREE FOR ORDER BY, per row! CORRELATED SCALAR SUBQUERIES 2..7 (the visibility EXISTS chain, per row) SEARCH UserDatas USING INDEX UserDatasIndexUnique1 (UserDataKeyId=? AND userId=?) -- applied LAST i.e. it scans ~176k items and evaluates the ShareLevel subquery (with a per-row sort) plus up to five correlated visibility subqueries for every row, and only then joins UserDatas where DateLastSearchedInt > 0 throws away all but ~10 rows. Measured: >90 s. The mirror plan (drive from UserDatas first) takes ~2 s; which plan a pooled connection gets appears to depend on the sqlite_stat1 state at prepare time, which is why the freeze is intermittent and per-connection ("plan roulette" — we observed the identical request take 116,798 ms and, four minutes later, 2,351 ms). ANALYZE does NOT stabilize the good plan (after a fresh ANALYZE the planner chose SCAN A, still >60 s). Fix that works (verified on production) CREATE INDEX idx_UserDatas_LastSearched ON UserDatas(UserId, DateLastSearchedInt) WHERE DateLastSearchedInt IS NOT NULL; Build time 0.2 s (partial index over the handful of rows that have the column set). The planner then drives from this index in every stats state we tested. Result on the live server: the recent-searches request went from 116,798 ms → 16 ms, and the server-wide freezes stopped. Suggest shipping this index (or equivalent) in the 4.10 schema, and/or restructuring the query so the selective DateLastSearchedInt predicate drives the join rather than being applied after the per-row ShareLevel/visibility subqueries. Notes No SQLite errors of any kind in logs (no "database is locked", no corruption); PRAGMA quick_check ok. The DB stays fully readable by other processes during the freeze (external probe queries answered in 34–52 ms throughout) — the hang is entirely this query plus the connection-pool convoy behind it. Reproduction needs: a multi-user library in the 100k+ item range, at least one user with DateLastSearchedInt set (i.e. someone has used search before), and folder-restricted users (the ShareLevel/visibility subqueries). Secondary observation: Debug App: Sqlite: 284 - automatic index on ... warnings appear frequently for LastWatchedEpisodes(SeriesPresentationUniqueKey) and LinkedCounts(AId) (materialized subqueries in the NextUp/Resume queries) — worth a look for the same reason, but not the freeze trigger here.

Yes if you can pick new and live as options that's all I'm asking for. It would make setting up recordings much simpler when live is what's there. Thanks.

Hi Luke, Sure. the first pic - movies view with names in Czech the second pic - folders view - no collage pic for folder the third pic - movies with name of folder, no Czech names the fourth pic - library settings Thanks

Isn't it only things like pixel shift that can help with it?

So far this app is working great for me. I have tweaked a lot of the settings to just the way I like it. I am having one issue in the presentation of my poster and thumbs on the home screen. They look very blurry and low quality. In the Emby app they look really nice. I tried to look for any setting regarding this but can't find anything. Am I missing something somewhere or is this just how the app compresses these?

What specific example from the log file are we focusing on here?

Need help to figure out why my media art is disappearing....