All Activity

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

It's most likely a problems with TV's and AVR's. Setting Kodi to match resolution also sets the TV to 1080p for me. My old Sony with Android could correctly match resolutions to the source, my new LG doesn't do that. I havn't tested connecting a computer to the TV and see what it does when setting different resolutions though but that could prove/disprove if it's the TV or the match resolution feature. If you are not satisfied with the player that Emby uses (Exoplayer made by Google i believe for Android) then you can set it to use another one, like for example VLC. I would also argue that not having FEL doesn't change much, as i doubt many TVs (if any) use a 12bit panel anyway.

1.5% failure rate (emby/provider data can not be well reconcilled), thats a bit too much manual work, but the large cohorts are probably auto resolvable.

This is a just an alpha, its more of an idea than a fully formed solution. But if your up for an adventure (after you have backed up) then id be interested in feedback. one thing it does do well is find tonnes of provider errors, TVDB is a mess and TMDB a bit better but still lots of errors. I guess thats the point to crowd source correction of the providers.

This bug is still present in the Emby version 2.2.57.

Treatments are different because I decided to change the style between when I took that first screenshot and the second. The rest of it still stands though. Metadata refresh does nothing, library scan does nothing. - Which ever is scanned in first takes priority when merged. If your experience is different then I have no idea. Lets say for example I have a HD film in the library and then I add a 4K version, when grouping the HD poster/treatment will be what is shown to me (HD+4K access) If the 4K version was added before the HD version then the 4K poster/treatment is what is shown to user with HD+4K access - just me, and HD only users see the HD one. So it defines which is the "Master" as to what is scanned in first - Which does make sense.

0.1.17 Improve task performance (8 mins on 150000 person library, after provider fetching on my 6 core cpu, still uses GBs of memory)

Update date/time local: The plugin now automatically matches your Emby 'Date/time locale' setting (stored in your browser's local storage). Fallback to browser's default format if it's set to Auto. EmbyUserNotes.dllv1.0.1 beta

Good question, and it caught a real hole: everything I had been writing was about the last segment, and 220 is not the last one. Here is 220 measured four ways on 4.9.5.0, all on the same file: requested 216..221 in order 220 -> 200 (and 221 fails) fresh session, jumping straight to it 220 -> 500 (500 on every retry; 219 -> 200) real player, no seeking 220 -> 200 (36 ms) (and 221 -> 200, 173 ms) real player, after one seek 220 -> 200 (42 ms) (and 221 -> 500) So 220 is not special, and neither is being last. What separates the rows is how the request arrives: near the end of a file, a request that comes in sequence is answered, and one that arrives on its own — a jump, or a step back after a failure — starts a fresh transcode, and that is the one that doesn't come back. Which is exactly what my first post was describing without realising it. The player asked for 221, got nothing, and stepped back to 220. That step back is itself a jump, so 220 was then being asked of a fresh transcode near the end of the media, and it returned 500 each time it tried. One more measurement, in case it saves you time, though this one is from the beta in a container rather than my production box: a restart producing segment 210 wrote the file, logged SegmentComplete for it, and exited with code 0 — and the request still returned 500, in 60 ms. So whatever this is, it does not look like an inability to produce the segment. I'm not going to offer you a mechanism for it. I've proposed three in two days and measured all three dead, so I'd rather hand you the table and stop there.

This is what I meant in the first post when I said it should be version-agnostic. If it's just adding the item, it doesn't matter which version is added, so it would work. But since it does only add one specific version, it needs to ask which I want to add because I keep running into scenarios where the user adding items to the playlist has different quality-access permissions to the user watching it. My remote users don't have access to higher-quality versions to save on transcoding, and my user account doesn't have access to lower-quality versions to save on clutter. My admin account can see everything, so if I do any playlist work from the admin account I keep running into scenarios where it adds a version the relevant user account has no access to.

I owe you a correction, and this time I have the control case that my last two posts were missing. I said the trailing segment cannot be served. That is not true, and here is the same file from my first post — the one declaring 1326.336 s — played twice on 4.9.5.0 through your web client, four minutes apart. A. Played straight through, no seeking: 07:13:27.849 segment 219 -> 200 (2 ms) 07:13:27.937 segment 220 -> 200 (36 ms) 07:13:28.147 segment 221 -> 200 (173 ms) session then advanced to the next item on its own So the file plays to the end and the session tears down properly. My apologies for saying otherwise. B. Same file, same session type, this time with one seek to about 1289 s: 07:17:16.613 segment 220 -> 200 (42 ms) 07:17:40.141 segment 221 -> 500 (68 ms) logged as "Error processing request" 07:17:41 client re-requests master.m3u8 and continues on a fresh transcode 07:17:41-42 segments 438-441 -> 200 (737, 465, 363, 404 ms) 07:18:12.498 segment 442 -> requested, and no response line ever follows The session then sat at position 1328.17 s of a 1326.34 s item — past its own declared end — with IsPaused=False and the transcode still registered, for 6 minutes 16 seconds and counting when I stopped sampling. Eleven samples thirty seconds apart, the same position to the hundredth each time. The log shows 31 restarts with -ss during that playback, the last two at 00:21:54 and 00:22:06. That is the whole of my original report — the 500, the retry, the request that never returns, the session left playing on the dashboard — and it reproduces on demand with one seek. So the accurate version of my complaint is narrower than what I have been writing, and I would rather state it correctly: The segment list is computed from the declared duration and never checked against the media, so the last entry can be an interval the file does not contain. In continuous playback that costs nothing, because the transcode that is already running serves it. After a seek, the client asks a fresh transcode for that interval, and it cannot be produced. The arithmetic behind it is unchanged: 222 segments advertised as 1332.0 s for an item of 1326.336 s, with the final #EXTINF still claiming 6.0000 s of a stretch that can hold at most 0.336 s. Two corrections I also owe you, from my previous post. First, I claimed the cause was that ffmpeg never announces the final segment of a run (SegmentComplete). The observation is true, but as the cause it is wrong: segment 210 is announced by its restart, the file is written, ffmpeg exits cleanly, and the answer is still 500 in 60 ms. Second, both my earlier posts say the server "held the request for 90 seconds" — that was my own client's timeout, not a server limit, as your log's "after client disconnected" says plainly. To reproduce, about two minutes: take a file whose declared duration is a little past a segment boundary, play it to the end (it works), then play it again and seek to within thirty seconds of the end. The second run fails at the last segment. I am not offering a mechanism this time. I have proposed three in two days and measurement killed all three; the pair above is what I can defend.

Being able to see if there are extras and what they are is more relevant to me personally so I would really appreciate an option to have Movie and Episode level Extras menu above the Cast & Crew and More From Season X menus respectively.

Hi, we’ll take a look at it. Thanks for reporting. And thanks for the feedback !

sad i can't found it in french alexa store !

In Emby, the "Date time local" setting is stored in the browser's local storage rather than on the server. Whenever "Cookies and other site data" are cleared—or if you open Emby from a different browser for the first time—this setting defaults back to "Auto". I'll try to update the plugin so that it reads the format directly from the Emby web app's local storage, with a fallback to the browser's settings if the local storage entry is empty (as it is when set to "Auto" or on a fresh session).

This started about four months ago as a simple personal Docker container. I had stopped using Kodi, but I found that Emby was lacking features I really missed—and that was the main reason I started this project. Eventually, I decided to create a plugin version and share it with everyone. It ended up turning into a pretty complex plugin that I genuinely enjoyed building. I couldn't have pulled it off without everyone's input and feedback. Thanks!

Playlists still use file path, not item ID.