Tizen app hangs indefinitely on external Greek (el) subtitle extracted from MKV — same file works fine renamed

[GiannisValatsos 0]

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

[GiannisValatsos 0]

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