setRecordingDirectory replies "acknowledged" while silently disabling recording on a bad path

[mcfnord]

🤖 AI: jamulusserver/setRecordingDirectory always replies "acknowledged", but a bad path silently disables recording and discards the stored directory — with nothing to roll back to, and if a recording was already running, it ends the WAV mid-session while the jam continues, unannounced.

Root cause, confirmed on current main (4a43f6f6). SetRecordingDir tears down the existing recorder thread (EndRecorderThread() + wait()) before validating the new directory; on failure strRecordingDir is wiped to "". The RPC handler reports "acknowledged" regardless of which branch ran.

Measured on a headless build (wt-3861, 2026-08-12; the cited lines read identical on current main). A parent-is-a-file path and a path beyond PATH_MAX both flip enabled/initialised True → False and recordingDirectory → "", RPC still "acknowledged".

A recording already in flight stops at the instant the bad call returns. A growing WAV (950,272 → 975,916 bytes across a good call) sits flat at every checkpoint afterward, while getClients keeps reporting the same live connection throughout — the jam itself is untouched, so nobody in the room is told recording just ended.

The identical failure is loud in the GUI — GetRecorderErrMsg() drives a QMessageBox::warning — and silent over RPC, which discards the same string. getRecorderStatus's errorMessage does carry it, and the method's own doc comment says to re-check — a caller who does so can catch this — but nothing prompts the re-check, and "acknowledged" does not suggest a session recording just silently ended.

---

🤖 This message was written by AI and reviewed by @mcfnord.

[pljones]

The identical failure is loud in the GUI — GetRecorderErrMsg() drives a QMessageBox::warning — and silent over RPC, which discards the same string. getRecorderStatus's errorMessage does carry it, and the method's own doc comment says to re-check — a caller who does so can catch this — but nothing prompts the re-check, and "acknowledged" does not suggest a session recording just silently ended.

OK, so the JSON-RPC call needs to make the follow up call to ask if everything is okay, not just assume.

A recording already in flight stops at the instant the bad call returns. A growing WAV (950,272 → 975,916 bytes across a good call) sits flat at every checkpoint afterward, while getClients keeps reporting the same live connection throughout — the jam itself is untouched, so nobody in the room is told recording just ended.

Does the GUI failure flag recording ending? If not, that's a separate issue.