All Activity

26.0.17 Fix add to collection option missing for artists and albums

Emby Web App Update: Version 26.0.17 The Emby Web app has been updated to version 26.0.17 Go and try out: https://app.emby.media/ Changes 26.0.17 Fix add to collection option missing for artists and albums

Hi, are you able to get the issue to happen again?

Emby 4.9.x – Collections temporarily missing / missing artwork after library refresh, eventually repopulate after forced image refresh I wanted to document an issue I ran into with Collections on Emby 4.9.x in case it helps anyone else or provides useful information for the developers. Server Emby Server 4.9.x Native Linux installation Linux Mint Large movie library (2,000+ movies) Automatic collections enabled Minimum automatic collection size: 2 movies TheMovieDb enabled A small number of additional dynamic/curated collections managed by the ACdb.tv plugin Symptoms I initially noticed that a large number of collection posters were missing. The collections themselves were visible, but many had blank artwork. Refreshing an individual collection using: Collections → Collection → Refresh Metadata with: Replace images: Enabled Video preview replacement was also enabled during the first test caused the collection image to appear correctly. I then selected the collections in bulk and ran the same metadata refresh with Replace images enabled. This successfully restored the collection artwork. However, shortly afterward I noticed what appeared to be a second problem: the number of visible collections seemed much lower than expected. I remembered having roughly 350 collections, but at one point only around 140 appeared to be visible. For example: 30 Days of Night Collection was not visible even though both: 30 Days of Night (2007) 30 Days of Night: Dark Days (2010) were present in the library. Refreshing those two movies did not immediately recreate or reveal the collection. Database investigation Before modifying anything, I checked library.db. The supposedly missing collection was still present: Id type Name Path ParentId ProviderIds ------ ---- --------------------------- ---- -------- ----------- 218205 9 30 Days of Night Collection Tmdb=91660 The movie-to-collection links were also intact: LinkType ItemId ItemName LinkedId LinkedName -------- ------ --------------------------- -------- --------------------------- 6 134238 30 Days of Night 218205 30 Days of Night Collection 6 134242 30 Days of Night: Dark Days 218205 30 Days of Night Collection Both movies also still had their imported collection information: ItemId Name ProviderIds ------ --------------------------- ----------- 134238 30 Days of Night Collection Tmdb=91660 134242 30 Days of Night Collection Tmdb=91660 The collection count in the database eventually showed: CollectionsInDatabase --------------------- 333 So the collection records had apparently not actually been lost. TMDb activity The Emby log showed the server actively requesting collection metadata/images from TMDb and receiving HTTP 200 responses. Example, with the API key removed: Info HttpClient: GET https://api.themoviedb.org/3/collection/9380?api_key=[REDACTED]&append_to_response=images&language=en-US&include_image_language=en-US,null Info HttpClient: Http response 200 from https://api.themoviedb.org/3/collection/9380?... after 46ms Info HttpClient: GET https://api.themoviedb.org/3/collection/98036?api_key=[REDACTED]&append_to_response=images&language=en-US&include_image_language=en-US,null Info HttpClient: Http response 200 from https://api.themoviedb.org/3/collection/98036?... after 50ms There were many requests like this occurring one after another. What ultimately happened After the bulk collection refresh with Replace images enabled, the collections and their artwork began appearing gradually. Refreshing the Collections page periodically showed more and more collections. Eventually the visible number rose to approximately the same number of collection objects present in the database. The ACdb-managed collections also began appearing normally again without changing the ACdb configuration. Working procedure What worked for me was: Open Collections from the normal Emby user interface. Select the affected collections, or bulk-select all collections. Choose Refresh Metadata. Enable Replace images. Start the refresh. Allow Emby to continue processing. Do not immediately assume missing collections have been deleted. Refresh the Collections page periodically and allow time for the entries/images to repopulate. In my case, collections appeared gradually while Emby continued downloading collection metadata and artwork. Possible 4.9.x issue What was confusing is that the UI initially made it look as though a large portion of the collections had disappeared, even though: The collection objects still existed in MediaItems Their TMDb IDs were still present Movie-to-collection links in ItemLinks2 were intact ImportedCollections still contained the correct collection information TMDb requests were succeeding with HTTP 200 responses This makes me wonder whether there is an issue in 4.9.x involving collection metadata/image refreshes, cache invalidation, asynchronous collection rebuilding, or how the Collections view is updated while a large refresh is still running. It may also be useful if the UI could indicate that collection metadata/artwork is still being processed, because during a large refresh it can look as though collections have actually been removed. No direct database modifications were required to resolve the issue. Hopefully this information and the database/log details are useful for tracking down any remaining Collections-related issues in the 4.9.x releases. I hope this helps somehow; I've had this issue multiple times during the 4.9.x versions; I just had not been able to do anything with it for health issues. I will also add that the investigation and troubleshooting were with ChatGPT's aid. Got to put it to work in something useful and not just make cat girl pics and videos lol. embyserver.txt

Thanks — I went to test that, and the result surprised me. If the list were approximating keyframe positions, changing the keyframe-break request ought to change it. It doesn't. Same file, same parameters, only BreakOnNonKeyFrames varying: BreakOnNonKeyFrames=True 222 segments, all #EXTINF:6.0000, sum 1332.000 (parameter absent) 222 segments, all #EXTINF:6.0000, sum 1332.000 BreakOnNonKeyFrames=False 222 segments, all #EXTINF:6.0000, sum 1332.000 The three playlists are byte-identical once the PlaySessionId is stripped. And the count is exactly ceil(declared duration / segment length), at both lengths I can get the server to produce: ceil(1326.336 / 6) = 222 -> 1332.000 s advertised ceil(1326.336 / 3) = 443 -> 1329.000 s advertised So the list isn't an imprecise estimate of where keyframes fall — it doesn't consult them at all, and every entry carries the nominal segment length rather than a measured one. That's why I don't think an import-time scan is what's missing here: making the last entry honest doesn't need keyframe positions, only the end of the media. And the gap isn't boundary rounding, it's 6.6 s — a whole segment. And the failure isn't confined to the predicted segment When the player doesn't get 221, it steps back to 220. That one is not predicted: it is real, it is inside the media, and it had already been served 200 earlier in the same session. It gets 500 nine times as well. One of those requests, end to end — 93 ms: 14:53:00.573 GET .../hls1/main/220.ts 14:53:00.614 ProcessRun 'StreamTranscode c2b692' Execute: ... -ss 00:22:00.000 ... -segment_start_number 220 14:53:00.628 SegmentComplete=video:0 Index=220 ... Frames=136 filename=04C768_220.ts 14:53:00.628 video:2332kB audio:148kB subtitle:0kB other streams:0kB 14:53:00.628 EXIT 14:53:00.634 ProcessRun 'StreamTranscode c2b692' Process exited with code 0 14:53:00.666 Error processing request 14:53:00.666 Response 500 ffmpeg produced the segment — 136 frames, 6.72 s, 2.4 MB — and exited 0. The request was answered 500 anyway. So there is a second failure that a better prediction would not fix, and it is the one that makes this unrecoverable: the client cannot get out of it even by stepping back to a segment that exists. Possibly related, from that same line: SegmentComplete reports Index=220 with Start=0.000000 End=1325.365000 Duration=1325.365000 — the length of the whole episode, for a segment holding 6.72 s. The command line carries -segment_time_delta -00:22:00.000 together with -copyts -start_at_zero. If anything downstream checks the produced segment against an expected time, that bookkeeping wouldn't match. I don't know the code, so this is only a guess. The transcoding path is a third thing again: there hevc_vaapi exits 139 (SIGSEGV) five times in forty seconds, and the request is never answered at all. None of this needs the prediction to become exact. Even leaving it as it is, overshooting by one segment could end the stream rather than start an unbounded retry loop — which is what turns a third of a second of missing video into a session that never finishes.

Thanks.

It's not random. It literally goes by which one is scanned into the library first. I've spent many hours testing various combinations to get it working and now it finally does.

How are you closing the app?

This could be made more accurate by scanning the file for keyframe information during import. The problem is that this can take a long time, so that’s why this is a prediction.

No, I can get to them no problem. If I revert back to 4.9.3.0 everything starts to come back and work.

Are the media folders unreachable at that time?

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

Hi, in case it helps, it’s not actually by date. It’s arbitrary which one you will see.

I tested this and it doesn't auto detect properly. E-AC3 with Atmos doesn't get passthrough via the Emby App for Android but the Emby for Android TV is working. Now I have to switch back to Emby for Android TV.

One last thing, and I say it with a smile. This is the bug that is pushing me to demux Matroska on the Apple TV myself. The app already carries a Matroska demuxer and an fMP4 muxer — I wrote them to keep HDR intact end to end — and the arithmetic above is what is now making me point them at everything else, HDR or not, so that the player never has to ask for a segment list at all. A playlist I never request cannot promise me a segment that was never written. For a TV app this one really is fatal: an episode that never reaches its end is an episode that never starts the next one, and a session left open on your dashboard. So I route around it — but writing container plumbing is not what a client should be spending its time on. It's a lot of code to own, a lot of new surface for bugs that are entirely mine, and every hour of it is an hour not spent on the app itself. I would delete all of it, gladly and in a single commit, the day the server hands me a stream I can play straight through. That's all this report is really asking for. Happy to test anything you want tested.

thanks for the very detailed answer

Thanks for sharing.

Not a dumb question — the screen hides it, and on top of that there's something on my side that means your server could never have shown up by itself. Here's where the button is, and what's being fixed. --- Where the button is --- Open the app without a session and it spends a few seconds looking for servers on the local network. Under that, there are two buttons side by side: [ ⟳ Search again ] [ + Enter address manually ] "Enter address manually" is the filled one on the right. You don't have to wait for the search to finish — the button is there and selectable the whole time. It replaces the list with a single field labelled SERVER ADDRESS and a Connect button. Type the address, press Connect, and the app comes back with your server's name and version and the users your server publishes on its own sign-in screen: pick yours, type your password, and you're in. --- What to type --- The same address you would type into a browser on that network: http://192.168.1.50:8096 · 8096 is Emby's default HTTP port — 8920 if you've set up HTTPS. Include the port. · The http:// is optional; leave it out and the app adds it. · Don't use localhost or 127.0.0.1 — from the Apple TV, those mean the Apple TV. · A name works too (http://tower.local:8096), and so does a domain through a reverse proxy, including one where Emby lives under a subfolder. If you don't know the address: open Emby in a browser on a computer on the same network and read the address bar. If it says localhost, then it's that machine's own LAN address you need, and the Emby dashboard will show it to you. One thing you'll see in that field and should ignore: the example inside it currently reads "servidor" instead of "server". That's a string I forgot to translate — not a hint about what to type. It'll say http://192.168.1.50:8096 in the next build, which is what it should have said in the first place. --- Why your server wasn't in the list --- This part is on me. The automatic search does broadcast on UDP port 7359, which is the right port — but it doesn't send the message Emby answers to ("who is EmbyServer?"). So your server was never actually asked, and no Emby server can appear in that list today. Nothing to switch on at your end, and nothing wrong with your setup. The next version asks the right question. Even then, manual entry stays and stays first-class: broadcast doesn't survive everything — Docker bridge networking without 7359/udp published, guest or IoT VLANs, access points with client isolation — so the address field is also getting the example it should have had, and a shorter path to reach it. Thanks for asking it out loud. This is the kind of thing that gets found by someone typing "dumb question", and not by me.

Okay sorted it, have a script on unraid that I run via UserScripts, it scans the array for "newer" 4K movie, scans HD share for version match and renames the file to add (HD) on it and to also trigger re-scan on Emby so that the 4K version is older and primary. Took a bit of work, but least it's a solution.

Emby Server 4.9.5.0 (Linux, .NET 8). The claim: the HLS segment list is computed from the container's declared duration and is never checked against the media. For any file whose declared duration runs past its last frame, the list therefore always contains one trailing segment that cannot be produced. It reproduces in one request No playback, no transcoding session to watch, no waiting for the end of a file — just fetch the variant playlist and count: curl -s "<server>/emby/videos/<id>/main.m3u8?<params>" | grep -c '#EXTINF' curl -s "<server>/emby/videos/<id>/main.m3u8?<params>" \ | grep -o '#EXTINF:[0-9.]*' | cut -d: -f2 | awk '{s+=$1} END {print s}' For a 22-minute MKV here (RunTimeTicks 13263360000 = 1326.336 s), 6-second segments: Segments in the list 222 (0–221) Distinct #EXTINF values one — 6.0000, all 222 times Sum of declared durations 1332.000 s Declared container duration 1326.336 s End of the written media 1325.365 s That last figure is the server's own, from SegmentComplete=video:0 Index=220 Start=0.000000 End=1325.365000. So the playlist advertises 6.635 s of video that does not exist, and the trailing segment is declared 6.0000 rather than the 0.336 s it would nominally cover. #EXT-X-TARGETDURATION is 7 while every segment says 6. What follows from it When a client asks for that trailing segment, ffmpeg is started with -ss 00:22:06.000, which is past the last frame. What happens next depends on the path: Copy / remux (-c:v copy -c:a copy ffmpeg exits 0 having written nothing, and the request is answered 500. Clients retry indefinitely; each retry starts a new ffmpeg process. Transcode (hevc_vaapi the encoder gets no frames and segfaults — Process exited with code 139 - Failed. The request is never answered at all; the connection is held open until the client disconnects. Either way the stream never terminates, so no client on the HLS path ever reaches end-of-stream. Direct play is unaffected, because it never reads the segment list. Why this is posted here This is not a configuration issue and it does not depend on the client. The symptom side — sessions stuck on the dashboard, next episode not starting — is already reported at 145772, with the playback-side measurements. This post is only about the arithmetic that builds the list. Deriving the segment count and the final #EXTINF from the actual end of the media rather than from RunTimeTicks would remove the phantom segment, and would also make the last segment's declared duration honest. Happy to provide the full playlist, the server log or the sample file.

That sounds like your metadata fetchers in your libraries are disabled.

@Luke Emby Server 4.9.5.0 (Linux, .NET 8). Coming back to this with numbers, and with a test that I think isolates the cause. Everything below is one server, one file, one afternoon, using Emby's own clients. The file A 22-minute episode, H.264 1080p 23.976 fps + AC3 stereo, in MKV. The container declares RunTimeTicks 13263360000 = 1326.336 s. The last segment ffmpeg actually writes reports: SegmentComplete=video:0 Index=220 Start=0.000000 End=1325.365000 Duration=1325.365000 offset_pts=0 start_pts=0 Frames=136 So the written media stops at 1325.365 s and the container claims 1326.336 s. That 0.971 s disagreement is where everything below comes from. What the playlist promises The segment list is built from the declared duration, so it always holds one more segment than the media can fill: 6-second segments: 1326.336 / 6 = 221.056 -> list runs to index 221 (1326.000 -> 1326.336) 3-second segments: 1326.336 / 3 = 442.112 -> list runs to index 442 (same 0.336 s) What happens when a client asks for that segment In both cases the server starts a fresh ffmpeg with -ss 00:22:06.000, which is 0.971 s past the end of the written media. What happens next depends on the path. Transcoding — Emby Web 4.9.5.0 on Safari, h264 → hevc_vaapi, 3-second segments: 15:17:18 GET .../hls1/main/442.ts -> no response; held open 10 s, client disconnects ProcessRun 'StreamTranscode aaa338' Process exited with code 139 - Failed 15:17:28 retry -> ... exited with code 139 - Failed 15:17:38 retry -> ... exited with code 139 - Failed 15:17:48 retry -> ... exited with code 139 - Failed 15:17:58 retry -> ... exited with code 139 - Failed 15:17:59 Playback stopped ... Position: 1325323 ms Exit code 139 is SIGSEGV. Five new ffmpeg processes, five segfaults, in forty seconds. Those are the only five 139s anywhere in the log, and all five are on this one segment. Direct streaming / remuxing (-c:v copy -c:a copy), 6-second segments: ffmpeg exits with code 0 and writes nothing, and the server answers 500 instead: 14:52:10 ... 14:52:41 segment 221 -> 500 (9 times, ~every 5 s) 14:53:00 ... 14:53:31 segment 220 -> 500 (9 times, ~every 5 s) Segments 209–219 all returned 200, and 220 returned 200 the first time it was requested. Each 500 is preceded by AppendExtraLogData - File Deleted, and each retry starts a new ffmpeg process which then exits with no error at all. Why the session sticks on the dashboard This is the part that gave this thread its title, and I think it follows directly. The player never receives an end of stream. It receives a playlist promising a segment that never arrives, so it keeps retrying and never reports playback as finished: 14:52:10 first 500 on the tail segment 14:52:24 Playback progress (StateChange) ... 14:52:34 Playback progress (StateChange) ... 14:52:44 Playback progress (StateChange) ... 14:52:54 Playback progress (StateChange) ... 14:54:32 PlaySession ... has gone idle while playing 14:54:32 Removed playSession ... 14:59:51 Playback stopped ... playing Unnamed item. Position: 1325732 ms 14:59:51 DELETE /Videos/ActiveEncodings ... The session reports as playing for 2 minutes 22 seconds after the media is effectively over, and the server ends it with an idle timeout rather than because the stream ended. I suspect this is also the mechanism behind the "streaming not ending server-side / multiple streams on one user" report: on this path nothing is ever ended by playback completing. The test that isolates it Same file, same server, same afternoon, three paths: Path Last position Outcome HLS, transcoding (Emby Web, Safari) 1325.323 s stuck, 5× ffmpeg SIGSEGV HLS, direct stream / remux 1325.732 s stuck, 18× HTTP 500 Direct play (Emby for iOS 2.2.56) 1326.063 s plays to the end For the third row I raised the client's bitrate ceiling so the server would pick direct play (MaxStreamingBitrate=420000000). That session made 14 requests, all of them to videos/<id>/original.mkv — no m3u8, no segment request, no transcoding process started — and it reached the end of the file normally. So it is not the container, not the codec, and not the client. The one path that finishes is the only one that never reads the segment list. A player reading the file gets a real EOF; a player reading the playlist waits for a segment that cannot exist. Suggested fix Build the segment list from the end of the actual media rather than from the container's declared duration. Failing that: don't emit a trailing segment whose start lands past the last frame, and when one is requested anyway, return something terminal instead of a 500 — and certainly instead of a segfaulting encoder. Happy to provide the full server log, the ffmpeg command lines, or the sample file. This is not an exotic file: declared duration and last written frame disagree in most MKVs I have.

sorry for the dumb question but cant figure out how to add manual server what should it look like

Hi, I have exactly the same issue with Emby on my Philips TV running Titan OS. TV model: Philips 55OLED760/12 Firmware: TPN258E_V058.010.026.001 Firmware creation date: 2026/07/01 When I launch Emby, it immediately opens the “Are you ready to exit Emby?” screen. Whatever option I select, it just returns to the same menu, so the app is stuck in an infinite loop and is basically unusable. I found a workaround that is completely reproducible: I clear the TV's Internet memory. I launch Emby → it works normally. I close Emby. I launch Emby again → it immediately gets stuck on the “Are you ready to exit Emby?” screen again. If I clear the Internet memory again, Emby works again — but only for one single launch. So Emby works exactly once after clearing the TV's Internet memory, and the problem comes back on the very next launch. Unfortunately, this workaround is very inconvenient because clearing the Internet memory also logs me out of all the other apps on the TV. Titan OS does not seem to provide any option to clear only Emby's cache/data or to uninstall and reinstall the app. This makes me think that Emby may be writing some persistent local data after the first successful launch, and that this data causes the issue on the next startup. I can reproduce the problem consistently. Let me know if there is any information, logs, or additional testing I can provide to help diagnose it.

I also use custom-built Python scripts and proxies to create my libraries. For example, I have my own Aniworld.to library that scrapes all the anime from the website, including posters and descriptions. It's powered by Py Proxy and Strm Support. Best regards