mirror of
https://github.com/euzu/tuliprox.git
synced 2026-10-03 14:32:08 +02:00
DarkBreakpoint
1662e79ce3
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.