Explain metadata matching coverage without presenting it as archive health or predicted import success #6
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The analysis screen labels a filename-matching percentage as “Health Check” and shows a red “Orphans” count. This makes an intact export look damaged and does not explain the next step.
The current Bridge matcher has limited filename rules, rejects ambiguous metadata candidates and repeated media paths, and counts all JSON entries. Its results are not the importer’s matching results or a count of unique photos.
Acceptance criteria:
Starting #6 after reading #14, this issue, and the related importer diagnostics handoffs. I will separate ZIP integrity from preliminary filename-based metadata coverage, expose aggregate counts for no candidate / ambiguous candidates / repeated media paths, explain JSON entry counts and subset-only timeline/location summaries, and review recognized media formats against the pinned importer. All verified ZIPs will still go to Immich-Go for its own authoritative preview/matching. Existing analysis details stay owner-only and shareable support reports remain aggregate-only. Work will use an isolated branch and disposable validation; no active upload, task or pilot service will be restarted.
Implementation findings: the old matcher could reject ambiguous full-name candidates and then silently choose an extensionless fallback. New preliminary coverage conservatively counts all candidates from both rules, with repeated media entries classified separately and taking precedence. Counts reconcile to ZIP entries, not unique photos. Uppercase JSON suffix handling is fixed. Recognition now covers the pinned v0.32.0 image/video baseline (including WebP/TIFF/HEIF/RAW/WebM), and other file entries are counted explicitly.
Decision on matching authority: retain the inexpensive preliminary summary, label its limits, and treat Immich-Go preview results/private diagnostics as authoritative for importer outcomes. Every verified ZIP still reaches Immich-Go intact; no preliminary match filters its inputs. Older reports explicitly lack the new reason breakdown instead of fabricating it. Dates with no usable metadata no longer display year 1.
Backend tests/vet, UI lint/build, documentation contracts and owner/other-user/administrator analysis isolation have passed locally. Browser validation is finishing. The new report fits the established 390px page width; a separate existing application-header overflow of 3px at 320px was identified and is not being folded into this report change. No pilot service or active upload/task has been restarted.
Implemented, locally verified and pushed:
9980373bf6d7025f23560f47ede1c9ff74dce1e1oncodex/issue-6-metadata-coverage.PR #18 is ready for review: #18 . It is stacked on PR #15 (
codex/issues-10-11-diagnostics) to keep the diff specific to #6. Working tree is clean.Changes:
Checks actually passed on local AMD64 Docker Desktop:
Limitations/state: implemented, tested and published as a review branch/PR; not merged, release-image-published or deployed. Native ARM64/full release CI and a real-library pilot remain unverified. The extra 320px test found an existing application-header overflow of 3px; the analysis report fits at 320px and 390px, and the existing whole-page 390px check passes. No pilot service or active upload/task was interrupted.
Next handoff: review PR #18; merge/retarget the stacked branch after #15 is integrated, then use the repository release checks and coordinate an idle app/runner/processor update. Run a new owner analysis/preview to check the report against the pilot export. Keep this issue open through that verification; do not treat preliminary coverage as a reason to discard or re-export intact ZIPs.
Integration handoff: PR #18 is merged into main in
4de3f35. The final combined source passed local backend/vet/race, UI/browser, container/isolation/HTTPS, source/image policy and secret checks. Detailed merge/conflict evidence and limitations: #14 (comment). Native Forgejo AMD64/ARM64 release validation remains queued; no release images or deployment are claimed. This issue remains open for its pilot checkpoint. Run a new owner analysis/preview and verify the preliminary report against the pilot export. Integrity and importer outcomes remain separate. No active upload/task or pilot service was interrupted.Final development handoff: PR #18 is merged into main in
4de3f35, preserving feature commit(s)9980373.ZIP integrity is distinct from preliminary metadata coverage and actual importer matching. Reports explain absent/ambiguous candidates, repeated paths/entries, other entries, format recognition, legacy limitations and subset-only summaries. Immich-Go preview remains authoritative. Conflict resolution
3cc5c33preserves cancellation and the new entry counts.Validation: Cross-ZIP, ambiguity/fallback, repeated-path, format/other-entry and zero-coverage integrity fixtures passed, along with integrated report/browser/privacy checks. The combined application also passed backend/vet/race, UI lint/build, container/HTTPS, source/image policies and secret checks; integration evidence.
Documentation is updated on main through PR #21, merge
5ed7191: feature guide, merged scope/evidence, and remaining pilot checks. All nine documentation/policy tests and link/anchor/workflow checks passed.Closing at the owner's explicit request after merge, local validation and documentation review. This supersedes the earlier request to keep this development issue open through deployment. Native Forgejo AMD64/ARM64 release gates, coordinated idle installation and applicable real-provider/owner pilot checks remain in the release checklist and coordination issue #14. No deployment, native ARM64 pass, real-library capacity result or gate waiver is claimed. PR #19 and scanning remain on hold.