All Activity

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....

@Geordie When you suggested the engine, I said the route wasn't for me but the pointer was worth it either way. It turned out to be worth more than that. I kept turning it over — the part of your suggestion that stuck wasn't the engine, it was the route itself: stop negotiating with the server's manifest and do the remux locally. So I built a narrow version of exactly that. The app now carries its own Matroska demuxer and fMP4 muxer — about two thousand lines of Swift, no FFmpeg, no decoders, nothing bundled. It reads the MKV straight from the server with HTTP range requests (opening a 19 GB file costs 16 requests and ~300 KB, thanks to Matroska's cues), splits it into fMP4 segments on the device, writes its own HLS master — VIDEO-RANGE, CODECS, one audio rendition per track, all derived from the file itself — and hands that to the native AVPlayer. It never touches the bytes: video and audio are copied, not transcoded. HDR10, and the HDR10+ metadata that a server-side transcode strips, survive untouched. Measured last night on an Apple TV 4K, with a 19 GB 4K feature — Dolby Vision profile 8 over an HDR10 base, ~25 Mbps average: the display switches into HDR, and it switches from a 4K SDR output mode with Match Dynamic Range on, before playback starts — the case that used to be hopeless. The server's only work is serving byte ranges: the day's server log shows zero ffmpeg launches and ~1,300 HTTP 206 responses against the static file endpoint, and the dashboard reports the session as Direct Play. Seeking, chapter jumps and resume all behave like local playback — the cues map straight to byte ranges, so nothing round-trips through a session. So the line I drew in my earlier post still stands, and now it has both halves: the native player, the system track picker, no bundled engine — and the local remux you were right to point at. The difference from the engine route is only where the pieces come from: AVPlayer keeps doing the decoding and the UI, and the app only rearranges containers, which is the boring part and the one I'm happy to own. For everyone else on the thread: this doesn't retire the original request. VIDEO-RANGE and CODECS in the manifest are still what would fix this for every client that doesn't carry its own demuxer — which is nearly all of them. My app just stopped needing to wait. Thanks again, @Geordie. The nudge did more work than the suggestion.

It could be the mime type passed into the intent is not correct. We'll take a look at it. Thanks.

@jccbsl?

Success! Retested with Emby Server v4.9.5.0 and Emby for Android (on FireTV) v3.5.44. Now it seems every single place shows the correct transcoding information. Thank you @Luke!

PLAN B: Tiny Media Manager can apparently export the list that I need. I have it installed and running right now. Unfortunately, I had done what the page shows. It doesn't make sense to me, especially since I am the ONLY configured user and so presumably the Admin by default. Co-Pilot decided at some point that instead of using localhost the script should use the IP address instead. Maybe I'll just have to manually do this, which would be a stinker, but the Reports plugin might give me some good info.

Hi, the issue has been found and is specific to folders with dots in the name: Thanks.

Hi, the issue has been found and is specific to folders with dots in the name: Thanks.

OK Thanks. I see the issue. It is resolved for the next release.

That is likely a bug as already described here: Even with all badges/everything else OFF/None, episodes 1 are getting it in CW row.

Honestly, I thought it was more likely something in the script, even though Co-Pilot didn't agree. LOL I'll read that now, thank you!

HI @Blueskies278 , I might be doing something wrong. i wanted to disabled all the web client stuff (i only want the image overlay stuff in real life and for testing). so went with config { "EditorTitle": "TV Show Status Settings", "EditorDescription": "Displays TV show status badges (Returning, Ended, Cancelled) and return dates on series pages using data from TMDB. This product uses the TMDB API but is not endorsed or certified by TMDB. The web browser badge deploys itself automatically on startup - it writes a small script into Emby's own web folder and adds a line to index.html that loads it. On some setups, most often Docker, Emby doesn't have permission to write there: the folder is owned by root while Emby runs as another user. That is an ownership problem rather than a read-only folder, and one chown fixes it permanently - the 'Web Badge/Description Script' box at the bottom of this page tells you the exact command for your platform. Everything else in this plugin works regardless. If you would rather not change permissions at all, turn on 'Prepend status to show description' instead: it writes into Emby's own metadata, needs no file access, and shows on every client including Android and tvOS.", "TmdbApiKey": "[removed]", "WriteStatusToOverview": false, "DisplayMode": "None", "BadgeStyle": "None", "EnableImageOverlay": true, "OverlaySize": "ExtraLarge", "WebGridBadges": false, "ThumbnailBadges": "Everything", "EpisodeBadges": "PremiereAndFinale", "BadgeOpacity": "Solid", "OverlayPosition": "BottomCentre", "OverlayMarker": "Calendar", "EndedMarkerColour": "Red", "CancelledMarkerColour": "Default", "AiringMarkerColour": "Default", "CompleteMarkerColour": "Default", "OverlayMode": "ReadyToBinge", "OverlayWatchedUser": "Cartman", "ForceDisableSkiaSharp": false, "OverlayModeStatus": { "Status": "Warning", "Caption": "Poster Overlay", "StatusText": "This server has 5 users.\n\nEmby draws ONE poster per show and shares it with everyone, so every user will see Cartman's watched progress - not their own. On a household server that is misleading rather than broken, which is why it is worth saying plainly.\n\n'Show when a season has finished airing' gives you the blue Complete badge without this problem - it just does not hide the badge once you have watched the show.\n\nWorth knowing: TMDB reports 'nothing scheduled' both for a season that has genuinely finished and for one that is simply between episodes with no date published yet. Those cannot be told apart from the data, so a show on a mid-season break can read Complete early. It corrects itself as soon as TMDB publishes the next date.", "CanHideInCompactView": false }, "AirDateSourceStatus": { "Status": "Succeeded", "Caption": "Air Dates", "StatusText": "Using TMDB dates. The Trakt Air Dates plugin is not installed, or has not built its cache yet.\n\nThat is a perfectly normal setup and nothing is broken. Worth knowing though: TMDB stores an air date as a bare date with no time and no timezone, so a US show broadcast in the evening can show the previous calendar day if you are outside the US. Installing Trakt Air Dates fixes that; this plugin picks it up automatically with no configuration.", "CanHideInCompactView": false }, "WebScriptStatus": { "Status": "Succeeded", "Caption": "Web Badge/Description Script", "StatusText": "Active - the badge script is deployed into Emby's web folder and index.html loads it.\n\nAn Emby app update wipes both, so the plugin now re-checks every 5 minutes and puts them back on its own. On Docker it can only do that once Emby owns its web folder again - see Setup below.", "CanHideInCompactView": false }, "FeatureRequiresPremiere": false, "IsNewItem": false } (testing 2.5.77) I am a bit unsure how to refer to what i am looking at. My previous feedback was through a mistaken lense, i think i was seing the "web client" functioanlity... In continue watching ...Are these Show thumbnails? or seasons thumbs (which have inherited the show's thumb image) or episode thumbnails (which are overridden by season > show) - not sure how emby works, or if it even matters to the logic of the image processor. something interesting is happening becuase if i look at the show thumb in library there is no overlay only on "continue watching" (not a problem but it might help to know whats going on when troubleshooting / feeding back). To me extra large on the image could not be readable if it was any smaller. In practice for screen realistic i wonder wether a dot rather than text would be a useful option (idle suggestion until i see it as a whole). I think the ultimate outcome for me would be to see text/dot which confirmed somethign on continue watching thumbs, that indicates "Ready to Binge Season(/Show)", and season premier/finale as the cherry on top. Anyways i seem to loose almost all functionality when i turn off what i assume is the web functionality, except season premiere (oddly season finale on "Bottom" doesnt work, when premier does on "The Simpsons"). Maybe some of the settings are shared by web client and image processing and i have inadvertently turned something off? Could/should the web client and image processoing be more 'obviously' separate to enable/configure in the options? That said if image processing is working and granular enough, why would you want to overlay things via webclient functionality that only works on the web client?

Since the latest update I have problems scrolling down in the list of home movies. When I play one when I quit to go back to the list it takes me back to the top of the list instead of that movies place lower down in the view. This did not happen before. Also I’ve noticed after deleting the app and reinstalling when I play a movie it disappears from the view that contained it but it is still in the library if I look in the folder that contains it. I think both of these things happened before on a previous build and you fixed them with newer builds but now they have resurfaced. Back to Infuse client for now for me. @SamES

BOonjour, temps de réponse très long, mais j'ai pris le temps de me remettre sur mon problème. J'ai trouvé la solution, dans la partie transcodage, j'ai activé l'option suivante: Il me semble pourtant que ce menu n'existait pas il y a encore 2 ans. Merci d'avoir pris le temps de me répondre en tout cas

Within the base folder (s) for each library does each movie have its own directory with the correct name and year of that one movie? https://emby.media/support/articles/Movie-Naming.ht Does each series have its seasons (even if only one) in a separate Season nn directory within the series folder? https://emby.media/support/articles/TV-Naming.html Those rules as I stated them are perhaps stricter than necessary in some situations, but if you follow them, misidentification (and specifically confusion between series and movies) should be a thing of the past. Paul

Hi, have you taken a look at this? Emby SDK Documentation: API-Key Authentication

I am having issues with the Reports plugin as I try to find my old movies that are 720p or even worse to upgrade. It has often wrongly identified the resolutions, usually showing 1080p as 720p... So, anyway, I've been using Co-Pilot to create reporting based using the API key that I created specifically for this. I should mention that I first tried the API key that was already with the same error. My Lifetime license appears to be fully installed and everything is happy in that regard. ERROR OCCURRED: Access token is invalid or expired. The C:\Reports path has full permissions and I'm executing the .PS1 file from within Powershell, which is running as Administrator. After a lot of back and forth, Co-Pilot thinks that the issue is related to network binding of some sort, causing the key to be rejected. Any thoughts would be much appreciated. I've attached the script here as a .TXT file, in case that helps. EmbyReportingPowershell.txt

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

@Eggi001?