False “write failed -- no space left on device” error

Frances Cook

I am using Tvheadend 4.3-2604_g9968e6f30 on an amd64 PC with Ubuntu 25.10.

When recording multiple files, some recording entries just randomly stopped writing in files but the task is still shown as ongoing in the DVR and subscriptions tabs.

The log showed an error message about that stopped task

[ ERROR]:pass: /mnt/sda/Records/2026-02-17_02-00-00_TESTING_TESTING.TS: Write failed -- No space left on device

But in the meantime other recording tasks can still write files as normal. If there is really no space left on my device I think all recording tasks should stop at the same time.

DaveH

Well it all depends on what 'device' you are talking about. What device does the error message refer to and what device are the other recording tasks using? Do you have some cotemporaneous record of the space available on those devices?

Frances Cook

DaveH Yes those recording tasks are using the same storage path. I still have more than 200GB of free space available on my hard disk. I was running seven recording tasks and two of them just stopped writing files, but they were still listed as recording in the “Upcoming / Current Recording” page.

If there isn’t enough space those tasks will be shown in “failed recordings”, but they didn’t turn “failed”, just no longer writing the recording files.

DeltaMikeCharlie

I'd double check your space using df -h. If you have multiple DVR profiles, I'd also check how many of them point to the same or different location.

I did an internet search for erroneous "ENOSPC" and I found that if your OS has insufficient free 'file watchers' that an ENOSPC error can occur even if you have sufficient free disc space.

Another thing to check is the file system type. Not all file systems, for example FAT, handle really big files used in recording TV. FAT32, for example, supports a maximum file size of 2GB or 4GB depending on configured options. You can use the df -T command to check your file system type.

ulimit -f can also be used to see if a file size limit has been configured.

Frances Cook

DeltaMikeCharlie Double checked both - I still have enough space and I only have one default DVR profile.

I can still record a 50GB file but another recording task just randomly stopped writing after 2GB. But that task was still in Status > Subscriptions with normal input and output bitrate.

I don’t know how to replicate it because it just occurred randomly. What can I do to trace it further? I now put pass and dvd in Configuration > Debugging.

DeltaMikeCharlie

Frances Cook What can I do to trace it further?

https://docs.tvheadend.org/documentation/appendices/debugging#trace-options-1

You could try adding pass and muxer to --trace and --debug either from the command line or via the WebUI, but yesterday I was looking in the code where your error arises and I did not see any logging capability in that area except for the error that you already see. I did not look super closely, so I may have missed something.

I'd also dig deeper into your OS configuration and your environment in general. Are you running in a container? Are you running in a VM? Are you running on an OS with constrained resources?, etc. I have no further suggestions.

Frances Cook

DeltaMikeCharlie Not a container or a VM, just the normal Ubuntu 25.10.

DeltaMikeCharlie

I have some random ideas:

Does the error occur with any other muxer settings like MKV?
Does the error always occur on the same channel?
Does the error always occur on channels from the same mux?
Does the error always occur on the same hardware tuner?
What is your programme source? (DVB-T, DVB-S, IP TV, etc.)
If you have multiple sources, is the error restricted to one of those sources?
If you play the failed recording, does it play cleanly until the end or are there audio/video errors?

I have an idea, but it's a bit crazy.

In C, the function that writes data to a file needs to know how much data is being written. Perhaps if TVH is telling the OS that it needs to write several TB instead of several MB (for example), then this error occurs.

Do you have the skills to compile your own TVH?

If so, then perhaps the error logging can be enhanced to add the number of bytes intended to be written to the log message.

If you have a hardware error or similar, then perhaps TVH is getting the wrong data length from the tuner and trying to save that invalid length worth of data to disk.

I searched the forum, and this does not seem to be a common error.

Frances Cook

DeltaMikeCharlie Haven’t tested other mixers yet. But it occurs on different channels and mixes. My programme sources are all LAN IPTV addresses from another device at my home. Those failed recording can played cleanly till the end. The last time I compiled my TVH was years ago so I think I forgot how to do it…

DeltaMikeCharlie

Frances Cook My programme sources are all LAN IPTV addresses from another device at my home.

This could be useful information. Maybe there is some exotic bug with IPTV sources?

Frances Cook The last time I compiled my TVH was years ago so I think I forgot how to do it…

See if this link jogs your memory. If it does, we should be able to give you some assistance in updating some source files to augment your logging and maybe help narrow down the error.

Frances Cook

DeltaMikeCharlie This could be useful information. Maybe there is some exotic bug with IPTV sources?

Not sure because it’s fine with the older 4.2 Tvheadend on my old amd64 PC with Ubuntu LTS 22.04. So I don’t know if it’s a bug with the sources or the OS or TVH.

DeltaMikeCharlie See if this link jogs your memory. If it does, we should be able to give you some assistance in updating some source files to augment your logging and maybe help narrow down the error.

Yes and I remember I installed lots of dependencies when building it.

DeltaMikeCharlie

Frances Cook Yes and I remember I installed lots of dependencies when building it.

Would you like to try compiling with some additional logging?

Frances Cook

DeltaMikeCharlie Sure!

DeltaMikeCharlie

Here is a diff that you can apply to /YOUR/PATH/HERE/src/muxer/muxer_pass.c.

diff --git a/src/muxer/muxer_pass.c b/src/muxer/muxer_pass.c
index 95ba86e52..9930d107d 100644
--- a/src/muxer/muxer_pass.c
+++ b/src/muxer/muxer_pass.c
@@ -599,8 +599,8 @@ pass_muxer_write(muxer_t *m, const void *data, size_t size)
   if(ret) {
     pm->pm_error = errno;
     if (!MC_IS_EOS_ERROR(errno))
-      tvherror(LS_PASS, "%s: Write failed -- %s", pm->pm_filename,
-              strerror(errno));
+      tvherror(LS_PASS, "%s: Write failed (size: %zu) -- %s", pm->pm_filename,
+              size, strerror(errno));
     else
       /* this is an end-of-streaming notification */
       m->m_eos = 1;

You can also just manually update the 2 lines involved.

This will not fix anything, however, it should be able to tell us if TVH is trying to write an insane amount of data to the disk.

I looked further into the code and it seems that some functions call pass_muxer_write with an int (signed) instead of a size_t (unsigned) size variable. If there is a bug in one of these calling functions that makes this int negative, then maybe this could be causing the error that you see.

At the very least, this extra logging should indicate if TVH is malfunctioning or if you have some other, potentially OS configuration, problem.

Frances Cook

DeltaMikeCharlie I tested for several hours and nothing happened but it occurred again when my disk is almost, but not exactly, running out of space.

Two DVR tasks ended writing in advance but the tasks themselves didn’t end until 13 minutes later when it truly ran out of space.

Another two tasks continued recording 5.2GB till they were aborted.

2026-02-26 06:52:16.045 [  ERROR]:pass: /mnt/sda/Records/2026-02-26_02-14-00_TEST1_TEST1.ts: Write failed (size: 18988) -- No space left on device
2026-02-26 06:52:16.049 [  ERROR]:pass: /mnt/sda/Records/2026-02-26_01-00-00_TEST2_TEST2.ts: Write failed (size: 39668) -- No space left on device
2026-02-26 07:05:05.000 [   INFO]:subscription: 0025: "DVR: TEST2" unsubscribing from "TEST2", username="admin"
2026-02-26 07:05:05.009 [  DEBUG]:dvr: adding inotify watch to /mnt/sda/Records (fd=1)
2026-02-26 07:05:05.009 [   INFO]:dvr: "TEST2" on "TEST2": End of program: Completed OK
2026-02-26 07:08:33.962 [WARNING]:dvr: running out of free disk space for dvr config "Default profile", required free space "800 MiB", current free space "727 MiB"
2026-02-26 07:08:33.962 [WARNING]:dvr: No "until space needed" recordings found for config "Default profile", aborting active recordings now!
2026-02-26 07:08:33.962 [   INFO]:subscription: 0043: "DVR: " unsubscribing from "TEST4", username="admin"
2026-02-26 07:08:33.962 [  DEBUG]:dvr: adding inotify watch to /mnt/sda/Records (fd=1)
2026-02-26 07:08:33.962 [   INFO]:dvr: "" on "TEST4": End of program: Not enough disk space
2026-02-26 07:08:33.963 [   INFO]:subscription: 002D: "DVR: TEST1" unsubscribing from "TEST1", username="admin"
2026-02-26 07:08:33.963 [  DEBUG]:dvr: adding inotify watch to /mnt/sda/Records (fd=1)
2026-02-26 07:08:33.963 [   INFO]:dvr: "TEST1" on "TEST1": End of program: Not enough disk space
2026-02-26 07:08:33.963 [   INFO]:subscription: 001C: "DVR: " unsubscribing from "TEST3", username="admin"
2026-02-26 07:08:33.963 [  DEBUG]:dvr: adding inotify watch to /mnt/sda/Records (fd=1)
2026-02-26 07:08:33.963 [   INFO]:dvr: "" on "TEST3": End of program: Not enough disk space

DeltaMikeCharlie

Frances Cook it occurred again when my disk is almost, but not exactly, running out of space.

From the revised logging, it does not appear that TVH is trying to write an insane amount (GB or TB) of data to disk when the error occurs.

It is interesting to note that TVH does monitor disk usage and provides running out of free disk space messages when appropriate.

Because your disk was nearing capacity during your test, perhaps you could try to clear some space and redo the test with plenty of space, just to be sure.

Based on your current test result, this is looking more like you may have an OS or file system issue. Use your favourite Internet search engine to identify potential causes of false No space left on device error messages and investigate those.

You could even try testing without TVH. You could write a simple looping shell script that writes a few MB to a file and then sleeps for 1 second to see if the error still occurs. There are several methods for achieving this just an Internet search away.

Frances Cook

DeltaMikeCharlie Did some tests simulating recording 8 HD and 2 UHD channels at the same time with a shell script and it worked as intended.

What also confused me is only some of the recording tasks were randomly affected. Eg when there was four tasks yesterday, only two stopped writing but the other two tasks still wrote files as normal.

DeltaMikeCharlie

@Frances Cook - You could try testing TVH once more, but with ample free spaces too see if the updated logging shows and abnormal 'size' values.

Have you looked into potential erroneous sources of this message and check these against your system?

If you truly believe that TVH is at fault, the next thing to consider would running TVH within the debugger and putting a break point just before the file is closed. You could check on your system for any of the factors potentially leading to the erroneous error message. Unfortunately, you'd be on your own with the debugger, I'm not overly familiar with it.

Frances Cook

DeltaMikeCharlie I believe it’s not a TVH issue - if it is all tasks using the pass profile will be affected at the same time. Pardon my poor Linux knowledge, I guess it’s because my file system reported that error to only some tasks?

And unfortunately I am currently using NTFS3 so it’s even more difficult now.

Flole

Maybe the reserved space is all that was left. If you really want to use 100% of the disk space then you can disable reserved space, but that may have unintended side effects.