Duplicate camera events often occur when a tracker loses one identity and reacquires the same subject under a new track ID.
A person can trigger one driveway alert, disappear behind a parked vehicle, then generate another alert seconds later without ever leaving the property. Detection still sees one person, but the tracking layer may represent two trajectories. Whether the user receives one event or two depends on reacquisition confidence, the gap window, zone logic, and where the NVR performs deduplication.
Detection, Tracking, and Events Use Different Identities
A detector produces boxes and class scores for individual frames. A tracker associates those boxes over time and assigns a temporary identity. Event logic then decides whether a trajectory crossing a zone, dwelling, or matching a class should become a notification or saved event. These are related layers, not one object.
object tracking links detections across an image sequence using motion and appearance cues. When that association breaks, the detector can remain correct while the tracker creates a new identity for the same physical subject.
If the event engine keys alerts directly to track IDs, the new identity looks like a new visitor. If it keys them to a longer-lived incident window, zone occupancy, or appearance match, the second track may be merged. Duplicate events therefore reveal a boundary between temporary track identity and the user-facing meaning of one incident.
Occlusion and Coverage Gaps Create Reacquisition Pressure
During continuous visibility, the tracker predicts motion and matches each new detection to an existing trajectory. Occlusion, glare, low light, edge-of-frame exits, and skipped inference frames remove that evidence. The longer the gap, the larger the plausible location and appearance uncertainty becomes.
A technical briefing on camera handoffs identifies occlusion, coverage gaps, identity switches, and appearance ambiguity as major failure modes. Re-identification can bridge some gaps, but its confidence depends on lighting, angle, resolution, and how distinctive the subject remains.
The tracker must choose between two errors. Reusing an old ID too readily can merge different people; requiring stronger evidence can split one person into multiple tracks. Reacquisition thresholds shift that balance, so duplicate reduction cannot be separated from the risk of false identity continuity.
Event Windows Decide Whether a Split Track Becomes a Duplicate
Deduplication keeps short-lived state beyond the tracker itself. It may remember the last class, zone, direction, appearance embedding, and timestamp, then suppress or merge a new event that falls within a configured relationship window. This can convert two technical tracks into one user-facing incident.
temporal consistency matters because stable event output requires evidence across time, not only a confident frame. A cooldown suppresses repetition, while a continuity rule asks whether the later observation plausibly extends the earlier event.
A longer window catches more reacquisitions but can merge separate visitors who arrive close together. A shorter window preserves incident separation but exposes more duplicate alerts. Zone boundaries and direction can reduce ambiguity: two tracks connected by a plausible path are safer to merge than two detections that merely share a class and timestamp.
The Right Metric Separates Identity Errors From Alert Errors
Track quality and alert quality should be measured separately. Identity switches, fragments, and reacquisition delay describe the tracking layer. Duplicate notification rate, merged-distinct-incident rate, and time-to-first-alert describe the event layer. One can improve while the other worsens because deduplication may hide tracking defects.
Research reviews of multi-object tracking distinguish detection, association, trajectory fragmentation, and identity-switch problems. A useful home test labels physical incidents first, then compares technical tracks and final notifications against that ground truth.
The practical boundary is that no reacquisition threshold eliminates both splits and false merges. Tune the tracker for the scene, then tune event windows for the notification meaning users care about. Keep raw track evidence available so a low duplicate count does not conceal aggressive merging of unrelated events.
Tech & AI HUB
More to Read

Why Jellyfin Home-Server Architecture Changes as You Add Services
A Jellyfin box becomes a service stack as more apps are added, so CPU, storage, network, secrets, backups, and recovery boundaries need explicit ownership.

How to Measure Jellyfin Performance Without Mistaking Cache for Capacity
A reliable Jellyfin benchmark labels cold and warm state separately so cached metadata or filesystem pages are not mistaken for permanent hardware capacity.

How Much iGPU Headroom Does Multi-User Jellyfin Need?
Jellyfin iGPU headroom is workload-specific: reserve margin above the hardest repeatable concurrent transcode mix, not an arbitrary utilization percentage.

