MKV playback error at end of file in Transcoding and Direct Streaming – session stuck on dashboard

[vdatanet 1663]

Hi,

I’m experiencing an issue where many MKV files cause an error right at the end of playback when using Emby. This happens both when the server is Transcoding and also when it is doing Direct Streaming (repackaging without conversion). The same files play to completion without any issues in Jellyfin and Plex, and in Emby they also work perfectly when they are Direct Played.

Because of the error at the end:

• The playback session remains “stuck” as active on the Dashboard / Now Playing.
• The playback queue does not advance to the next item.
• I have to manually stop or clear the session.

Behavior

1. Direct Play (works)

• Playback reaches the end normally.
• The session stops correctly.
• The next item in the queue starts as expected.

2. Direct Streaming (remuxing) – fails

• Playback reaches the final seconds.
• Emby shows an error or silently fails right before EOF.
• The session gets stuck on the Dashboard.
• Queue does not continue to the next file.

3. Transcoding – fails

• Same behavior as Direct Streaming:
  • Error at end-of-file
  • Session stuck
  • Queue does not progress

Additional details

• The issue affects multiple MKV files, not just one.
• The exact same MKVs finish correctly in Plex and Jellyfin (even when they transcode/remux).
• This seems related to how Emby handles MKV EOF (end-of-file) when not doing a full Direct Play.
• Other users in the forum have reported the same behavior.

What I have tested

• Reproduced across several MKVs.
• Works perfectly in Emby only if the file is Direct Played.
• Fails in both Direct Streaming and Transcoding, with different clients.
• Tested with different network connections and playback settings.

Happy to provide whatever is needed to help diagnose this issue.

Thanks in advance.

Here is an example:

 

[Blueskies278 102]

3 hours ago, vdatanet said:

 

Hi,

I’m experiencing an issue where many MKV files cause an error right at the end of playback when using Emby. This happens both when the server is Transcoding and also when it is doing Direct Streaming (repackaging without conversion). The same files play to completion without any issues in Jellyfin and Plex, and in Emby they also work perfectly when they are Direct Played.

Because of the error at the end:

• The playback session remains “stuck” as active on the Dashboard / Now Playing.
• The playback queue does not advance to the next item.
• I have to manually stop or clear the session.

Behavior

1. Direct Play (works)

• Playback reaches the end normally.
• The session stops correctly.
• The next item in the queue starts as expected.

2. Direct Streaming (remuxing) – fails

• Playback reaches the final seconds.
• Emby shows an error or silently fails right before EOF.
• The session gets stuck on the Dashboard.
• Queue does not continue to the next file.

3. Transcoding – fails

• Same behavior as Direct Streaming:
  • Error at end-of-file
  • Session stuck
  • Queue does not progress

Additional details

• The issue affects multiple MKV files, not just one.
• The exact same MKVs finish correctly in Plex and Jellyfin (even when they transcode/remux).
• This seems related to how Emby handles MKV EOF (end-of-file) when not doing a full Direct Play.
• Other users in the forum have reported the same behavior.

What I have tested

• Reproduced across several MKVs.
• Works perfectly in Emby only if the file is Direct Played.
• Fails in both Direct Streaming and Transcoding, with different clients.
• Tested with different network connections and playback settings.

Happy to provide whatever is needed to help diagnose this issue.

Thanks in advance.

Here is an example:

 

I was beginning to think I was the only one having this issue 

Thank you for the extensive tests.

[vdatanet 1663]

@Luke

Emby Server 4.9.5.0 (Linux, .NET 8). Coming back to this with numbers, and with a test that I think isolates the cause. Everything below is one server, one file, one afternoon, using Emby's own clients.

The file

A 22-minute episode, H.264 1080p 23.976 fps + AC3 stereo, in MKV. The container declares RunTimeTicks 13263360000 = 1326.336 s. The last segment ffmpeg actually writes reports:

SegmentComplete=video:0 Index=220 Start=0.000000 End=1325.365000 Duration=1325.365000
                offset_pts=0 start_pts=0 Frames=136

So the written media stops at 1325.365 s and the container claims 1326.336 s. That 0.971 s disagreement is where everything below comes from.

What the playlist promises

The segment list is built from the declared duration, so it always holds one more segment than the media can fill:

6-second segments:  1326.336 / 6 = 221.056  -> list runs to index 221 (1326.000 -> 1326.336)
3-second segments:  1326.336 / 3 = 442.112  -> list runs to index 442 (same 0.336 s)

What happens when a client asks for that segment

In both cases the server starts a fresh ffmpeg with -ss 00:22:06.000, which is 0.971 s past the end of the written media. What happens next depends on the path.

Transcoding — Emby Web 4.9.5.0 on Safari, h264 → hevc_vaapi, 3-second segments:

15:17:18  GET .../hls1/main/442.ts   -> no response; held open 10 s, client disconnects
          ProcessRun 'StreamTranscode aaa338' Process exited with code 139 - Failed
15:17:28  retry -> ... exited with code 139 - Failed
15:17:38  retry -> ... exited with code 139 - Failed
15:17:48  retry -> ... exited with code 139 - Failed
15:17:58  retry -> ... exited with code 139 - Failed
15:17:59  Playback stopped ... Position: 1325323 ms

Exit code 139 is SIGSEGV. Five new ffmpeg processes, five segfaults, in forty seconds. Those are the only five 139s anywhere in the log, and all five are on this one segment.

Direct streaming / remuxing (-c:v copy -c:a copy), 6-second segments: ffmpeg exits with code 0 and writes nothing, and the server answers 500 instead:

14:52:10 ... 14:52:41   segment 221 -> 500   (9 times, ~every 5 s)
14:53:00 ... 14:53:31   segment 220 -> 500   (9 times, ~every 5 s)

Segments 209–219 all returned 200, and 220 returned 200 the first time it was requested. Each 500 is preceded by AppendExtraLogData - File Deleted, and each retry starts a new ffmpeg process which then exits with no error at all.

Why the session sticks on the dashboard

This is the part that gave this thread its title, and I think it follows directly. The player never receives an end of stream. It receives a playlist promising a segment that never arrives, so it keeps retrying and never reports playback as finished:

14:52:10  first 500 on the tail segment
14:52:24  Playback progress (StateChange) ...
14:52:34  Playback progress (StateChange) ...
14:52:44  Playback progress (StateChange) ...
14:52:54  Playback progress (StateChange) ...
14:54:32  PlaySession ... has gone idle while playing
14:54:32  Removed playSession ...
14:59:51  Playback stopped ... playing Unnamed item. Position: 1325732 ms
14:59:51  DELETE /Videos/ActiveEncodings ...

The session reports as playing for 2 minutes 22 seconds after the media is effectively over, and the server ends it with an idle timeout rather than because the stream ended. I suspect this is also the mechanism behind the "streaming not ending server-side / multiple streams on one user" report: on this path nothing is ever ended by playback completing.

The test that isolates it

Same file, same server, same afternoon, three paths:

Path	Last position	Outcome
HLS, transcoding (Emby Web, Safari)	1325.323 s	stuck, 5× ffmpeg SIGSEGV
HLS, direct stream / remux	1325.732 s	stuck, 18× HTTP 500
Direct play (Emby for iOS 2.2.56)	1326.063 s	plays to the end

For the third row I raised the client's bitrate ceiling so the server would pick direct play (MaxStreamingBitrate=420000000). That session made 14 requests, all of them to videos/<id>/original.mkv — no m3u8, no segment request, no transcoding process started — and it reached the end of the file normally.

So it is not the container, not the codec, and not the client. The one path that finishes is the only one that never reads the segment list. A player reading the file gets a real EOF; a player reading the playlist waits for a segment that cannot exist.

Suggested fix

Build the segment list from the end of the actual media rather than from the container's declared duration. Failing that: don't emit a trailing segment whose start lands past the last frame, and when one is requested anyway, return something terminal instead of a 500 — and certainly instead of a segfaulting encoder.

Happy to provide the full server log, the ffmpeg command lines, or the sample file. This is not an exotic file: declared duration and last written frame disagree in most MKVs I have.

Edited 53 minutes ago by vdatanet