Misreporting "available disk space" during transcoding, triggering false "due to disk space" freezes

[tgemby 0]

(please forgive me using claude to help summarize/synthesize the problem I'm seeing and the troubleshooting efforts I've tried so far)

Emby Server (Synology DSM) repeatedly misreports "available disk space" during transcoding, triggering false "due to disk space" segment deletions and playback freezes

Environment

• Emby Server version: 4.9.5.0 (.NET 8.0.25), x64, installed via Synology Package Center
• Platform: Synology DSM, NAS model "DS923+," 4 CPU cores, x64
• Data volume: /volume1, btrfs on /dev/mapper/cryptvol_1 (encrypted), 32TB total, currently ~24TB used / ~8.0TB free
• Transcoding temp path (current): /volume1/[redacted]/transcoding-temp (a real directory on the data volume, owned emby:emby, 755), configured explicitly via Dashboard → Transcoding → Advanced → "Transcoding temporary path"
• Transcoding temp path (original default, before any changes): /var/packages/EmbyServer/var/transcoding-temp
   

  Note: the incidents below are only the handful of times I had logs open and actively dug into this. The actual freezing happens far more often — close to daily — and has been ongoing throughout this whole period. This is not a complete incident list, and the gaps between incidents below do NOT mean the problem went away in between — just that those were the times I captured and analyzed logs in detail.

  The problem

  During HLS transcoding, EncodingManager periodically logs:

   

  EncodingManager: Deleting segment ... due to disk space. Available space: 829423616

  and proactively deletes .ts segment files that are still being read by the client, freezing or stalling playback. The "Available space" figure has consistently been ~829–831 million bytes (~791–792MB), across a month of logs and two different real transcoding-temp paths, while the actual volume has had multiple terabytes free the entire time. It doesn't track real usage and doesn't change when the configured path is relocated.

  Troubleshooting so far

  Incident 1: Repeated "due to disk space" deletions on the default path, Available space ~791MB, while df -h on that same path showed 7.6TB free. Also saw a separate ffmpeg crash: Could not write header for output file #N ... No such file or directory → Conversion failed! (HTTP 500 to client) — possibly segments being deleted mid-write. Ruled out disk hibernation/ATA reset via /var/log/messages, dmesg, /proc/uptime. Fix tried: moved transcoding-temp to a new real directory on /volume1, set it explicitly in Transcoding settings, restarted Emby. This did not resolve the underlying problem — the freezing has continued at roughly the same frequency since, as shown below and in day-to-day use that wasn't separately logged.

  Incident 2: Different symptom — repeated stalls on one episode near the same timestamp, Apple TV client falling back from Direct Play to HLS. No "due to disk space" lines in this particular captured log. ffprobe showed no source file corruption. Possibly an Apple TV/network issue layered on top of the same underlying freezing problem, not necessarily unrelated.

  Incident 3: The Incident 1 ffmpeg ENOENT crash recurred (mostly on the subtitle-extraction output stream). Fix tried: disabled "Allow subtitle extraction on the fly," restarted Emby. A follow-up log captured a few hours later showed no recurrence of that specific crash, but 99 "due to disk space" deletions in that same window, Available space ~792.4MB, on the same relocated path from the Incident 1 fix, with sustained client disconnects throughout — i.e. the core disk-space problem was still there, just not producing that particular crash signature in this window.

  Root-cause investigation

  Three environmental explanations were tested directly and ruled out:

• Per-user DSM disk quota: the emby Linux account isn't a DSM-managed user — it doesn't appear in Control Panel → User & Group at all, so DSM's User Quota feature can't apply to it.
• Package sandboxing hiding the real volume: cat /proc/<EmbyServer PID>/mountinfo shows Emby's own process sees /volume1 mounted correctly as real btrfs on /dev/mapper/cryptvol_1, identical to the host's view.
• btrfs qgroup / shared folder quota: stat -f run directly on the real, live transcoding path returned Total ≈31.4TiB / Available ≈8.0TiB — matching df -h exactly, no quota ceiling at the filesystem level.

• A coincidence worth flagging: the ~791–792MB figure is close to the free space on DSM's own small system partition (/dev/md0, 2.3GB total). But Emby's process working directory and the live stat -f results above both check out correctly against /volume1, so this doesn't look like the literal mechanism — just a possibly-relevant coincidence for your engineers.

  Leading theory: since every OS/filesystem-level explanation is ruled out, the "Available space" figure is likely not being queried live against the configured path at log time — more likely a cached, stale, or internally-tracked value that doesn't reflect real-time disk state. The problem has been persistent and near-daily rather than intermittent, so whatever is producing this wrong value appears to be a standing condition rather than something tied to a specific restart.

  Known precedent

  Forum thread #116243 describes the same symptom on another Synology/Emby install — a small root volume triggering "due to disk space" deletions despite ample space on the real data volume. Their fix (properly setting the Transcoding temporary path) is the same one I tried, and also wasn't durable. No staff explanation of the mechanism was given there either.

  Questions

• Is "Available space" queried live via DriveInfo/statvfs() on the configured path each time, or cached/derived once?
• Any known issue with this check specific to Synology package installs?
• Any way to force a re-check without a full restart, to help isolate a startup-caching bug?
• Any way to disable or raise the threshold for this proactive deletion behavior — it currently causes far more disruption than running close to actually full would?

• Happy to provide full logs and the exact mountinfo/stat -f/df -h output on request.

Edited Friday at 04:53 PM by tgemby
edited for clarity!

[Luke 43374]

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[tgemby 0]

1 hour ago, Luke said:

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!
 

 

No problem! 

Between 08:14 and 09:04 today, the same single episode triggered at least seven separate ffmpeg transcode sessions, each lasting only a few minutes before ending and being replaced by a new one:

• 08:14:03 → 08:16:52 (EXIT)
• 08:17:59 → (restarted)
• 08:47:17 → 08:51:49 (EXIT)
• 08:52:44 → 08:57:24 (EXIT)
• 08:58:18 → 09:00:58 (EXIT)
• 09:01:50 → (restarted)
• 09:04:20 → (restarted)

This sits in the same window as the server log attached below (the one showing 99 "due to disk space" deletions, Available space ~792.4MB). None of these ffmpeg sessions show the ENOENT crash from my earlier incidents — they end cleanly or get superseded — but something is repeatedly forcing a brand-new transcode session for the same episode every few minutes, consistent with the client losing its segments to the false disk-space deletions and having to restart the stream from scratch each time.

Attaching all six full ffmpeg logs from this window, sanitized the same way as my original server log attachment.

Thanks!

embyserver_disk-space-incident_sanitized.txt ffmpeg-transcode_08-17-59_sanitized_1.txt ffmpeg-transcode_08-47-17_sanitized_1.txt ffmpeg-transcode_08-52-44_sanitized_1.txt ffmpeg-transcode_08-14-03_sanitized_1.txt ffmpeg-transcode_08-58-18_sanitized_1.txt ffmpeg-transcode_09-01-50_sanitized_1.txt

Edited Friday at 06:38 PM by tgemby
edited for clarity

[Luke 43374]

Quote

•  

• Is "Available space" queried live via DriveInfo/statvfs() on the configured path each time, or cached/derived once?

Hi, this is using the dotnet runtime DriveInfo api, I'm not sure what that is calling underneath the hood. But it is checking this constantly.

[tgemby 0]

On 10/16/2026 at 12:55 PM, Luke said:

Hi, this is using the dotnet runtime DriveInfo api, I'm not sure what that is calling underneath the hood. But it is checking this constantly.

Thanks, that's a useful data point, and it actually rules something out for me.

If it's checking via DriveInfo constantly (i.e. live, not cached), that means it isn't a stale-value problem — it's getting the wrong answer freshly on every single call for this path. That's worth pinning down, because I've already confirmed the OS itself reports the correct value for the exact same path: running stat -f directly against my configured transcoding directory returns Total ≈31.4TiB / Available ≈8.0TiB, matching df -h exactly. So the real filesystem is fine — whatever DriveInfo is doing underneath only goes wrong somewhere between the raw syscall and what Emby sees.

One concrete thing worth checking: my data volume is a Synology btrfs volume, and it doesn't mount like an ordinary filesystem. The relevant line from /proc/<EmbyServer PID>/mountinfo is:

 

41 17 0:32 /@syno /volume1 rw,nodev,relatime - btrfs /dev/mapper/cryptvol_1 rw,ssd,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50,block_group_cache_tree,syno_allocator,subvolid=256,subvol=/@syno

Note the two different path fields — /@syno (the subvolume's own internal root) vs /volume1 (the actual mount point). Most mount entries have those identical; this one doesn't, because it's a btrfs subvolume mount. If DriveInfo's Linux implementation resolves a path to a filesystem by walking/matching against the mount table (rather than just calling statvfs() directly on the given path and trusting the kernel to resolve it), a subvolume-style entry like this seems like a plausible place for that matching to go wrong — Synology volumes are commonly mounted this way, which might also explain why this isn't a totally obscure one-off (see the other forum thread I linked with the same symptom).

Happy to provide the full mountinfo output, or run any other test that would help narrow down where in the stack this breaks.