All Activity

@MarvinB Thanks for your request. The way Emby works is that we are ffprobe-ing all new media files and are storing a subset of that data with the items in the library in the form of Emby SDK Reference: MediaSourceInfo and MediaStream. At the moment, replay gain information is not included with the media information data that is being stored. We might be able to add that, though. With regards to transcoding, the question is how it should be handled: applied and removed, not applied but preserved/carried over, not applied and dropped. I think the latter is happening at the moment - at least when a volume filter is included.

Thanks for both of these — they're bugs, not intended, and they turned out to be two different ones. The last row. When the last row isn't full, there was nothing directly below the column you were on, so the remote did nothing at all and those titles couldn't be reached. It wasn't only Movies and TV Shows — every grid in the app had it. Each row is now its own focus destination, so a short last row gets picked up whichever column you come down from. The middle poster. Also not intended. The bar at the top is centred while the rows start at the left edge, so coming down from it landed on whatever happened to be nearest — the middle poster. It now takes you back to the card you were on, and to the first one in the row the first time you go down. Both are written, and now they need the remote: focus behaviour is the one thing that never shows up in a test, only in your hand on the sofa. So no date from me — it goes out when it's actually right. Please keep them coming. This is exactly the kind of thing that's hard to catch from here.

Audio playback has absolutely nothing to do with Dolby Vision. The Amlogic S922X-J chip is required for FEL. Very few manufacturers have this, though. And at the moment, it ONLY works with CoreELEC. With the right programming, however, it would also be possible on Android. It’s just that at the moment, most devices are Android boxes, not Android TV boxes like the Shield. The FEL layer provides additional information. For example, with older films like *Braveheart*, which have been remastered, you’ll see a very slight pinkish tinge to the sky without the FEL layer. Not with FEL. You simply have to see it for yourself. So you can’t just say, ‘The difference is so slight, it certainly won’t be noticeable.’ As I said, DV 7 FEL is a topic in its own right. But fundamental problems could generally be solved with DirectPlay. It’s just that an ebr doesn’t see it that way.

Please! In the same ugly boat here. Like sucker punching all that hard work in the gut. Would love to also re-bring up the request to get rid of the folder overlay icons as well.

edit

Just got the new update ver 2.0.9 (1) and this now works, thanks. Could we maybe get a clock displayed in the next update?

Ui bug maybe when you go down on the homepage it always goes to the middle poster and not the left ( not sure if this is intended ) but when you are in the tv or movie section it wil not go down to the last row if there is no poster under where you are focused .

Excellent. Such a quick response. Yeah, the runtime isn't a big deal. I actually don't think I have ever seen it listed in other apps any way. Probably will look cleaner without it to be honest. I do love the UI layout in general. The images look really nice and clean. I will be watching several movies this weekend so will report anything regarding playback. I don't have very much 4K content that I haven't already watched. It's mostly just 1080p standard blu-ray rips with 5.1 audio. I am playing mostly on a 1080 projector anyway and is why I don't much bother with 4K stuff anymore. My TV in the bedroom is 4K but don't watch in there as much. I am also playing to 2 Homepod Pros so audio becomes a big deal on most apps. Yours plays back just fine so far.

I will try to do that for the next build, but please remember I'm limited by what the plugin allows. I will keep you updated.

yes it is sad.. but there are possibilities... If your english is good I can give you access to the beta and you can at least try it out. Right now, I am working on sound-leveling with French language availability next on the list If you like the beta, you can assist me with the migration to French language and that is a win for both of us. Let me know your thoughts. thank you

I am the developer of Ear Wax, an Alexa music client that streams tracks from Emby Server 4.9.3.0. Emby’s FFmpeg transcode log confirms that it detects embedded ReplayGain tags. For example: REPLAYGAIN_TRACK_GAIN: -2.85 dB REPLAYGAIN_TRACK_PEAK: 0.861816 REPLAYGAIN_ALBUM_GAIN: -2.16 dB REPLAYGAIN_ALBUM_PEAK: 1.000000 The corresponding item is available through /emby/Audio/{Id}/stream.mp3, but requesting the complete item through /emby/Users/{UserId}/Items/{Id} does not return any gain, peak, ReplayGain, loudness, or normalization fields. Is there a supported API endpoint or optional field that returns these embedded ReplayGain values before playback? If not, is there a supported audio-streaming parameter that tells Emby’s transcoder to apply track ReplayGain during progressive MP3 transcoding? The goal is track-to-track volume consistency. I would prefer to use Emby’s existing metadata and transcoder without requiring users to install a custom plugin or modify their media files. I am specifically looking for: An API-accessible track gain and peak. A documented way to apply that gain during audio transcoding. Confirmation whether these capabilities are unavailable in Emby 4.9.3.0. Thank you

Good catch, and yes — it's changed, and a bit further than you asked. That line was deliberate, which is the interesting part: the shelf merges "continue watching" and "up next" into one row, and the metadata line was what told them apart. Your report makes it obvious the label was doing nothing useful — a next-up card already has no progress bar, so the text was saying twice what the card already said, and never saying the one thing you were looking for. So episodes now read the same in both states, the way you'd expect: The Big Bang Theory S1:E8 - The Grasshopper Experiment with the progress bar as the only difference between one you've started and one that's next. One thing that costs you, and I'd rather point it out than have you notice it: the runtime is gone from that line — the part you said was good. The bar now does that job on its own. If you miss it once you're living with it, say so; you're the one who looked closely enough to spot the first problem. And thank you for the skip intro/credits report — that's the first time I've heard those two work in someone else's house, which is worth more than it sounds.

Should i hold out hope for options for series images to carry all the functionality via image processing not web hacks, in the future?

Audio track handling? With direct play a bit to bit perfect copy is sendt to the player so i don't see how audio could be any worse unless it needs transcoding. Again, not talking about HDR10 fallback. I'm saying that the difference between Dolby Vision layer 7 (FEL) and Layer 8 (Not FEL) is so small that most people would fail a blind test between the two. Also, i'm no expert at this but i don't think it's so much an Emby problem as it is with the players and devices being used. Android doesn't support FEL and neither does AppleTV (because of licensing i bet) . There's simply nothing Emby can do about adding FEL to those devices when they don't support it to start with. If they found a work around to support FEL they would break a lot of licenses and be in serious legal trouble. The reason other media servers, devices and players might be able to playback something like FEL is because they are open source and maintained by a lot of different people so it's impossible for companies to stop them. Good luck suing a company in China. Direct play in Emby is precisely that, a bit to bit perfect transfer of a file to the player. If the player/device doesn't support the format sendt then Emby will transcode it on the fly to a supported format. So direct play is already available for use in Emby.

Thanks for the constructive feedback and the insights regarding the TV and AVR behavior. You raise a valid point about how modern displays handle resolution switching—especially since manufacturers sometimes implement EDID or HDMI handshake logic differently compared to older generations. Regarding the ExoPlayer and external players like VLC: While switching to an external player is technically possible, it unfortunately breaks the seamless Emby integration (such as server sync, direct resuming, and proper audio track handling), which is why many users prefer to avoid it. As for the point about FEL and 12-bit panels: It's true that very few consumer TVs feature a true native 12-bit panel (most high-end sets operate on 10-bit or use FRC). However, the primary benefit of the Full Enhancement Layer isn't just about outputting a 12-bit signal. The FEL stream contains critical residual data, targeted luma/chroma corrections, and specific mastering metadata that directly improves the 10-bit output image compared to a standard fallback layer. It really comes down to whether someone wants a solution that "just plays the file" or one that preserves the complete data integrity of the original master. FEL (Full Enhancement Layer) is the most technically sophisticated variant of Dolby Vision (Profile 7), as used primarily on UHD Blu-rays. Unlike standard Dolby Vision profiles, the FEL layer contains not only dynamic brightness metadata, but also genuine additional image information and image corrections (residual data) to bring the video even closer to the master. Why playback is so difficult: Most standard streaming boxes and apps (such as Android TV, Fire TV or Apple TV) do not natively support FEL files. They ignore the Enhancement Layer completely and often play back only the basic HDR10 image – a so-called ‘core fallback’ occurs. Players that offer genuine FEL support: Ugoos AM6B Plus (with CoreELEC): Considered within the community to be the only consumer-grade hardware currently capable of outputting Dolby Vision Profile 7 FEL losslessly and natively. Certain Amlogic-based media players (running Linux/CoreELEC): Similar SoC platforms can process FEL, provided the software architecture (such as CoreELEC) accesses the hardware interfaces directly. Oppo UDP-203 / UDP-205 (and identical clones such as the M92 / Reavon): Dedicated high-end UHD disc players capable of correctly processing the signal from physical media or ISOs, including FEL. But actually, FEL is a topic in its own right. That said, a good programmer could implement it on an Android platform too. Once people properly understand what it actually is and what it can do, the growth would be enormous. Ultimately, however, one thing would be absolutely essential here too: direct playback.

@vdatanet Just checked out the new update. Nice! Skip intro and credits pull up correctly and work very well. Will have more time to test further tonight and tomorrow. I plan to give the app a good run. One UI point I noticed and not sure if on purpose or not - on the "Continue Watching" Row, instead of showing the name of the episode under the thumb image it says "Up Next" (I believe in most apps that is where it would show the episode name. It then shows the season number/episode number and episode runtime (which is good). Is it possible to have it display the episode name instead of the "Up Next"?

That's the one I was waiting for — thank you. A DV set switching over is the one thing I had no way to test here, and it was the last open question in 1.4. And thanks for the picture — it arrived, and it's exactly the screen I needed: the line reads "signalled to the TV" and your set agrees with it. For anyone else here with a Dolby Vision TV: there's nothing to do, it's already in 1.4. The only report I'd still like to see is the opposite one — if the Playback Information screen ever says Dolby Vision was signalled and then withdrawn, that's the case I can't reproduce here.

Happy to report that everything seems to be working . My TV DV indicator does indeed come on. sent a pic in pm if you still wanted to see it thanks

HW tone mapping is broken in the stable branch. Feel free to try the beta release though you might want to search the forum to find which ones actually work. Regressions happen...

I just updated to the latest Tizen version but the problem still persists.

Emby wants to use a resolution of lets say 3840x1600, the TV can't do that resolution so Emby falls back to 1080p which is the safest thing to do. Pretty sure the scaling will be done on the TV and not Emby. I guess a "closer to" rule based on display device EDID could be made in Emby to avoid that but falling back is always the safest thing to do. Not sure i understand you here. Direct play is bit to bit perfect copy sendt to the player. The player used might strip things like the FEL layer but that is the player/device's problem IMO. I agree that watchtime tracking is a problem with external players, i would love better integration with for example VLC, it is how ever a solution (a bit flawed i agree) to people wanting to use other players. Not talking about falling back to normal HD. What i meant was that the difference between Dolby Vision with and without FEL on normal TVs is so minute that a blind test would be most about luck other than actual visual differences unless you have a studio display.

No.it's still there. What type of subtitles are you trying to display? The ability to adjust the offset is only available for some subtitle types

Yup, tried that... No dice

The reference to the AVR or TV signal processing does not go far enough here. If the app misinterprets or downscales the native resolution even when the input chain is correctly connected, the problem lies with the software’s stream handling and not with the underlying hardware. As for external players such as VLC: this does not fully resolve the underlying problem either. External players disrupt seamless integration with the Emby interface (e.g. lack of server synchronisation, erratic playback resumption or lost audio tracks). This is precisely why a clean Direct Play architecture, which works exactly like specialised hardware players with CoreELEC, is irreplaceable. On the subject of FEL and 12-bit panels: Dolby Vision Profile 7 FEL is not simply about the panel’s colour depth, but rather that the Enhancement Layers (FEL) contain additional image information, metadata and bitrate corrections which are completely lost when falling back solely to HDR10 or inferior processing layers. Even if the panel operates internally at 10-bit, the system discards essential data from the master without a genuine FEL.

Title: Tizen app hangs indefinitely on external Greek (el) subtitle extracted from MKV — same file works fine renamed to gre Environment: Emby Server: 4.9.5 Emby for Samsung: 2.2.8 TV: Samsung QE65QN85CATXXH, Tizen 9.0 Server: Docker container (emby/embyserver) on Debian LXC (Proxmox), VAAPI hardware transcoding Summary: An external .srt subtitle file extracted from an MKV source and tagged as Greek causes the Emby for Samsung app to hang indefinitely (infinite loading spinner) shortly after playback starts, while the exact same byte-for-byte file content works perfectly when simply renamed with a different language suffix. Steps to reproduce: Extract a Greek subtitle track directly from an MKV file (tested with both ffmpeg -map and mkvextract — same result with either tool) and save it as an external sidecar moviename.ell.srt (or .el.srt) next to the video. Play the item on Emby for Samsung, with the Greek subtitle track selected (or even just present in the folder — same behavior). Playback starts, video plays for a few seconds (first 1-2 HLS segments load fine), then hangs on an infinite spinner. No further segment requests are made by the client. After ~12-13 seconds the client itself sends a Stopped event with Position: 0. Workaround found: Renaming the identical extracted file (byte-for-byte, confirmed via diff) from .ell.srt to .gre.srt makes it play perfectly. Notably, this is not a general issue with extracted subtitles, nor with Greek subtitles as a whole: A Greek subtitle machine-translated via the OpenSubtitles website (translated from a French subtitle, not extracted from the source MKV) works fine regardless of whether it's named .ell.srt or .gre.srt. An external French subtitle extracted from the same MKV file, using the same extraction tools, works fine regardless of naming. So the bug appears specific to the combination of: (a) subtitle track originating from MKV extraction, and (b) Greek language, and (c) the el/ell language tag specifically. I was unable to find any structural difference between the extracted and non-extracted Greek files that would explain this (checked: BOM, line endings, Unicode normalization NFC/NFD, trailing newline, encoding validity via iconv — all identical/clean in both cases). Server-side log evidence (embyserver.txt): The SRT→WebVTT conversion succeeds and is delivered correctly to the client both times this was tested: Info SubtitleService: GET .../Subtitles/2/Stream.vtt?AddVttTimeMap=true... Info SubtitleService: Response 200 to host1. ... Content-Length=38131 Video HLS segments also download successfully: GET .../hls1/main/0.ts → 200 OK GET .../hls1/main/1.ts → 200 OK Then — nothing. No further segment requests. ~12s later: Info SessionManager: Playback stopped reported by app Emby for Samsung 2.2.8 ... Position: 0 ms. This indicates the server-side pipeline (SRT extraction, VTT conversion, HTTP delivery) is functioning correctly in all cases. The hang occurs strictly client-side, after the Tizen app has already received a valid VTT subtitle stream — and appears tied specifically to how the el-tagged track from an MKV-extracted source is handled internally by the app. My best guess is something related to font loading / text shaping triggered differently depending on subtitle origin, but I don't have visibility into the client code to confirm. Question: Is this a known issue? Has anything changed in beta builds of Emby for Samsung regarding Greek subtitle handling? Happy to provide the full embyserver.txt log or the exact test .srt file if useful for reproduction. embyserver.txt