Repository navigation
Resolve the recording folder to an absolute user path (T2.8 / #469) - #496
Merged
Merged
Conversation
…2.8 / #469) The issue's premise is wrong, and the fix is not the one it asked for. The shell's DEFAULT has been an absolute Videos\CoreVideo Pro since 2026-07-21 (807975a). What actually bit is a PERSISTED RELATIVE preference: it bypasses that default entirely and is resolved by the CORE against its own working directory, which for an installed build is the install folder. Shows then sit where a version-isolated upgrade or an uninstall can strand or delete them, and the operator cannot find them. Verified live on the owner's machine 2026-09-12: the stored value is the literal "Recordings/CoreVideo Pro". RecordingFolderPolicy.Resolve is now the one rule, used by both the default and the prefs restore, so the migration is permanent on the next save. It migrates ACCIDENTS, never DECISIONS: - an absolute path is returned untouched, including a UNC share; - the one legacy value maps onto the user folder itself rather than nesting Videos\CoreVideo Pro\Recordings\CoreVideo Pro; - any other relative path keeps the shape the operator typed, under the user folder instead of under the install directory; - a drive-rooted path stays on its drive and is never reparented under Videos; - with no Videos folder at all the result is STILL absolute, because the old fallback there was the relative wire default — the value that caused this. The record flyout now shows the resolved absolute path: "operators can't find their files" is half the issue. 2218 MediaCore tests and 1446 WinUI tests pass. One test caught a real gap while being written: a drive-rooted path had no defined behaviour, and now has one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014yuH7EMvWCWdkhvevrtMyJ
iamfatness
added a commit
that referenced
this pull request
Sep 12, 2026
Nine items closed and two partial, all shipped in beta-2026-09-12-e1223d3 and none of them live-checked: T1.12 #475 join-time prompts answered #493 T1.13 #473 media decoder failures are loud #494 (observability ONLY) T2.6 #438 packaging spec reconciled #504 T2.7 #474 one shortcut, uninstall cleans up #497 T2.8 #469 recordings resolve absolute #496 T2.9 #466 recording lifecycle survives a stream #499 T2.10 #468 sender health stops lying #499 T3.2 #440 WebView2 message #504 T3.7 #470 ISOs armed with capture off warn #502 T3.8 #482 ISO frames conform to the writer #503 T2.1 #433 PARTIAL — WER dumps are HKLM-only T3.5 #476 PARTIAL — the rest is a product call Each row keeps the thing that is expensive to rediscover rather than just a tick: T2.8 records that the issue's premise was wrong (the default was already absolute; a persisted relative preference bypassed it), T3.8 records that its end-to-end test is a guard which passes either way, T2.6 records that dropping MSIX cost auto-update, and T2.1 records the measurement proving a per-user installer cannot enable crash dumps. Tier 1 now has ONE open item, and it is waiting on a decision rather than effort: T1.11 step 1 needs a change to the Take path itself, because a plain cut never captures the outgoing scene. That is written into the row so the next session does not rediscover it and ship it blind. Two entries came out of the work rather than the list: #505 (the per-layer border controls are vestigial — the core forces borderStyle="none" on every route layer, so they cannot do anything) and the T1.11 ruling. The honest header: the binding constraint is now T0.1 and a live check, not engineering capacity. Claude-Session: https://claude.ai/code/session_014yuH7EMvWCWdkhvevrtMyJ Co-authored-by: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #469.
docs/BACKLOG.mdT2.8.The issue's premise is wrong, and the fix changes accordingly
The shell's default has been an absolute
Videos\CoreVideo Prosince 2026-07-21 (807975a). So "the default is relative" is not what bit you on 2026-09-10.What actually bites is a persisted relative preference. It bypasses that default entirely and is resolved by the core against its own working directory — the install folder for an installed build. Shows then sit exactly where a version-isolated upgrade or an uninstall can strand or delete them, and you can't find them.
Verified on your machine 2026-09-12: the stored value is the literal
Recordings/CoreVideo Pro.So the fix is a migration, not a new default.
The rule
RecordingFolderPolicy.Resolveis the one rule, used by both the default and the prefs restore, so the migration is permanent on the next save. It migrates accidents, never decisions:D:\Shows,\nas\showsRecordings/CoreVideo Pro(legacy)Videos\CoreVideo Pro— not nested under itselfShows/SundayVideos\Shows\Sunday— keeps the shape typed\Shows\Sunday(drive-rooted)Videos\CoreVideo ProThat last row matters: the old fallback there was the relative wire default — the exact value that caused this.
The record flyout now shows the resolved absolute path, because "operators can't find their files" is half the issue.
Verification
2218 MediaCore tests and 1446 WinUI tests pass. (1446 rather than the 1451 I reported on #493 is exactly the five tests that live on that branch, not this one.)
One test earned its keep while being written: a drive-rooted path had no defined behaviour at all. It does now, and is pinned.
Note for T2.7
This is a prerequisite for the uninstall cleanup in #474 — until recordings are out of the install directory, an uninstaller that removes what first-run added is one mistake away from deleting a show.
🤖 Generated with Claude Code
https://claude.ai/code/session_014yuH7EMvWCWdkhvevrtMyJ