DarkBreakpoint 1662e79ce3 feat(app): refuse to move the recording root out from under a library ...

Task 13, step 4. Playback resolves a recording's stored relative path
against whichever root is configured *now*. Changing
`video.recording.directory` while recordings exist therefore repointed
every one of them at a root their files are not in: the library kept
listing them and each one 404d. Nothing warned, and the existing hot
reload test asserted the swap worked.

`recording_root_change` decides it, and `save_config_main` calls it
before persisting, answering `409` with the number of recordings in the
way. Changing the root of an empty library is still allowed, as is any
other recording setting -- only the one field that invalidates stored
paths is gated, and only while something depends on it.

The count comes from the committed queue rather than from scanning the
filesystem: an entry exists exactly while a recording is expected to be
found, which is the condition that matters. Files with no entry are the
orphan case, and they are not what this protects.

Not done in Task 13, and not faked: steps 2 and 5 specify per-field hot
reload behaviour by reference to Design section 9.1, which is not in the
plan document and which I do not have. Steps 1 and 3 want the provider
adapter extracted to `recording_runtime.rs`; that is a refactor of the
app startup path rather than something this change approaches. Step 6's
guardrail already passes -- no `spawn_download_services`,
`resume_download_worker_if_needed`, `ensure_download_worker_running` or
`download_scheduler` remain anywhere.

2026-09-01 14:05:31 -05:00

..

src

feat(app): refuse to move the recording root out from under a library

2026-09-01 14:05:31 -05:00

Cargo.toml

Feature/multi crate (#837)

2026-08-27 15:36:23 +02:00