Philip Guzman
38 lines
1.5 KiB
Markdown
38 lines
1.5 KiB
Markdown
# Batch duplicate review
|
|
|
|
## Problem
|
|
|
|
Opening a diagnostic, opening each group again, scrolling to a separate repair
|
|
form, and applying one change at a time creates unnecessary friction and many
|
|
small backups.
|
|
|
|
## Design
|
|
|
|
Duplicate and cloud-conflict diagnostics now open as a sequential review queue.
|
|
Each group presents its candidates together with audio preview and Finder
|
|
controls. Choosing a keeper records the decision and advances immediately.
|
|
Uncertain groups can be skipped without changing them.
|
|
|
|
All approved decisions are submitted as one dry-run plan. Apply creates one
|
|
backup containing every affected audio file plus the Serato metadata snapshot,
|
|
then installs all compatibility shortcuts as one rollback unit. Any validation
|
|
or filesystem failure prevents or rolls back the batch.
|
|
|
|
The dry-run opens in a closable modal that names every selected keeper and every
|
|
path that will become a compatibility shortcut. Closing the modal preserves the
|
|
queue position and all decisions so the DJ can continue reviewing before apply.
|
|
|
|
## Edge cases
|
|
|
|
- The same group cannot be submitted twice.
|
|
- A file cannot be both a keeper and a disposable file across choices.
|
|
- Every group is rescanned and revalidated before preview and apply.
|
|
- Skipped and unreviewed groups remain untouched.
|
|
- Revisiting a group preserves and visibly marks its selected keeper.
|
|
|
|
## Tests
|
|
|
|
- Two groups produce one backup and one restorable receipt.
|
|
- Batch preview reports combined changes without modifying files.
|
|
- Existing single-group repair remains a wrapper around the batch engine.
|