Repository navigation
fix: don't skip cross-monitor events in gapless playback when sorting by another field - #5312
Merged
connortechnology merged 1 commit intoOct 20, 2026
Conversation
…y another field getNearEvents() built the prev/next query from the full (sort value, Id) tuple, which already orders events strictly in the chosen sort, but then also added AND E.StartDateTime >= / <= the current event's time. That extra predicate is only consistent when the sort field is StartDateTime. When events are sorted by another field -- MonitorName to group cameras, or Id -- it dropped events that are correctly next in that order but started earlier or later than the current one: the next monitor's first event (which often started before the current monitor's last), or a concurrently recorded event with a higher Id. Gapless playback then skipped over the events of every monitor but the first. A fresh, single-timeline database rarely shows this because Id order tracks time order; a database with several monitors recording in parallel, or one migrated from another system, makes the two diverge and exposes it. Drop the StartDateTime constraint and let the tuple be the whole ordering. It cannot reintroduce the earlier playback loop because (sort value, Id) is a strict total order. refs ZoneMinder#4186 Co-Authored-By: Claude Opus 4.8 <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
1 participant
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.
Symptom
With Replay set to "Gapless events", playback skips over events recorded by monitors other than the first event's monitor. Reported on 1.38.7 against a database migrated from a multi-monitor production system; a fresh single-monitor test database did not show it.
Cause
getNearEvents()already selects the prev/next event with the full(sort value, Id)tuple, which orders events strictly in the chosen sort. It then also addedAND E.StartDateTime >= / <=the current event's time. That extra predicate is only consistent when the sort field isStartDateTime. When the list is sorted by another field —MonitorName(grouping cameras) orId— it drops events that are correctly next in that order but started earlier or later than the current one:StartDateTime >=excludes it — the whole next monitor is skipped.A fresh, single-timeline DB rarely exposes this because Id order tracks time order; a DB with several monitors recording in parallel (or one migrated from another system) makes the two diverge.
Fix
Drop the
StartDateTimeconstraint and let the(sort value, Id)tuple be the whole ordering. It can't reintroduce the earlier playback loop (#4186 follow-up) because(sort value, Id)is a strict total order.Verified
php -lclean. The near-event query path is shared by Prev/Next and gapless playback for both video.js and zms events.🤖 Generated with Claude Code