Emby 4.8.11.0 Crash During DirectStream - FFmpeg "No such file or directory" Error

[fahad92 7]

 

Hello @Luke

Since I have updated to 4.8.11 , I had  multiple crashes all for the same reason 

To make it short below summary generated by Ai which the Ai checked everything and found the root cause likely a bug in Emby 4.8.11.0 where the transcoding directory is deleted prematurely, possibly due to a cleanup timing issue during the 5-minute gap.

is there anything I can do? Or wait for future updates if this correct report.

Emby Version: 4.8.11.0
Operating System: Ubuntu (kernel 5.15.0-76-generic)
Setup: .NET 6.0.36, 8-core CPU, software-only transcoding (no hardware acceleration, Matrox G200EH GPU detected but failed VAAPI), 30 TB free disk space, permissions confirmed fine.

Issue Description:
Emby server crashed during DirectStream playback of “Tv show name S25E01” (MKV, 1080p H.264, AC3 5.1, 22:24 duration) on an Apple TV client (subtitles disabled with -sn). The server became unresponsive, requiring a manual restart after which playback resumed normally.

Details of the Crash:

• Two FFmpeg processes were involved:

  First at 00:05:41: Succeeded, remuxed 2:45 of the video to HLS TS segments in /config/transcoding-temp/055DB2/, exited cleanly at 00:05:42.

  Second at 00:10:43: Sought to 00:22:24.000 (file end), failed immediately with the error “Could not write header for output file #0: No such file or directory,” lasted 0.013 seconds.

• No scheduled tasks were running at the crash time (confirmed via logs).
• Disk space (30 TB free) and permissions are fine.

Analysis:
The error suggests the transcoding directory /config/transcoding-temp/055DB2/ was not found when the second FFmpeg process tried to write to it. Research indicates a potential bug in Emby 4.8.11.0 where the directory is deleted prematurely during cleanup, possibly in the 5-minute gap between the two FFmpeg processes. This aligns with:

• Emby documentation stating transcoding contents are deleted when playback stops (Transcoding | Emby Documentation).
• Forum reports of cleanup issues (how often is transcoding-temp cleaned?).
• Similar issues in Jellyfin, a fork of Emby (transcoding-temp folder not cleanup up well).
• Emby 4.8.11.0 release notes mentioning “Various fixes with transcoding disk space cleanup,” suggesting prior issues (Emby GitHub Releases).

Other possibilities like file descriptor exhaustion were considered but seem less likely given the error message. The negative segment_time_delta -00:22:24.000 in the FFmpeg command might also be a factor, as FFmpeg docs suggest it should be non-negative (FFmpeg Formats Documentation).

Steps Taken:

• Confirmed disk space and permissions are not the issue.
• Reviewed logs: No scheduled tasks ran at the crash time, and no logs were recorded between 00:10:43 and the restart at 12:54:55, indicating a crash.

 

Thank you

Edited April 11, 2025 by fahad92

[Luke 43389]

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

[Luke 43389]

Hi @fahad92we are looking into this. Thanks.

[daddystorm 0]

I have reproduced a similar missing-transcoding-directory error on Emby Server 4.10.0.40, 4.10.1.0 and 4.11.0.6 beta. I cannot confirm that it has the same underlying cause as the original report, but this isolated reproduction may help.

Test setup

Official Docker images, without third-party plugins (bundled Emby plugins remain). A synthetic 40-minute H.264/AAC MKV, with no subtitles, is served over loopback HTTP with HEAD and byte-range support. The environment has no outbound network access. Copies of existing databases/settings were used; production was not modified.

HLS video transcoding is requested through PlaybackInfo using H.264/AAC and MPEG-TS, with a 7 Mbps client limit. The synthetic video is 320x180 at 24 fps and much lower bitrate; the limit is not its actual output bitrate. Video is transcoded; AAC can be stream-copied.

Reproduction

1. Fetch the HLS media playlist.
2. Begin requesting segment 753, corresponding to approximately 37:39.
3. Cancel that HTTP request while it is still pending.
4. Request segment 60, approximately 3:00, using the same PlaySessionId.

Expected: the new seek returns a playable segment.
Actual: the subsequent request returns HTTP 500. FFmpeg reports "Could not write header ... No such file or directory."

Observed directory lifecycle

Polling the output directory every 20 ms shows that it is removed after cancellation. The next FFmpeg process attempts to write to the same directory, without it being recreated beforehand.

One observed sequence on 4.10.0.40, in UTC:
- Directory 0B13B5 created: 20:46:50.495
- Directory removed: 20:46:53.598
- Subsequent FFmpeg write fails: 20:46:55.313

The exact internal Emby method responsible has not been identified.

Control tests

- Sequential, completed seeks work.
- The same synthetic file provided as a native local File source works, including cancellation while the request is pending (verified on 4.10.0.40).
- With the HTTP source, adding a fixed 0.8-second delay before GET responses reproduces the failure consistently when cancellation occurs after 0.05, 0.25 or 1.5 seconds.
- The HTTP-source failure was reproduced on all three Emby versions listed above.
- No third-party integration, subtitles or external streaming service is required. No Sessions/Playing reports are sent during these tests.

Unlike the original report, this reproduction establishes an HTTP 500 playback failure, not a complete server crash.

Attached is a sanitized ZIP containing the server logs, corresponding FFmpeg logs and test reports for all three versions, plus the local-file control report. The README explains the redactions and maps the directory-removal example to its FFmpeg log. Credentials and identifying information are removed; compressed ExtraData payloads are omitted. Timestamps, error traces, FFmpeg commands and transcoding-directory names are retained.

A reproduction script can also be prepared for sharing if useful.

emby-hls-cancellation-sanitized-logs.zip

[Luke 43389]

On 10/10/2026 at 3:49 PM, daddystorm said:

I have reproduced a similar missing-transcoding-directory error on Emby Server 4.10.0.40, 4.10.1.0 and 4.11.0.6 beta. I cannot confirm that it has the same underlying cause as the original report, but this isolated reproduction may help.

Test setup

Official Docker images, without third-party plugins (bundled Emby plugins remain). A synthetic 40-minute H.264/AAC MKV, with no subtitles, is served over loopback HTTP with HEAD and byte-range support. The environment has no outbound network access. Copies of existing databases/settings were used; production was not modified.

HLS video transcoding is requested through PlaybackInfo using H.264/AAC and MPEG-TS, with a 7 Mbps client limit. The synthetic video is 320x180 at 24 fps and much lower bitrate; the limit is not its actual output bitrate. Video is transcoded; AAC can be stream-copied.

Reproduction

1. Fetch the HLS media playlist.
2. Begin requesting segment 753, corresponding to approximately 37:39.
3. Cancel that HTTP request while it is still pending.
4. Request segment 60, approximately 3:00, using the same PlaySessionId.

Expected: the new seek returns a playable segment.
Actual: the subsequent request returns HTTP 500. FFmpeg reports "Could not write header ... No such file or directory."

Observed directory lifecycle

Polling the output directory every 20 ms shows that it is removed after cancellation. The next FFmpeg process attempts to write to the same directory, without it being recreated beforehand.

One observed sequence on 4.10.0.40, in UTC:
- Directory 0B13B5 created: 20:46:50.495
- Directory removed: 20:46:53.598
- Subsequent FFmpeg write fails: 20:46:55.313

The exact internal Emby method responsible has not been identified.

Control tests

- Sequential, completed seeks work.
- The same synthetic file provided as a native local File source works, including cancellation while the request is pending (verified on 4.10.0.40).
- With the HTTP source, adding a fixed 0.8-second delay before GET responses reproduces the failure consistently when cancellation occurs after 0.05, 0.25 or 1.5 seconds.
- The HTTP-source failure was reproduced on all three Emby versions listed above.
- No third-party integration, subtitles or external streaming service is required. No Sessions/Playing reports are sent during these tests.

Unlike the original report, this reproduction establishes an HTTP 500 playback failure, not a complete server crash.

Attached is a sanitized ZIP containing the server logs, corresponding FFmpeg logs and test reports for all three versions, plus the local-file control report. The README explains the redactions and maps the directory-removal example to its FFmpeg log. Credentials and identifying information are removed; compressed ExtraData payloads are omitted. Timestamps, error traces, FFmpeg commands and transcoding-directory names are retained.

A reproduction script can also be prepared for sharing if useful.

emby-hls-cancellation-sanitized-logs.zip 134.4 kB · 1 download

@daddystormhow does 4.11.0.8 compare for you?