QA finding
A user starting an experiment recording currently sees only a modal message with the destination path. The application does not show free/usable space, recording size, growth rate, estimated remaining duration or a low-space warning. A disk-full error stops RecordingTap in the background and may only be visible in logs.
For experiments that write continuous multichannel float audio, storage capacity is part of experiment readiness and must be visible before and during recording.
Goal
Add storage preflight, continuous monitoring and a persistent recording-health display.
Storage model
Create an API-neutral RecordingStorageStatus or equivalent containing:
- destination path and backing store identity/type;
- writable/read-only state;
- usable, unallocated and total bytes when available;
- bytes already written;
- measured and expected bytes per second;
- estimated remaining safe recording duration;
- warning state and threshold;
- last successful capacity check and any capacity-query error.
Use Files.getFileStore(...) / FileStore.getUsableSpace() for the destination's existing parent or nearest existing ancestor. Treat the value as an advisory estimate, not a guarantee; continue to handle write failures.
Preflight
Before truncating or creating the target:
- verify that the destination parent exists or can be created;
- verify that the store is writable;
- calculate expected growth from sample rate, channels, sample representation and per-block overhead;
- show available space and estimated maximum duration;
- optionally accept an intended experiment duration and validate a safety margin;
- require explicit confirmation when the estimate falls below the configured margin.
Runtime behaviour
- Refresh capacity off the EDT at a bounded cadence.
- Warn by remaining duration as well as raw bytes.
- Use configurable warning and critical thresholds.
- At critical space, stop the recorder cleanly before the filesystem is exhausted, finalize the file as incomplete, and preserve capture/analysis where possible.
- Distinguish capacity-query failure from genuinely low space.
Required display
A persistent recording strip/status panel must show at least:
Do not use a modal dialog for continuously changing values.
Tests
- deterministic fake
FileStore for normal, warning, critical, read-only and query-failure states;
- preflight refuses an unwritable destination before truncation;
- warning thresholds are based on both bytes and estimated duration;
- critical state stops/finalizes recording exactly once;
- capacity polling does not run on the EDT;
- network/quota-like changes between checks are handled without assuming the previous value guarantees a write.
Acceptance criteria
- A user can see whether the selected disk can safely hold the planned experiment.
- Low-space conditions become visible before data loss or a generic I/O exception.
- The final recording summary includes size, duration, capacity warning history and completion state.
Depends on the status/lifecycle model introduced by #305.
QA finding
A user starting an experiment recording currently sees only a modal message with the destination path. The application does not show free/usable space, recording size, growth rate, estimated remaining duration or a low-space warning. A disk-full error stops
RecordingTapin the background and may only be visible in logs.For experiments that write continuous multichannel float audio, storage capacity is part of experiment readiness and must be visible before and during recording.
Goal
Add storage preflight, continuous monitoring and a persistent recording-health display.
Storage model
Create an API-neutral
RecordingStorageStatusor equivalent containing:Use
Files.getFileStore(...)/FileStore.getUsableSpace()for the destination's existing parent or nearest existing ancestor. Treat the value as an advisory estimate, not a guarantee; continue to handle write failures.Preflight
Before truncating or creating the target:
Runtime behaviour
Required display
A persistent recording strip/status panel must show at least:
Do not use a modal dialog for continuously changing values.
Tests
FileStorefor normal, warning, critical, read-only and query-failure states;Acceptance criteria
Depends on the status/lifecycle model introduced by #305.