All Activity

What this request is NOT - Not a request to decrypt, re-stream, or strip DRM from anything - the opposite content stays encrypted end-to-end and is only ever decrypted inside the platform CDM, per the DRM vendors' own model. - Not tied to any specific streaming service. Services that only certify their own first-party clients would remain out of reach regardless - that is their business decision and not solvable by Emby. The target is the long tail of standards-based, legitimately accessible DRM sources. Emby clients can currently only play unencrypted media. I would like to request a **generic, provider-agnostic DRM playback layer**, conceptually similar to Kodi's InputStream Adaptive: the server (or a server plugin) describes *that* a stream is protected and *where* the license server lives, and each client hands the encrypted stream to the **DRM stack its platform already ships with**. No decryption keys ever touch Emby code - the platform CDM does all the work, exactly as the DRM vendors intend. This is explicitly **not** a request to circumvent or strip DRM. It is a request to *play protected content the official way*, which every modern browser, every Android device and every Apple device already supports natively. Emby just doesn't pass the necessary information through. ## 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". ## Current state (as far as I can tell) - `MediaSourceInfo` / the `PlaybackInfo` response has no notion of content protection. There is no field a server plugin could use to signal DRM to a client. - The web client plays via HTML5 `<video>` + MSE but never initializes EME (`requestMediaKeySystemAccess`), although every supported browser ships a Widevine CDM. - The Android/FireTV clients use ExoPlayer, which has **complete, mature Widevine support built in** (`MediaDrm` via `DefaultDrmSessionManager` / `MediaItem.DrmConfiguration`). Emby simply never configures it. - iOS/tvOS use AVFoundation, which supports FairPlay Streaming via `AVContentKeySession`. Again unused. - There is no way for a plugin to participate in a license exchange. So the platforms can all do it - the capability exists on every single Emby client platform, provided by the OS/browser vendor. What is missing is plumbing, not cryptography. ## Proposed design ### 1. DRM metadata in the API Extend `MediaSourceInfo` (and the LiveTV/channel equivalents) with an optional block, e.g.: ```json "DrmInfo": { "Systems": [ { "Scheme": "widevine", "LicenseServerUrl": "https://license.example.com/wv", "RequestHeaders": { "Authorization": "Bearer ..." }, "ServerCertificateBase64": "...", "PsshBase64": "..." // optional, if not in the manifest }, { "Scheme": "fairplay", "LicenseServerUrl": "https://license.example.com/fps", "CertificateUrl": "https://license.example.com/fps/cert" } ], "LicenseThroughServer": true // see section 3 } ``` Clients pick the first scheme their platform supports (Widevine on Android/web/most TVs, FairPlay on Apple platforms, PlayReady on Xbox/Windows/Tizen). A `SupportedDrmSystems` capability field in the client's device profile would let the server transcode-or-reject sensibly, mirroring how codec negotiation already works today. ### 2. Client implementation per platform - **Web:** MSE + **EME**. This is the cheapest win. The established open-source players (Shaka Player, dash.js, hls.js + eme-controller) all implement the hard parts already and are Apache/BSD licensed. Even without swapping the player, wiring `navigator.requestMediaKeySystemAccess` + a license `fetch` into the existing playback path is a well-trodden road. - **Android / Android TV / FireTV:** ExoPlayer `MediaItem.DrmConfiguration` (scheme UUID, license URL, headers). This is nearly configuration, not code - ExoPlayer handles provisioning, key rotation and renewal on its own. - **iOS / tvOS:** `AVContentKeySession` with the FairPlay application certificate + SPC/CKC exchange against the license URL. More work than Android, but a standard, well-documented pattern. - **Windows / Xbox / Samsung / LG:** EME as well (these clients are web-based), with PlayReady as the key system where Widevine is unavailable. ### 3. License proxying through the server (the plugin hook) Many real-world license servers require provider-specific authentication: session tokens, signed requests, device registration. Clients should not need to know any of that. Proposal: - New endpoint, e.g. `POST /Items/{id}/DrmLicense`, which forwards the raw license challenge to the license server and returns the response. - Server plugins get a hook (analogous to existing `IServerEntryPoint`/HTTP handler patterns) to **enrich or wrap** that exchange: add auth headers, refresh tokens, unwrap provider-specific envelopes. - Result: *all* provider logic lives in one server-side plugin; every client just POSTs opaque bytes. No client updates are ever needed for a new provider. This mirrors exactly how Kodi splits the work between a Python addon (auth, manifests) and InputStream Adaptive (playback), and it is the piece that would make Emby's plugin ecosystem genuinely extensible here. ### 4. Manifest handling For DASH this is mostly free (the PSSH lives in the manifest/init segments). For HLS, `EXT-X-KEY`/`EXT-X-SESSION-KEY` with `SAMPLE-AES` + FairPlay attributes need to be passed through untouched by any server-side proxying/remuxing. A "direct play only when DRM present" rule would be a sane v1 constraint (transcoding encrypted content is impossible by design anyway - which also keeps this feature honest: the server never sees plaintext media). ## Prior art - **Kodi InputStream Adaptive**: exactly this split (generic client-side DRM layer + per-provider addons), proven for years. - **Shaka Player / dash.js / hls.js**: production-grade EME implementations, permissively licensed. - **ExoPlayer / AVContentKeySession**: first-party DRM stacks on the two biggest client platforms, already shipped inside Emby's own apps, just not wired up. Happy to provide more technical detail, test streams (there are public Widevine/FairPlay demo endpoints, e.g. the Shaka and Axinom demo assets), or help testing early builds. Best regards

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.

Yes that would be great. Thanks.

Yes, we should limit flac audio file playback to 2 channels for all LG models. @Lukecan you please add this? I couldn't work out how to set it correctly. Thanks

not yet. still waiting for Channels support to see if they can help. I might just have to suck it up and call Verizon. The other idea on the table right now is cancel the TV part and go with YTTV.

As it's scanning, i'm loosing media art. Never seems to fix itself. However, I never let it finish because it just keeps removing all my media art and never restoring. I end up just rolling back to 4.9.3

@jcbeaver76 did you ever get this fios/tv anywhere to work for channels dvr? and then pass that to emby?.. I'm in the same boat as you.. not happy my hdhr prime cablecard even has to go.. its been simple and rock solid... for me im split 50/50 to make this work and recreate what i have now.. vs.. cancel cable and watch all my Eagles games at a bar haha... GO BIRDS! -MWS

How do I turn off trailer subtitles in 4.9.5.0? It's really annoying!

That matches what I found — thanks for confirming it. After your first message I went and read the two plugins myself, and they paint the picture you describe: whatever it is that finds the timings, they all end up setting Emby's own marker type on a chapter, so where the numbers come from really doesn't matter. One of them works around the missing end by writing a plain chapter where the credits finish, which tells you how much people want that marker to exist. The detail that settled it for me was smaller, and a bit funny: on my server the intro markers come through in Spanish and the credits one in English, because the server localises its own and a plugin doesn't. A client matching on names would have got one of them wrong for sure. Reading the type is the only thing that holds. So I have a clear picture now, and the rest is the server's move: with only a start, a skip can only ever land at the end of the file — which is exactly where anything after the credits lives. If a CreditsEnd ever turns up, it arrives on the same path I'm already reading.

Can someone walk me through this with my setup? /mnt/My Files/Docs/Backups/Emby Backups/ Username: iamhugh

If possible can I get you to try the latest beta in the catalog? I completely understand if you don't want to run a beta!

Yes, it does, but not if you set it rigidly to 4K. Then, to the box, all content is 4K – whether it’s 720p, 1080p or 2160p. Then EVERYTHING becomes 2160p. And that looks rubbish. That’s why the Shield 2019 has AI upscaling, so the box can decide for itself. As you can see, your suggestion just introduces further problems.

i update to 4.10.0.28 and folders in folder view missing I'll try to send the logs tonight.

As I understand, the server "only" handles the logins by the user and informs the clients about the last login time, yes. BUT the client unnecessarily seems to login to the server with the last user BEFORE the current user can select his/her profile, and so the last logged-in user gets the text "Vor 0 Minuten" ("0 minutes ago"), even if last user and current user aren't the same person. (The client can't know, b/c the user hasn't actively logged in yet.)

Very much agree but sadly watching 1080p and lower with the shield set to 4k introduces massive judder.

It is only a single start, because Emby only has IntroStart, IntroEnd and CreditsStart. Currently there is no CreditsEnd marker available, but i hope it will soon come.

They're set to loop, but it doesn't seem to be working—or at least, they only loop twice maybe? I left it on the Rocky Horror Picture Show item detail screen for a while and when I came back it was silent. Tried Clue and it seemed to loop, but then also went quiet. Not sure though if it did loop around a second time and then stop or if the track itself contains a second loop. embyserver.txt

That's a useful distinction, and it's exactly the shape I was asking about — thanks. For what it's worth, that's already how the app reads it. It doesn't look at a file's own chapters: it reads what the server hands back for the episode and goes by the marker type rather than the name, since the names come through localised and matching on those would only ever have worked in one language. So whatever put the markers there — the server itself, a plugin, your external tool — makes no difference at this end. Which is what makes your point the interesting one. My hesitation about credits was that every tool would leave behind something of its own shape; if they all land in the same place with a type on them, that's a different question. The piece I'd still want before saying yes to it is the value itself: on your episodes, what does a credits marker come through as, and is it a single start or a pair? Intros arrive here as a start and an end; credits I'd expect to have only a beginning, with the end being the end of the file — but I'd rather see one real example than assume and build the wrong rule.

My suggestion was a troubleshooting step to confirm the behavior but, there are some devices that may upscale better than (or be preferred over) the TV - the Shield being one.

You blanked out the IP addresses. Those should be local so nothing sensitive about them. What are they? Do they match your server address? And, one more time...

I set up port forwarding in my router menu as per the attached screenshot. I entered the IP address & default port & saved it. The saved configurations then show as per second screenshot.