LG app 1.0.51 freezes on HLS streams with video copy (remux + audio transcode): segment durations don't match

[aelleuch 0]

Hello,

Playback freezes on the Emby for LG app every time the server builds an HLS stream in which the video stream is copied (-c:v copy) and only the audio is transcoded. The TV plays a few seconds, then requests the same two segments thousands of times (about 100–200 requests per second, each aborted after a few milliseconds) and never asks for the next segment. The position stays frozen.

The same file plays fine when the server re-encodes the video. Direct play of similar files (HEVC 10-bit MKV with AAC/AC3/FLAC audio) also works. The network is healthy, so I believe the fault is in how the copy-mode HLS stream is built.

Environment

• TV: LG OLED65B39LA (webOS), Emby for LG 1.0.51 (latest)
• Server: Emby Server 4.10.0.40 in Docker (lscr.io/linuxserver/emby), Linux x64, no Premiere (software pipeline)
• Network: TV wired at 100 Mbps full duplex (0 TX errors on the switch port); server 1 Gbps; RTT 1–2 ms; TCP retransmits 0.05 % on the Emby container; per-connection delivery rate to the TV 50–87 Mbps. Direct LAN connection http://<server>:8097, no proxy.

Controlled test (same file)

File: Black Clover S02E01: MKV, HEVC Main 10 1080p, 2× Opus audio, ASS + PGS subtitles.

	Subtitles ON	Subtitles OFF
Start position	0:00	1:23.9 (new session when subtitles were switched off)
TranscodeReasons	SubtitleCodecNotSupported (PGS burn-in)	AudioCodecNotSupported
Video	re-encoded (libx264)	copied
Audio	Opus → AAC	Opus → AAC
Segment durations written by ffmpeg	3.003, 3.003, 3.003 …	59.19, 2.84, 4.38, 6.96, 8.26 …
ffmpeg target segment length (-segment_time)	3 s	6 s
TV	requested segments 0 → 42 in order, plays	requested segments 8 and 9 about 13,000 times each, frozen

Evidence: 1-*.log (copy, frozen), 2-*.log (transcode, plays). The start position differs between the two sessions, but it is not the cause: the second file below also freezes when started from 0:00.

A second file, Mushoku Tensei S02E01 (HEVC Main 10 + Opus), shows the same result with "Start over" from 0:00: video copied, segments of 9.98, 3.92, 5.51 and 7.51 s, and the TV loops on segments 0 and 1 (about 1,740 requests each) (3-*.log). It also fails when resuming mid-episode; in one such session the first segment written covered 0–137 s (log not attached).

Probable cause

In copy mode ffmpeg can only cut at keyframes. In these x265 encodes keyframes are 1–13 s apart (5-keyframes-black-clover-S02E01.txt: 89 keyframes in 300 s, gaps from 1.0 to 13.3 s). The server still sends a VOD playlist that announces fixed-length segments (4-playlist-black-clover-S02E01-copy.m3u8, requested by me through the API with parameters similar to the app's (the app's own sessions used a 6 s target): #EXT-X-TARGETDURATION:4, every #EXTINF:3.0000, while the segments are cut at keyframes). With BreakOnNonKeyFrames=False (sent by the app), the real segment boundaries don't match the playlist: the first segment after a start or resume can be about 60–137 s long. Presumably the LG player downloads the segment it expects to cover time X, gets data with other timestamps, discards it and requests it again, forever. I can't see inside the app, so this last step is inferred from the request pattern.

When the video is re-encoded, the encoder can place keyframes on the segment boundaries: every segment is exactly 3.003 s, matching the playlist, and the app plays normally.

What I ruled out

• Network: see the measurements above.
• Codec support on the TV: other HEVC Main 10 MKVs from the same library direct-play perfectly when their audio is AAC/AC3/FLAC.
• The audio transcode itself: Opus → AAC happens in both sessions of the controlled test; only the video copy vs. re-encode differs in outcome.
• Streaming quality / bitrate setting in the app: unrelated; the freeze happens at every setting.
• Turning off the user permission "Allow changing of container formats…" (remuxing): no effect, because audio is transcoded, so the server still treats it as a transcode with video copy.

Expected

Either:

• the copy-mode HLS playlist should reflect the real keyframe-aligned segment durations, or
• the server should fall back to re-encoding the video when the source's keyframe spacing can't fit the announced segment length, or
• the LG app should tolerate segments whose duration differs from EXTINF.

Steps to reproduce

1. Use a source with irregular, long keyframe intervals (e.g. an x265 anime encode; here gaps of up to 13 s), HEVC Main 10 + Opus audio in MKV.
2. Play it in Emby for LG 1.0.51 with subtitles off, so the only transcode reason is the audio.
3. The server remuxes (video copy + Opus→AAC) into HLS/TS. The TV freezes after a few seconds and loops on two segments.
4. Turn on a PGS subtitle (forces burn-in, so the video is re-encoded): it plays.

Attachments (API keys removed)

1. 1-black-clover-S02E01-subs-OFF-video-COPY-stuck.log: server requests, copy mode, frozen loop
2. 1-ffmpeg-black-clover-subs-OFF-copy.log: ffmpeg: copy, segment durations 59.19 / 2.84 / 4.38 …
3. 2-black-clover-S02E01-subs-ON-video-TRANSCODE-ok.log: same file, transcode, plays
4. 2-ffmpeg-black-clover-subs-ON-transcode.log: ffmpeg: libx264, segments 3.003 s
5. 3-mushoku-S02E01-start-over-video-COPY-stuck.log: second file, from 0:00, loop on segments 0/1
6. 3-ffmpeg-mushoku-start-over-copy.log
7. 4-playlist-black-clover-S02E01-copy.m3u8: head of a copy-mode playlist requested via the API: fixed 3.0 s EXTINF
8. 5-keyframes-black-clover-S02E01.txt: ffprobe keyframe gaps of the source

I'm happy to capture debug logs or test builds.

Thank you!

5-keyframes-black-clover-S02E01.txt 4-playlist-black-clover-S02E01-copy.m3u8 3-mushoku-S02E01-start-over-video-COPY-stuck.log 3-ffmpeg-mushoku-start-over-copy.log 2-ffmpeg-black-clover-subs-ON-transcode.log 2-black-clover-S02E01-subs-ON-video-TRANSCODE-ok.log 1-ffmpeg-black-clover-subs-OFF-copy.log 1-black-clover-S02E01-subs-OFF-video-COPY-stuck.log

Edited 27 minutes ago by aelleuch