Conversions filling system disk: Any way to set a storage cap?

[me@jackbenda.com 8]

I've been experimenting with Emby's built-in conversion feature and ran into a problem I suspect others have hit too: conversions writing to the system disk until it's completely full.

The Conversions settings page only gives me two controls: A temporary file path and the full speed toggle. There's no native option to limit how much disk space conversions are allowed to use, or to cap the queue size.

My setup: Emby running natively on Ubuntu Server 24.04, 231GB NVMe system disk. When I kicked off a batch of conversions, Emby happily wrote to /var/lib/emby/sync/ until the drive was full. No warnings, no throttling, just a dead server.

A few questions for the community:

1. Is there a setting I've missed that limits conversion disk usage? I've only found the temporary file path and the speed toggle.
2. Is there a way to limit how many conversions run concurrently, to at least control the rate at which disk is consumed?
3. For those running conversions on a system disk — what's your approach? Redirect to a separate drive, or something else?

If this genuinely isn't possible natively, I'll put in a feature request: A maximum disk usage cap for conversions seems like a fairly essential guardrail. Keen to hear how others are handling this before I go the OS-level workaround route (create a dedicated directory on the NVMe for conversions, then enforce a hard size limit using a fixed-size loopback mount. Emby hits the ceiling and stops. system disk is safe. I'd point the "Temporary file path" at that mount. The cap is whatever I set, say 50GB, and nothing else on the disk is at risk. I'm just worried that that could freeze Emby up entirely though.)

[Q-Droid 1015]

Conversions should not fill up the space unless there's a problem with the job or a bug. Each file that's converted is copied back into the library based on the settings (replace or new version) and the temporary work file should be deleted. 

If there's a problem copying the file back then work files could be left behind. Usually because the library folder (directory) or the source media file itself have the wrong ownership and/or permissions that keep Emby from creating or overwriting. Other problems or failures during conversion could also leave files behind.

The activity should be logged along with possible errors. Enable debugging to get more detail in the logs.

 

[Luke 42320]

Quote

If there's a problem copying the file back then work files could be left behind. Usually because the library folder (directory) or the source media file itself have the wrong ownership and/or permissions that keep Emby from creating or overwriting.

Hi, yes this is the most common reason for conversions taking up a lot of disk space.

[me@jackbenda.com 8]

This is a really helpful pointer. This issue arose just before i went on holiday on the 1st of April, and I don't have those logs any more. I've just updated all the permissions and I'm running a few things as a trial run. Hopefully this will work!

Big thanks to both. 

[Luke 42320]

Was this what happened?

[me@jackbenda.com 8]

No I don't think so. I double checked and I did already have all the permissions set. I honestly don't know what happened last time, but it does seem to be working now and I've got a telegram bot to warn me if the directory starts ballooning again. 

[me@jackbenda.com 8]

OK so after enabling debug logging and running some test conversions, I can confirm the conversion feature itself works well. QuickSync hardware encoding, files writing correctly to the temp directory, replacements landing in the right place. No permissions issues (emby user is in the correct group with write access to the NAS shares).

The problem I hit was a resilience issue rather than a conversion bug. Here's what happened:

1. Emby was mid-conversion, writing finished files back to the NAS via the Transfer media task
2. My (slightly crap) NAS became temporarily unresponsive under load
3. The CIFS/SMB mount hung at the kernel level which i think is a known Linux behaviour where processes with open file handles on an SMB share block indefinitely waiting for the server to respond
4. Emby's Transfer media task stalled on "Stopping" and couldn't be cancelled from the UI
5. The only recovery was a full server reboot

This isn't really an Emby bug, it's a Linux kernel CIFS behaviour. But it does raise a question about whether Emby could handle NAS disconnects more gracefully during conversion transfer, perhaps with a configurable timeout or retry mechanism rather than hanging indefinitely.

On the Linux side, the fix is to add echo_interval and echo_retries options to the fstab CIFS mount, which reduces the time before the kernel declares the server dead from ~5 minutes to ~60 seconds. But even with that, processes in uninterruptible sleep will still hang temporarily.

Is there a cleaner way to handle this? Specifically, whether Emby has any internal timeout on file transfer operations that could be configured.

[Q-Droid 1015]

If you're running Linux to Linux then NFS might be more reliable.

 

[Luke 42320]

Quote

4. Emby's Transfer media task stalled on "Stopping" and couldn't be cancelled from the UI

When you stop any scheduled task, the stopping occurs at the next point when it is possible to stop. Since the raw file transfers can't be cancelled in-progress, the stop doesn't occur until the file transfer either succeeds or fails. Thus there is no stall, just a delay.

[me@jackbenda.com 8]

Ok that makes sense - it was a 4 hour delay though last time. I will embark on remounting to NFS at some point though. 

One other thing to ask quickly - one episode from a series failed (for some reason) and I can't seem to find a way to tell it to try again... Maybe I'm being dense but do I just have to cancel the whole job and then re-do?

[Luke 42320]

It will try again on the next run of the server scheduled task.

[me@jackbenda.com 8]

So I had a server reboot last night (docker had a meltdown and had to reboot) and so a bunch of my things failed (logs:)

Quote

2026-04-18 01:35:58.002 Info App: Disposing MediaEncoder

2026-04-18 01:35:58.002 Info App: Disposing SsdpDevicePublisher

2026-04-18 01:35:58.011 Info VideoEncoder: AppendExtraLogData - Read graph file: /var/lib/emby/logs/ffmpeg-transcode-e66f64af-e975-479d-a706-ba919e724395_1graph.txt

2026-04-18 01:35:58.012 Info VideoEncoder: AppendExtraLogData - Deserialized GraphData fileStream: 13,188.00 bytes Graph Count: 1

2026-04-18 01:35:58.012 Info VideoEncoder: AppendExtraLogData - File Deleted

2026-04-18 01:35:58.013 Info VideoEncoder: ProcessRun 'Encoding e66f64' Process exited with code 255 - Failed

I'm trying to run the scheduled task manually and they just won't start up again. Am I going to have to delete all my conversion tasks and start from scratch? This would be a bit of a pain because I dialled in about 50 conversion jobs to slightly different specs each time...

[Luke 42320]

What makes you think they won't start up again?

[me@jackbenda.com 8]

The scheduled task runs fine - it's not that it won't start. The issue is that the individual job items that were marked as failed during the reboot aren't being picked up and retried when the task runs again. They sit in a failed state permanently. The task completes but those specific items remain failed with no way to retry them short of deleting the jobs and re-queuing from scratch.

Is there a way to reset failed job items so they get picked up on the next run, without having to delete and re-create the entire conversion job?