All Activity

I tried the latest build — 4.10.0.29, the current beta tag. Same setup as my codecs measurements in the other thread: a fresh install in a disposable container, nothing carried over from my server. Two sources: a real 21-minute TV episode (MKV, h264 + AC-3, 906 MB) that has been failing at the end for me for a year, and synthetic MKVs built for the purpose. Everything below comes from the server's own log and from the files in its transcoding-temp directory. The short answer: the segment is not served yet. But I can now show exactly where it stops, and the arithmetic and the stuck tail turn out to be two halves of one mechanism. 1) The list is still computed from the declared duration. The episode's container declares 1269.280 s; its last video packet is stamped 1268.184 s (ffprobe, read to EOF). The playlist the beta serves: 212 segments, all #EXTINF:6.0000 -> 1272.00 s promised That is the declared duration rounded up to whole segments — about 3.8 s promised past the last frame. A 60-second synthetic MKV whose Segment Info duration I patched to 90 s gets 15 × 6.0 s; re-encoded it gets 30 × 3.0 s. Always the declared 90, never the real 60. 2) The tail on the real episode (video copied, fMP4 segments), step by step: - during the remux: segments 0, 106, 210 -> all 200 - ffmpeg finishes on its own; the transcoding-temp directory holds all 212 segment files, 211 included - GET segment 211 -> the request never completes. The server held it for 90 seconds until my client gave up. Its own log, one request id end to end: 21:05:07.760 GET .../hls1/main/211.mp4 21:05:07.760 Starting transcoding because currentTranscodingIndex=null 21:05:07.856 ProcessRun 'StreamTranscode 011ceb' Process exited with code 0 21:06:37.769 Response completed after client disconnected. Time: 90009ms The file it was asked for was complete on disk before the request arrived, and the ffmpeg restarted to produce it exited cleanly 96 ms in. The response never came. 3) The same thing as a 500 instead of a hang, on the patched synthetic (30 segments promised, 20 producible): after ffmpeg's clean exit, segment 19 — real, sitting on disk — returns 500. So do 20 and 29, and every retry. The 500 body is FfRunException: Error starting ffmpeg wrapping an ffmpeg log that ends in a normal, complete run with exit code 0. And the extreme case, which takes the declared duration out of the picture entirely: a 3 MB MKV with an honest 60-second duration remuxes in about 25 ms — faster than the startup watchdog — and every segment request, init.mp4 included, returns that same 500, forever. So what it looks like from the outside: segment availability is decided from the state of the transcoding process, not from what is in the transcoding directory. While ffmpeg is alive, everything serves. Once it has exited — and near the end of the media it exits quickly, because there is little left to do — a clean exit is read as "Error starting ffmpeg", or, on the fMP4 path, the last segment waits on a completion signal from a process that is already gone. The declared-duration arithmetic then guarantees that every player ends its session inside exactly that zone — which I believe is this thread, the step-back 500s on a segment that had been served 200 minutes earlier, the sessions stuck at end of file, and the streams that never end server-side, all at once. At the moment of every 500 and of the hang above, everything needed was already on disk: the segment file, ffmpeg's own playlist with ENDLIST, exit code 0. If the wait checked the directory before concluding, and treated a clean exit as completion rather than as a startup failure, I believe every case above would serve. If the segment fix wasn't meant to be in 4.10.0.29 yet, happy to rerun all of this against the next build — the whole setup takes a few minutes and none of it touches my real server.

Hey everyone, Inspired by a feature request (Have an admin notes section under each user account), I built EmbyUserNotes (EUN) - a lightweight, admin-only plugin for internal notes on users and custom user groups, with CSV export/import for backup. Here are some screenshots: How to test: 1. Download EmbyUserNotes.dll below. 2. Copy it into your Emby Server "plugins" folder. 3. Restart Emby Server, then open Dashboard -> "User Notes". Security & privacy: - Admin-only, enforced server-side on every route - Never writes to Emby's own database - only reads existing user data (incl. avatar) the same way the built-in Dashboard does. - Notes are plain text only, no rich text/HTML formatting - keeps things simple and safe. - "EDIT PROFILE" links straight to Emby's own official user-edit page for the selected user. Export / Import: The export generates a single .zip file containing 3 CSV files (groups, group members, and user notes). While built-in validation checks are included, manually editing and importing modified CSV files is at your own risk. This is a fully working beta version, but since it's just a side project, further development will depend on community interest. If you'd like to help test this release, your feedback is welcome! EmbyUserNotes.dll

MediaOps GitGub repo my bad pasting the link... there you go should be ok now Official community Discord of MediaOps

@leshkraven Thanks for the feedback. I would have been surprised when it was about out app, simply because it would have come up before, but I wasn't sure enough to blame it away, because my main machine crashes on sleep, so it's always disabled. Now, didn't you say that the one change on your side was a switch to a different display? With your recent results, my best theory would be that maybe a new display requires a "refresh" or fresh save of the power settings - but that's merely a guess.

I'm sure it was not emby. But now you got me thinking: a few years ago I was using a 3rd-party screen saver on the Chromecast. Maybe it was the one showing the track title, not Google's. Unfortunately it was discontinued so I have no way of verifying it.

OK try the latest build and see if that segment is severed now. Thanks

I have no issues with Dolby Vision profile 7.6 content on Emby for Android. Have you reported a media playback issue with an example? Otherwise you're just polluting someone else's topic.

Confirmed on 4.10.0.29 — thank you, that was fast. To keep this independent of my library and my server, I measured the beta on a fresh install in a disposable container, against a synthetic HDR10 HEVC MKV (AC-3 source track) made for the purpose. Same device profile as my earlier posts, transcoding forced; the only thing changing between rows is the audio codec list in the transcoding profile. What the manifest advertises, and what the media segment actually contains according to ffprobe: requested CODECS attribute segment audio aac "avc1.640029,mp4a.40.2" aac mp3 "avc1.640029,mp4a.40.34" mp3 ac3 "avc1.640029,ac-3" ac3 eac3 "avc1.640029,ec-3" eac3 opus "avc1.640029,opus" opus dts "avc1.640029,ac-3" ac3 flac "avc1.640029,fLaC" (transcode fails to start; below) alac attribute absent alac truehd attribute absent (transcode fails to start) (The video half is avc1 in these runs because the probe deliberately forces a transcode, tonemap included — the half under test here is the audio one.) And the row that matters most to me: with my app's actual profile, aac,ac3,alac,eac3,flac, the server now keeps AC-3 and writes CODECS="…,ac-3". A described variant and passthrough at the same time — that was the practical cost of the old behaviour for nearly every file in my library, and it's gone. Thank you. A few observations from the table, in case they're useful: - The dts row is the mapping being honest, not a bug: the transcoder falls back to AC-3, the segment really is AC-3, and the attribute describes what actually comes out rather than what was asked for — which is exactly what a player needs. The only stale trace is that the TranscodingUrl still echoes AudioCodec=dts. - alac is now a clean measurement of the second point from my earlier post: the server produces a valid ALAC segment, and the whole CODECS attribute still disappears with it, including the video half it computed correctly. Emitting CODECS="avc1.640029" alone would be valid HLS and enough to rule the variant in or out. - flac advertises fLaC, but the transcode itself never starts: ffmpeg refuses FLAC in fMP4 without "-strict -2" ("experimental, add '-strict -2' if you want to use it" … "Could not write header"). truehd fails to start too. Both reproduce on the clean container, so it isn't my server's ffmpeg being odd. One more data point from this build: the "HDR 10" space round-trip from my last post is unchanged, so everything there still applies. What is new is what the patched URL yields now that AC-3 has a codec string: #EXT-X-STREAM-INF:BANDWIDTH=8871857,AVERAGE-BANDWIDTH=7393214,VIDEO-RANGE=PQ,CODECS="hvc1.2.4.L150.B0,ac-3",RESOLUTION=1920x1080,FRAME-RATE=23.976 — the untouched HDR10 copy and the passthrough audio in the same fully described variant. With that one serialisation fix, an AC-3 library gets everything I asked for at the top of this thread out of the box. Happy to run the same table against any future build.

Are you sure you weren't using the Android TV app before? It has its own music "screensaver" of sorts.

Not the way the version feature is currently designed to be used. There is a ton of discussion on this already. Our current version implementation is not intended for different editions of an item. It is intended for different qualities of the same item. The concept of "Editions" will need to be introduced to get what you want here.

It is, that's why I said thank you.

For instance, one of the steps was to go to canyouseeme.org and confirm your port is reachable (after you've completed the forwarding). Did you do that? What happened? I'm guessing it failed but you haven't told us.

New Emby server Beta release, v4.10.0.29.

It should be available now as an option in the app settings.

To my knowledge, Any TrueHD and 7.1+ in general can't be passed through on LG TVs. At least not by any native LG apps. You will need an external device connected to your AVR for that to work. Maybe it will work with connected to the TV and then through eARC, i'm not sure about that though.

New version v2.7.1.3 in the catalog. Added: 1) Ability to use multiple local Tesseract instances at once. 2) More control over CPU/GPU to improve performance on bigger machines. Fixed: 1) Episode process bars should now show the correct info.

but it's TrueHD 2.0!

Anyone who mocks without being able to refute what has been said ultimately only exposes their own narrow-mindedness – and thus becomes exactly what they are mocking.

Thankyou

TVs in general can't passthrough TrueHD and/or above 5.1 so transcode is needed. If you want TrueHD and 7.1+ you will need to use for example a Nvidia Shield connected to the AVR.

Not sure how you inserted those links into the post, but both of them are null.

Understood. I was wondering if this plug-in could be updated to 3.8.10 for this old Emby server version, so I could go on using Trakt. Thanks

Hi everyone, I’d like to share MediaOps, a free and open-source, self-hosted Discord bot I’ve been building to bring several parts of an Emby community directly into Discord. The idea started from my own setup: I wanted users to be able to search the Emby library, request missing content through Ombi, follow the status of those requests, and organize synchronized Watch Parties without having to jump between multiple interfaces. MediaOps currently includes: Emby library search through /movie and /tv Recently added media with /latest Ombi movie and TV requests directly from Discord Discord Forum integration for media requests, including automatic status/tag updates Watch Party scheduling and management Random movie selection for Watch Parties Discord Scheduled Events and RSVP notifications English and French support Role-based Discord command permissions Docker deployment with support for Unraid and Portainer A /health command for checking the MediaOps, Emby and request-provider connections Watch Parties For synchronized playback, MediaOps integrates with Emby Watch Party by Oratorian, an open-source project specifically designed to provide synchronized Watch Party sessions for Emby. Emby Watch Party by Oratorian on GitHub MediaOps does not attempt to replace or reimplement the Watch Party engine. Instead, the two projects complement each other: Emby Watch Party by Oratorian handles the synchronized Emby playback experience, while MediaOps adds the Discord orchestration around it — scheduling a party, creating Discord events, handling participation, sending reminders, generating the Watch Party session and giving participants a simple way to join. This allows an Emby community to organize the entire Watch Party from Discord while relying on Oratorian's project for the actual synchronized viewing experience. A big thanks to Oratorian for making Emby Watch Party available as an open-source project. It is what makes the synchronized playback side of MediaOps' Watch Party integration possible. Self-hosted by design MediaOps v1 is intentionally single-tenant and self-hosted. You create your own Discord Application/Bot and connect your own MediaOps instance to your own Emby, Ombi and optional Watch Party services. Your Emby and Ombi credentials remain with your deployment; there is no central MediaOps service that needs access to your server. Installation MediaOps is distributed as a Docker image through GHCR and includes Docker Compose and Unraid templates. It has also been accepted into Unraid Community Applications and should become searchable there after the next CA catalog build. The project is licensed under GPLv3 and the source code, documentation, configuration examples and installation instructions are available on GitHub. Project links GitHub: MediaOps on GitHub MediaOps Community / support: Join the MediaOps Discord MediaOps is still a young project, so feedback from other Emby users and self-hosters would be very welcome — particularly around different Emby deployments, Discord workflows and features that would make the integration more useful. Thanks! miakkia

Hello, I hae 2 LG TV. One is OLED65C8PUA which is an old 2014 model or so that only have HDMI ARC and the other one is OLED77C5PUA, 2025 model with HDMI E-ARC. Both are connected to 7.1+ Atmos Receiver (Sony STR-DN1080 and Denon AVR-X4800H). I know the 77 can do Dolby Atmos 7.1 no problem but the second a TrueHD stream is sent, even 2.0, Emby transcode it. I'm wondering why because it shouldn't. In the user guide, it says it support Dolby TrueHD on EArc http://kr.eguide.lgappstv.com/manual/w25/w25_u33/enga.html#6227 I know the 65 also support TrueHD but not on output at 7 channel. But TrueHD for 2 channel is supported. Thank you

Thanks Luke! Any ideas when the documentation might be ready, and where I should look for it if it is ready?