All Activity

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

This is my last effort to solve this issue it work for me, the IA suggestions are target on!

For a while, I’ve been using custom Python scripts alongside local LLMs to analyze my library and automate TV/movie recommendations. It worked so well that I decided to build and share a full native Emby plugin: LLM AI Assistant. Instead of relying on simple rule-based suggestions, this plugin leverages an LLM running an autonomous tool-calling loop (agent). The model dynamically queries your Emby library, Live TV EPG, external metadata providers (TMDB, TVDB, Showbizz new releases), and the web to make smart programming and viewing recommendations. Supported backends include local Ollama (100% private on your own hardware), Ollama Cloud, and Google Gemini. What It Does The plugin adds a dedicated Recommendations page directly into the Emby main menu: Series & Movies to Record (Server-Level / Admin): Powered by a background scheduled task (LlmScheduledTask). The LLM analyzes your upcoming EPG, cross-references your existing library and whitelists/rules, and suggests what should be scheduled for recording. Recommendations are saved globally, displayed to all users, and can optionally trigger standard Emby notifications. "À regarder ce soir" / Watch Tonight (Per-User & Personalized): Computed on demand via a custom API endpoint (TonightApiService). Tailored to each individual user by cross-referencing their personal watch history, tonight's live TV guide, and recent unwatched recordings. Includes a per-user cache so the LLM isn't re-invoked on every single page view. Interactive Action Cards: Schedule: Instantly create a SeriesTimer for TV shows or a single Timer for movies. Watch: Direct one-click playback for library items or Live TV channels. Forget: Adds unwanted suggestions to a DroppedTitles list so the agent won't recommend them again. How It Works (Agentic Architecture) The LLM isn't just generating text; it acts as an agent equipped with specialized tools to inspect: Your local Emby library (already recorded/owned content) Current & upcoming EPG data External sources (TMDB, TVDB, Web searches, Showbizz feeds) Source Code & Setup GitHub Repository: https://github.com/reneboulard/LLM_AI Check out the repo for setup details, requirements, and configuration instructions. Feedback, bug reports, and suggestions are very welcome!

For a while, I’ve been using custom Python scripts alongside local LLMs to analyze my library and automate TV/movie recommendations. It worked so well that I decided to build and share a full native Emby plugin: LLM AI Assistant. Instead of relying on simple rule-based suggestions, this plugin leverages an LLM running an autonomous tool-calling loop (agent). The model dynamically queries your Emby library, Live TV EPG, external metadata providers (TMDB, TVDB, Showbizz new releases), and the web to make smart programming and viewing recommendations. Supported backends include local Ollama (100% private on your own hardware), Ollama Cloud, and Google Gemini. What It Does The plugin adds a dedicated Recommendations page directly into the Emby main menu: Series & Movies to Record (Server-Level / Admin): Powered by a background scheduled task (LlmScheduledTask). The LLM analyzes your upcoming EPG, cross-references your existing library and whitelists/rules, and suggests what should be scheduled for recording. Recommendations are saved globally, displayed to all users, and can optionally trigger standard Emby notifications. "À regarder ce soir" / Watch Tonight (Per-User & Personalized): Computed on demand via a custom API endpoint (TonightApiService). Tailored to each individual user by cross-referencing their personal watch history, tonight's live TV guide, and recent unwatched recordings. Includes a per-user cache so the LLM isn't re-invoked on every single page view. Interactive Action Cards: Schedule: Instantly create a SeriesTimer for TV shows or a single Timer for movies. Watch: Direct one-click playback for library items or Live TV channels. Forget: Adds unwanted suggestions to a DroppedTitles list so the agent won't recommend them again. How It Works (Agentic Architecture) The LLM isn't just generating text; it acts as an agent equipped with specialized tools to inspect: Your local Emby library (already recorded/owned content) Current & upcoming EPG data External sources (TMDB, TVDB, Web searches, Showbizz feeds) Source Code & Setup GitHub Repository: https://github.com/reneboulard/LLM_AI Check out the repo for setup details, requirements, and configuration instructions. Feedback, bug reports, and suggestions are very welcome!

No problem. Thanks

OK i understand. We'll take a look at this. Thanks.

This user is setup to not being shown in the profile selection. This is the appropriate section in the administrative web interface. As you can see: User "Ralf" was logged in 16 hours ago. As soon as I start the Fire TV Emby App this evening it will read "0 minutes ago" though BEFORE I selected that user on the start screen.

What profile do you manage the server with using the server web interface?

Sorry, but I am really upset. This is not the first post by me where your answers let me think that you don't really know your own software. It's not fun to report any issues here.

Hi, we'll take a look at it. Thanks.

Let me explain something: My Emby Server is only on LAN. In my LAN, there are 5 people using it. 3 of them (our children) use their tablets or (Fire-)TVs. None of them uses a user profile of the others (I know, I can see it as an admin). I for myself (as the fifth profile in the picture above) use this profile only from one device - the FireTV in the living room. My wife uses this device also - with her own profile. I access the server also from my PC, but not with my own user profile, but as a dedicated "admin", so administration is done from PC. (Reason is that I can mark TV series as "watched" when a new season is complete for easier maintenance without interfering with my "watching" profile.) So, NO OTHER logs in as user "Arby" (that's not the real name, but that's not the point) from any device in our LAN, but me from this one client. And each time I newly started the client it shows my I logged in 0(!) minutes before. NONE of my family members is able to log into my profile on another device at the exact same moment, each of the estimated 200 days a year I use Emby on my TV. So let me ask you a question: Are you kidding me?

## Motivation / Use cases There is a growing class of **legitimate** sources that Emby currently cannot integrate at all, purely because the last mile (playback) is missing: 1. **Broadcaster catch-up services and public mediatheques.** Several European public and private broadcasters serve their catch-up catalogs as standard MPEG-DASH with Widevine/PlayReady (and HLS+FairPlay for Apple). Their APIs are documented or trivially accessible, plugins could be written today - but the resulting streams are unplayable in Emby. 2. **Licensed IPTV / TV Everywhere providers.** Operators increasingly protect their live channels with DRM even for paying subscribers. A subscriber with valid credentials cannot bring those channels into their Emby Live TV setup, while the same person can watch them in any browser via EME. 3. **Corporate / education video platforms.** Internal video libraries protected with off-the-shelf DRM (e.g. via common packagers like Shaka Packager + a license service) cannot be fronted by Emby. 4. **Future-proofing Live TV.** DVB and OTT distribution is moving toward CENC-encrypted delivery. Without a DRM path, Emby's Live TV story slowly erodes. In all four cases the user *has the rights* and *has working credentials*. The only missing piece is that Emby players never learned to say "this stream is encrypted, here is the license endpoint".

Hi, yes we are looking into this. The embedded youtube player is sometimes doing this even though we are telling it not to render any subtitles.

Hi, what do you want to play with it?

You also haven't said what your ISP/internet connection is, please provide that.

I saw that Stacked was fixed in a recent update so that's great! One thing I do have issue with, does anyone know how to make CoverArt change priority when it comes to version grouping? It seems like it only goes by which version was added into the library first. I don't feel like removing my HD version from library every time I add a 4K version just so I can have the 4K treatment for when grouping.

Hi all, dont know if this is the right Place. Yesterday i experienced alot of timeouts/not loading on the Musicbrainz Page. I wrote and email to the Support because on mobile it worked. Turns out i was temp banned and it might have to do with the new problem that Metabrainz have with Bots. They changed something and that now leads to temp bans. Via support mail i got the following links: https://blog.metabrainz.org/2026/08/24/blocked-listenbrainz-services-user-agent-strings/ and the open issue for jellifyn https://github.com/lyarenei/jellyfin-plugin-listenbrainz/issues/179 maybe this helps to fix the problem. I only use Emby (4.9.5.0 windows) with the Listenbrainz & Last.FM Plugin, that might cause the Problem "api.listenbrainz.org XXX.XX.XXX.XX - - [26/Aug/2026:20:46:40 +0000] "POST /1/submit-listens HTTP/1.1" 400 541 "-" "-" api.listenbrainz.org XXX.XX.XXX.XX - - [26/Aug/2026:20:46:40 +0000] "POST /1/submit-listens HTTP/1.1" 400 559 "-" "-" api.listenbrainz.org XXX.XX.XXX.XX - - [26/Aug/2026:20:51:52 +0000] "POST /1/submit-listens HTTP/1.1" 400 566 "-" "-" api.listenbrainz.org XXX.XX.XXX.XX - - [26/Aug/2026:20:51:52 +0000] "POST /1/submit-listens HTTP/1.1" 400 529 "-" "-" api.listenbrainz.org XXX.XX.XXX.XX - - [26/Aug/2026:20:57:52 +0000] "POST /1/submit-listens HTTP/1.1" 400 575 "-" "-" api.listenbrainz.org XXX.XX.XXX.XX - - [26/Aug/2026:20:57:52 +0000] "POST /1/submit-listens HTTP/1.1" 400 550 "-" "-" Something is calling the LB API with a completely undefined user agent. One thing we've seen does that is the LB plugin for Jellyfin (which should be fixed in the latest version, so if you are using that an update might be all you need), but there might be other potential sources." thats what i got for my question if i am banned. Dont know if this is the right place for it, if not, please let me know where to post this. Thanks

Hi, yes it is doable. Thanks.

What he’s saying is that it says 0 minutes because the user logged in from a different client.