SD card recording silently fails with write_error at exactly 2GB (2^31-1 bytes) due to missing large-file support

[Nicola-polentini1972]

Summary

Recordings to SD card (.ts segments) via waybeam (star6e backend, SSC338Q) hard-fail with stop_reason: "write_error" at exactly 2147483647 bytes (2^31-1, i.e. INT32_MAX), regardless of the configured record.maxMB / record.maxSeconds rotation thresholds. This happens well before the configured segment-rotation size is reached (e.g. maxMB: 5000 never gets a chance to trigger), so a single continuous recording simply stops/fails instead of rotating into a new segment.

Repo affected: OpenIPC/waybeam_venc (filed here since Issues are disabled on that repo).

Environment

• SoC / backend: SigmaStar SSC338Q (star6e backend)
• OS: Buildroot 2024.02.10, kernel 4.9.84, armv7l (32-bit)
• Recording filesystem: exFAT (no inherent 4 GB/2 GB limit)
• waybeam binary build: Jun 13 2026; contract_version reported as 0.10.1
• record config in /etc/waybeam.json:

  "record": {
    "enabled": false,
    "dir": "/mnt/mmcblk0p1/ruby",
    "format": "ts",
    "mode": "dual",
    "maxSeconds": 1200,
    "maxMB": 5000,
    "bitrate": 40000,
    "fps": 0,
    "gopSize": 1.0
  }

Steps to reproduce

1. Set record.maxMB above ~2000 (e.g. 5000) and start onboard recording (dual-VENC mode) at a bitrate/fps high enough to reach 2 GB within the desired session length (e.g. 1080p60 @ 25-40 Mbps).
2. Let the recording run until the written file approaches ~2 GB.
3. Query GET /api/v1/record/status.

Expected behavior

Per documentation/SD_CARD_RECORDING.md, when a rotation threshold is reached the recorder should: wait for the next IDR boundary, close+fsync the current segment, and open a new .ts file with fresh PAT/PMT. Since maxMB (5000) is well above 2 GB, recording should continue uninterrupted as a single segment past 2 GB.

Actual behavior

The write fails outright:

{"ok":true,"data":{"active":false,"format":"ts","path":"","frames":0,"bytes":0,"segments":0,"stop_reason":"write_error"}}

The last segment file on disk is truncated at exactly 2147483647 bytes. This was reproduced twice independently (two separate recording sessions on the same device both produced files of exactly this byte count), so it is fully deterministic, not a transient I/O glitch.

Root cause (found in source)

In src/star6e_ts_recorder.c, open_new_segment():

state->fd = open(state->path, O_WRONLY | O_CREAT | O_TRUNC | O_CLOEXEC, 0644);

No O_LARGEFILE is passed, and neither this file nor its includes define _FILE_OFFSET_BITS 64 / _LARGEFILE64_SOURCE. On this 32-bit ARM target that leaves off_t as a 32-bit signed type, so the kernel returns EFBIG once the file offset would exceed 2^31-1 -- independent of the filesystem's real limits (exFAT has none here) and independent of the app-level rotation logic.

The rotation check itself (segment_bytes >= max_bytes in the same file, using correctly-sized uint64_t counters) is logically fine, but it only runs against the configured maxMB. When maxMB is set above ~2047 MB (a very reasonable value for a long recording), the OS-level write fails first, before the app's own rotation logic ever gets a chance to close the segment early.

Suggested fix

• Build with _FILE_OFFSET_BITS=64 (or _LARGEFILE64_SOURCE + open64()) so off_t is 64-bit, removing the artificial 2 GB ceiling entirely, or
• As a defensive belt-and-suspenders fix, clamp/warn when maxMB (or the default when maxMB: 0) would allow a segment to approach the 32-bit off_t limit on 32-bit targets, and force rotation before 2^31-1 bytes regardless of user config.

Workaround

Setting record.maxMB below ~2000 (e.g. 1900) causes the existing rotation logic to close the segment before hitting the real 2 GB ceiling, avoiding the write_error -- confirmed as a viable workaround on-device, but the underlying 32-bit off_t limitation should still be fixed at the source level since it silently truncates any config with maxMB (or 0 = unlimited) above ~2 GB.

[snokvist]

Your diagnosis was correct, including the mechanism and both suggested fixes.
#124 implements them. Thank you for the report — the 2147483647 exactly,
twice, is what made it cheap to confirm.

Reproduced byte for byte. Three arms of one harness driving the real
recorder core on Star6E (SSC338Q), same 58 GB FAT32 card, same input,
maxMB=2500 throughout — only the build differs:

	unpatched	patched, no flag	patched + flag
sizeof(off_t)	4	4	8
outcome	EFBIG	rotated below the ceiling	ran through
segments	1	2	1
largest file	2147483647	2147212672	2306867536

Both of your suggestions are in: -D_FILE_OFFSET_BITS=64 as the fix, and the
defensive clamp as a backstop that rotates below the ceiling if that flag is
ever lost.

One thing your report understated. The ceiling also hit stat()/fstat()
— src/venc_recordings.c and src/venc_httpd.c — which return EOVERFLOW
for a file over 2 GB. Verified against a sparse 3 GB file: a recording larger
than 2 GB would have been invisible to /api/v1/recordings and
undownloadable, even once the write succeeded. So O_LARGEFILE alone would
not have been enough; the build flag was the right call.

Two corrections to the workaround, both worth knowing before you rely on
it:

1. maxMB: 0 is not unlimited. The runtime overrides its compiled-in
   threshold only when the value is > 0, so 0 means 500 MB, not
   unbounded. The docs said otherwise; corrected in Recording stops at 2 GB because the binary, not the card, says so #124. Your config was
   never in the dangerous case for that reason — only an explicit
   maxMB > ~2047 was.
2. The workaround only exists on format: "ts". format: "hevc" ignores
   maxSeconds and maxMB entirely — the raw recorder has no rotation code
   at all — so there the 2 GB ceiling had no config escape. Tracked
   separately as record.format="hevc" silently ignores maxSeconds and maxMB — the raw recorder has no rotation at all #123.

Also, a stop at a size ceiling no longer reports write_error. It gets its
own stop_reason: "size_limit", and the status keeps the path and byte count
of the recording that ended instead of zeroing them — so the next occurrence
of anything like this says which file was cut short and how far it got, rather
than pointing at the card.

Please try #124 if you can. Your config is the interesting case: 1080p60
at 25–40 Mbps with maxMB: 5000, on exFAT rather than the FAT32 I tested. A
single segment past 2 GB on exFAT is the one arm I could not run here.

CV610 and Maruko were checked and are unaffected — musl is 64-bit off_t and
sets O_LARGEFILE regardless — so this is a Star6E-class fix only.

[snokvist]

Fixed and merged — #124 (588cdfb), with the follow-up in #125 (0c880d8).

Your diagnosis was right down to the mechanism, and both of your suggested
fixes are in: -D_FILE_OFFSET_BITS=64 as the real fix, and the defensive clamp
as a backstop that rotates below the ceiling if that flag is ever lost.

Reproduced byte for byte before fixing — an unpatched build died at exactly
2147483647; patched, a single segment reached 2306867536 on the same card.

Three things worth knowing beyond the original report:

1. The ceiling also hit stat()/fstat(). A recording over 2 GB would
   have been invisible to /api/v1/recordings and undownloadable even once the
   write succeeded, so O_LARGEFILE alone would not have been enough.
2. maxMB: 0 is not unlimited — it means the compiled-in 500 MB. The docs
   said otherwise and are corrected. Your config was never in the dangerous
   case for that reason; only an explicit maxMB > ~2047 was.
3. format: "hevc" ignored maxSeconds/maxMB entirely — that path had no
   rotation code at all, which is why the "lower maxMB" workaround did not
   generalise. Tracked as record.format="hevc" silently ignores maxSeconds and maxMB — the raw recorder has no rotation at all #123 and fixed in Rotate hevc recordings, and stop forcing a keyframe to do it #125, which also stopped rotation
   requesting a keyframe from the encoder at all: on an intra-refresh craft
   that was raising the bitrate the link had to carry, purely for the benefit
   of a file.

A size-ceiling stop also no longer reports write_error. It gets its own
stop_reason: "size_limit", and the status now keeps the path and byte count
of the recording that ended instead of zeroing them — so the next occurrence of
anything like this says which file was cut short and how far it got, rather
than pointing at the card.

Thank you for the report. The exact byte count, twice, is what made it cheap to
confirm.