Why does the duplicate count look wrong?
Why duplicate counts differ between the timeline, Review tabs, overview stats, and the resolver.
Use this article when duplicate numbers in Clipido do not match what you expect, and you need to know which count means what.
Clipido shows several duplicate metrics in different places. Each counts something different: files in one upload, files across the workspace, duplicate sets, or upload batches. Comparing unlike numbers is the usual reason counts look wrong.
The duplicate metrics Clipido shows
The table below lists the main duplicate counts and what each one measures.
| Where you see it | What it counts |
|---|---|
| Upload timeline: "N duplicates detected" | Files "from this upload" that belong to an open duplicate set |
| "Review → Duplicates" tab badge | Upload "batches" that still have unresolved duplicates |
| Overview: "Total duplicates left" | Every file still in any open duplicate set across the workspace (including copies you will keep) |
| Overview: "Unique duplicates left" | Open duplicate "sets" across the workspace (one keeper each) |
| Upload row: "N groups" | Open duplicate sets linked to that upload |
| Upload row: "N files" | Files from that upload in open sets |
| Resolver: "File X of Y" | Your position among duplicate "sets" in this upload (the label says File but means set) |
| Resolver context line | Files from this upload in open sets, and how many sets they span |
Why the timeline count can differ from the resolver
The upload timeline counts duplicate files "from that upload only".
The resolver shows "every copy in the set", including identical files uploaded through other zones or earlier batches anywhere in your workspace.
Example: the timeline says "2 duplicates detected", but the resolver shows "4 copies". Two of those copies came from a different upload zone. They still belong to the same hash group, so the resolver includes them.
Why three identical copies are not "two duplicates"
Counts use "member files", not "extra copies beyond one."
Three byte-for-byte identical files in one set often appear as "3 duplicates detected" on the timeline, not 2. "Total duplicates left" on the overview uses the same file-based counting.
"Unique duplicates left" counts "sets" instead. One set of three identical files adds 1 to unique duplicates and 3 to total duplicates.
Why the tab badge is smaller than the file total
The badge on "Review → Duplicates" counts "upload batches" with open duplicates, not duplicate files.
If two uploads each have unresolved duplicates, the badge shows "2", even when hundreds of duplicate files remain across both batches.
Why "File 1 of 3" does not mean three files
In the duplicate resolver, "File X of Y" tracks duplicate "sets", not files in the current set.
An upload with three separate duplicate sets shows "File 1 of 3", "File 2 of 3", and "File 3 of 3" as you Click Continue, even when each set contains only two copies.
Read the context line above the pagination for the file count, for example "3 duplicate files in 1 set".
Why an upload can lose duplicates after a re-upload
Duplicate review is attributed to the upload that contains the "newest" copy in a set.
If someone uploads the same file again in a newer batch, the open set can move to that batch. An older upload's duplicate count may drop to zero even though the set still exists under the newer upload.
Why duplicates may not appear yet
Duplicate sets only include files in "submitted" uploads. Files still in draft are excluded until submission.
Duplicate detection also runs after processing finishes. Until then, the timeline may still show progress under "Duplicate detection".
When counts drop after you resolve a set
After you "Apply" a resolution, archived copies leave the active set. A set with fewer than two active members no longer appears in counts.
"Storage freed" and "Storage left to recover" on the overview update separately: freed reflects past resolutions, while left to recover estimates space from sets still open.