About updating to version 4.10.0.40

[17732 24]

In this version, the default popular search results show up quickly, but when I click on the options on the right like shows, seasons, episodes, or movies, it just keeps loading for a long time before showing results. I remember this wasn’t a problem in version 4.9. It only appeared in version 4.10.0.40, and it seriously affects the efficiency of searching for things. ...

[17732 24]

54 minutes ago, 17732 said:

In this version, the default popular search results show up quickly, but when I click on the options on the right like shows, seasons, episodes, or movies, it just keeps loading for a long time before showing results. I remember this wasn’t a problem in version 4.9. It only appeared in version 4.10.0.40, and it seriously affects the efficiency of searching for things. ...

 

I had AI analyze the logs, and it really is an Emby issue.
Investigation Conclusion

The logs (Emby 4.10.0.40, Synology, with the media library located on the large-capacity /volume4 storage) have clearly identified the problem. This is a query-path defect in the new full-text search (FTS) introduced in the 4.10 release. It is not an environment configuration issue.

The Difference Between the Two Search Paths (Confirmed by the Logs)

1. Default Search (Fast, ~150–250 ms)

When entering a search keyword, the frontend calls a lightweight interface (/emby/ItemTypes + /Items without a type filter).

For example, searching for “生化危机” (Resident Evil) takes only about 148–155 ms.

2. Clicking the Type Filter (Slow, 2–19.7 seconds)

After clicking the type filter on the right side (Movie / Series / Season / Episode), the request changes to:

IncludeItemTypes=Movie&SearchTerm=...

The server then generates SQL like this:

from mediaitems A
join fts_search9 on A.Id=fts_search9.RowId and fts_search9 match @SearchTerm
where A.Type=5
AND EXISTS (SELECT 1 FROM AncestorIds2 ...)
Group by A.PresentationUniqueKey
ORDER BY Rank ASC LIMIT 50

The logs show that queries of this type take an extremely long time.

For the same “美国队长” (Captain America) movie search, the query repeatedly took approximately:

* 19,368 ms
* 19,371 ms
* 19,383 ms
* 19,426 ms
* 19,440 ms
* 19,445 ms
* 19,775 ms

The slowest query took 39,035 ms.

The execution time is highly consistent and reproducible, which indicates that this is not an occasional system-load issue, but rather an inappropriate query plan caused by the combination of:

* FTS matching
* Type filtering
* Per-row AncestorIds2 subqueries
* Rank sorting

Why the SQLite Errors in the Logs Are Not the Root Cause

There are 97 occurrences of the following SQLite error in the logs:

Sqlite: 9 - statement aborts ... interrupted

This is a symptom, not the cause.

The query is still running when the user gets tired of waiting and leaves the page or switches to another search/filter. The client then disconnects, and Emby cancels the still-running query.

This is why the logs also contain messages such as:

Response completed after client disconnected

Therefore, the SQLite interruption messages are a consequence of the slow query rather than the original problem.

Why This Does Not Happen in 4.9

There was no such problem with 4.9.

The 4.10 series rewrote the search implementation and introduced the fts_search9 (FTS5 full-text index) search path.

The type-filtered search happens to hit the worst possible query-plan combination involving FTS matching + type filtering + per-row AncestorIds2 subqueries + Rank sorting.

This is a regression introduced in Emby 4.10.0.40.

Recommendations (in Priority Order)

1. Upgrade to the Latest 4.10.x Beta

The FTS search has continued to receive optimizations in subsequent versions of the 4.10 series.

If the latest version is still slow, I recommend temporarily reverting to the 4.9 stable version.

2. Run the “Optimize Database” Scheduled Task

Go to:

Dashboard → Scheduled Tasks → Optimize Database

It is recommended to run it manually once.

This performs VACUUM + ANALYZE, which allows the SQLite query optimizer to recalculate statistics and potentially choose a better query execution plan. For this type of slow query, it may significantly improve performance.

3. Report the Issue to Emby

Please provide the slow-query section beginning with “query time (slow 6x)”, including the approximately 19.7-second SQL query shown above.

This is the information the Emby developers need most to investigate the problem.

4. Temporary Workarounds

After searching, directly open the desired item from the default search results and avoid using the type filters on the right.

Alternatively, enter the corresponding media library and use its advanced filtering instead of the global search type categories.
 

[Luke 43166]

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

[17732 24]

embyserver.txt

8 minutes ago, Luke said:

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

 

embyserver.txt