C
Cyrano Security
10 min read
Reviewing footage, the three-jobs reframe

Reviewing security camera footage is three different jobs. Your DVR only ships the one you rarely need.

Every top result for this keyword teaches the same motion: pick a camera, pick a date window, scrub at 4x. That is forensic lookup, the job you do when a lawyer asks for a specific clip. The other two review jobs, live triage and shift triage, are what property managers and Redditors say feels impossible, and consumer DVRs do not ship an interface for either one. This page separates the three jobs, shows the math on the one that actually eats your day, and names the five event classes that fit in a morning glance.

See a morning review queue in 15 minutes
4.9from 50+ properties
Three review jobs: live triage, shift triage, forensic lookup
Five event classes in the shift-triage queue, nothing else
Median 7 to 8 second capture-to-reviewable latency
Tile.label OCR'd off the DVR's multiview strip, stable across channel swaps

The reason every SERP walkthrough says the same thing

Read the current top results and the shape is identical. Open the DVR app. Click Playback. Pick a channel, pick a date, drag the scrub bar. Set playback to 4x or 8x. If the recorder has a smart search button, click it and wait. That is the entire instructable. A handful of articles append "take notes" or "use bookmarks if your model supports them." The tone is always the same: this is the standard workflow, here is how to execute it.

The instruction is not wrong on its face. It is just describing one of the three jobs a reviewer actually does, and quietly pretending the other two do not exist. When a Redditor says reviewing footage is impossible, they are almost never doing the job this instruction is for. They are trying to triage an overnight shift, or watch a live event unfold, and those jobs have nothing in common with scrubbing a known time window.

The fix is not a faster scrub. The fix is naming the job first.

The three review jobs, separated

Each one has a different trigger, a different attention budget, and a different success shape. They do not share an interface. Any tool that tries to do all three from the same screen ends up doing none of them well, which is exactly what the DVR Playback screen does.

Live triage

Trigger: notification or alert in the last 60 seconds. Question: is this happening right now and do I need to send someone. Attention budget: 5 to 30 seconds. Success shape: decide respond or dismiss. Interface: a scrolling notification stream, not a multiview. Volume on a quiet 25-tile property: under 1 per hour.

Shift triage

Trigger: shift change, morning start, weekly review. Question: since I last looked, did anything cross a threshold that I need to act on. Attention budget: 2 to 20 minutes. Success shape: empty the queue by flagging or dismissing each row. Interface: reverse-chronological event list with thumbnails. Volume on 25 tiles overnight: 8 to 15 rows.

Forensic lookup

Trigger: a lawyer, cop, HOA, or insurance adjuster asks for a specific clip. Question: what exactly happened at t=X on camera Y. Attention budget: unlimited, bounded by the deadline. Success shape: exported clip with a timestamp and a camera label. Interface: filter by tile.label plus time window, click one thumbnail, export.

Why your DVR only does the third one

The DVR stores H.264 blobs addressable by (channel, timestamp). That data model only answers the forensic-lookup question. Live triage needs a notification stream on classified events. Shift triage needs an event index. Neither exists on the recorder because the recorder does not run classifiers at all.

Where each review job is actually served

Live event (past 60s)
Overnight queue
Specific t=X on cam Y
Cyrano event index
Notification stream
Reverse-chron thumbnail list
Thumbnail → DVR clip export

The shift-triage math that ends the 4x-scrub debate

Shift triage is the job most Reddit threads are really asking about. Someone had a bad overnight, or wants to do a weekly sweep, and opens the DVR hoping for a summary view. There is no summary view. Here is why the numbers force the reframe.

0tiles on a typical multiview
0hhours in an overnight window
0camera-hours of footage in that window
0thumbnails in the review queue (quiet night)

Scrubbing 200 camera-hours at 4x is 50 viewing hours. Scrubbing at 16x, which most humans cannot actually watch accurately, is still 12.5 viewing hours. The Cyrano event queue on the same footage is a median of roughly 0 thumbnails across 0 event classes, readable in under 2 minutes.

The five event classes that fill the shift-triage queue

Nothing else writes rows into the morning queue. The set is intentionally small so the reviewer never has to guess what a row means, and the filter chips on the dashboard are these five literal names. Everything not in this set stays in the DVR's own continuous recording, available by hand for the rare cases the queue does not cover.

classes in the Cyrano event record:

  • person_in_zone — an actor crossed a configured polygon
  • loiter — an actor's bounding box persisted past a dwell threshold
  • vehicle_dwell — a vehicle remained stationary past a threshold
  • tamper — a tile's HDMI frame lost structure (blocked, rotated, unplugged)
  • package_tamper — a package-sized object disappeared from a zone

One row from the shift-triage queue

This is the shape of one event the reviewer sees in the morning. The tile.label is the human-readable name the DVR paints on the multiview, OCR'd at install time. latency_ms is the time from the classifier trigger to the row being live in the dashboard, which in practice sits between 5 and 15 seconds. The open_clip_url is the forensic-lookup shortcut: click and the full clip opens, already seeked to the right place.

event.json (one shift-triage row)

The morning-review filter, as a URL

This is what the morning reviewer actually opens. A property filter, a time window, a comma-separated list of event classes, a tile wildcard, and a sort order. No scrubbing. No channel math. Readable by hand, scriptable against the event table.

the morning review filter

What the install and first queue look like on the wire

Below is a slice from a production 25-camera property at 6:02 a.m., the moment the morning manager opens the dashboard. Every row in the queue at that moment came in during the prior 8-hour overnight window, with the latency column visible for each.

shift-triage queue, 25-tile property, overnight window
5m51s

Five minutes and 51 seconds of attention on the same 200 camera-hours of overnight footage that a 4x DVR scrub would ask for 50 hours of viewing time. The reviewer dismissed 9 rows, flagged 2, and closed the session before the coffee was cold.

Cyrano field notes, 25-tile Class B multifamily, overnight 22:00 to 06:00

How each job should feel at the desk or on the phone

the three review jobs, each with its own interface

1

Live triage (attention: 5 to 30 seconds)

A notification lands. It carries a tile.label, an event_class, and a thumbnail. Tap to open the last 60 seconds on that tile. Decide respond or dismiss. The interface is a notification stream, not a camera wall. The multiview on the DVR is the wrong surface for this job; humans cannot usefully attend to 16 scenes in parallel.

2

Shift triage (attention: 2 to 20 minutes)

Reviewer opens the dashboard at the start of shift. Event list is already populated by a background pipeline that runs at 7 to 8 second median latency. Filter to the shift window. Scan the thumbnail strip top-down. Dismiss the obvious non-events. Click into the 1 or 2 that matter. Queue is empty in 10 minutes on a quiet night.

3

Forensic lookup (attention: bounded by the deadline)

A specific incident has been reported, often days or weeks ago. Filter by tile.label (the painted camera name the reviewer already knows). Tighten the time window. Pin the event_class if you have one. Click the thumbnail. The DVR clip opens, already seeked to iso8601_ts minus a 5 to 10 second pre-roll so the approach is visible. Export as MP4. Done.

4

Not a job: 4x-scrub archaeology

Opening the DVR Playback screen and scrubbing through yesterday at 4x or 8x hoping something catches your eye is not one of the three jobs. It is the workflow every SERP article describes, and it is the workflow every reviewer gives up on by day three. If you find yourself doing it, you have not named which of the three jobs you are trying to do, and the tool has not given you a way to do any of them.

DVR Playback framing vs. three-jobs framing

The table below is the distinction a reviewer should hold in their head before they open any tool. The left column is the workflow every DVR pushes you into. The right column is what each of the three jobs actually needs.

FeatureDVR Playback framingThree-jobs review model
Primary interfaceA scrub bar over one channel at a timeThree surfaces: notifications, event list, filter + export
Attention unitSeconds of playback at some multiplierThumbnails, each one a classified row
Handles live triageNo; multiview is not a triage surfaceYes; notification stream filtered to last 60s
Handles shift triageNo; no concept of a shift queue existsYes; reverse-chronological event list across all tiles
Handles forensic lookupYes, if you know the channel and timeYes; filter by tile.label + event_class + window, click, export
Stable key when channels get renumberedNo; saved searches break on re-cableYes; tile.label is OCR'd off the painted camera name
Cross-recorder reviewNo; each DVR brand has its own Playback appYes; event table is one store across the portfolio

The thing that is uncopyable

Name the job before you open the tool.

Live triage wants a notification stream. Shift triage wants a reverse-chronological event list across every tile. Forensic lookup wants a filter plus a thumbnail plus an export. These are three different jobs, each with its own attention budget and its own success shape. The DVR Playback screen is built for the third one and pretends the first two do not exist. The Cyrano event index is the same table for all three, surfaced differently per job. 7 to 8 second median latency, five event classes, one tile.label OCR'd off the DVR's own painted camera name. That is the whole review protocol.

The questions Redditors actually bring to review

I have 12 hours of overnight to check by 9am
Package was stolen, no idea what time
Cop asking for a clip from last Thursday
Guard quit, no one watching the wall
Tenant says there was a car in the lot at 3am
HOA wants weekly review notes, 25 cameras
Lobby camera is blocked, found out today
Same loiter guy keeps showing up
Insurance wants footage from 2 weeks ago
Two properties, two DVR brands, no time

Each of these is one of the three jobs. Name which one before opening the tool. The first two and "same loiter guy" are shift triage. "Guard quit" and "camera blocked" are live triage. The cop, the lawyer, and the insurance adjuster are forensic lookup. Four filter chips answer each of them.

Where the 4x-scrub advice is fine, and where it is not

Worth being direct. If you already know the camera and the approximate time, and the incident is old enough to be fully on disk, the DVR Playback screen with a fast-forward slider is acceptable. That is forensic lookup on a known target. It is a fine tool for that specific job.

For everything else, it is wrong. Shift triage at 4x on a 25-tile property is a full workday of viewing. Live triage is not a thing you can do by scrubbing at all. The rewrite is not a faster scrub; it is a layer that produces a small, classified event list across every tile, so the reviewer can name the job first and then act on it in the right interface. That is what Cyrano puts on top of the recorder you already have, off one HDMI cable, in under two minutes of physical install.

Watch a real shift-triage queue load on a 25-camera property

A 15-minute call. We open the overnight queue on a production property, walk the five event classes, and show the 7 to 8 second capture-to-reviewable latency on a live tile.

Book a call

Reviewing security camera footage: frequently asked questions

Why does every 'how to review security camera footage' article tell me the same thing?

Because the DVR interface leaves them no alternative to describe. The consumer DVR has a Playback screen with a date picker, a channel dropdown, and a scrub bar. That is the full expressive surface. Every walkthrough therefore becomes: pick the channel, pick the date window, scrub. Some add 'set the playback speed to 4x or 8x.' Some add 'enable motion-based skip if your DVR supports it.' None of them say the true thing, which is that this workflow only serves forensic lookup (you already know exactly what you are looking for) and is actively wrong for the other two review jobs (did anything just happen, and did anything happen overnight).

What are the three jobs of reviewing footage, and which does my DVR actually handle?

Live triage is 'is something happening right now that I should respond to.' Shift triage is 'since I last looked, did anything cross a threshold that needs action.' Forensic lookup is 'a specific incident at a specific time is being investigated, find and export the clip.' Consumer DVRs are built for forensic lookup. The live view is there, but it is a 16-tile wall of noise with no attention hooks. There is no shift-triage screen at all; the feature does not exist on the recorder. So two out of three jobs have no interface on the box, and review becomes impossible for anything except 'I already know when this happened, show me the tape.'

What does shift triage actually look like when it is built correctly?

It is a reverse-chronological list of classified events across every tile on the multiview, loaded in the morning and read top-down. On a 25-tile multiview across an 8-hour overnight window, a quiet property produces 8 to 15 thumbnails. Each row is a timestamp, a tile.label (the camera name the DVR stamps on the multiview strip), an event_class (person_in_zone, loiter, vehicle_dwell, tamper, or package_tamper), and a thumbnail. Scan the strip, flag what looks interesting, click to open the full clip. Typical attention cost on a quiet night is under 2 minutes. On a busy property it is maybe 15 minutes. Compare that to 4x scrubbing 25 channels across 8 hours, which is 50 real-time viewing hours even at the elevated speed.

What are the five event classes Cyrano writes into the review queue?

person_in_zone (an actor crossed a configured detection polygon), loiter (an actor's bounding box persisted inside a zone past a dwell threshold), vehicle_dwell (a vehicle remained stationary inside a zone past a threshold), tamper (the HDMI frame from a tile suddenly lost structure, usually because the camera was blocked, rotated, or unplugged), and package_tamper (a package-sized object disappeared from a zone that previously contained it). Those five labels are the full filter surface of the shift-triage dashboard. Nothing else writes rows. If a class is not on that list, the full DVR recording is still there to review by hand for the rare case it matters.

Why is capture-to-reviewable latency the number that matters for shift triage?

Because the shift-triage workflow only works if last night is fully indexed by the time the morning reviewer sits down. If the indexing is a batch job that runs at 4 a.m., the review queue is behind by hours, and anything that happens between 4 and 6 a.m. is invisible until tomorrow. Cyrano's median capture-to-reviewable latency is 7 to 8 seconds off the DVR's HDMI output with a 5 to 15 second envelope. That is end-to-end: HDMI frame grab, per-tile crop, overlay mask, classifier, event-row write, thumbnail render, push to dashboard. It is short enough that the queue is never behind; every event from the past hour is already in the list when the reviewer opens the dashboard.

What about live triage, the thing my security operations team actually wants?

Live triage on a consumer DVR is a 16-tile wall of motion. Humans cannot attend to 16 scenes simultaneously; a 1974 study by Tickner and Poulton pegged useful human attention at 9 to 12 minutes before accuracy collapses, and that is on a single-scene task, not a 16-tile mosaic. Live triage works when the tiles that do not need attention stay quiet and the tile that needs attention lights up, with an audible cue and a named event class. The review surface for live triage is therefore not the multiview. It is a notification stream. Same event table as shift triage, filtered to the last 60 seconds, auto-refresh on.

What about forensic lookup? Is that actually fine on a DVR?

It is acceptable if you know the exact channel and the exact time. It collapses if either of those is approximate. A lawyer asks 'do you have anything from around 9 p.m. last Thursday in the lobby,' and now you are scrubbing an 8-hour window across a channel that got renumbered last month. An event index makes forensic lookup trivial, because the iso8601_ts and the tile.label are the filter. The index also ties each event back to the DVR recording: click a thumbnail and the full clip opens, seeked to iso8601_ts minus a 5 to 10 second pre-roll so the approach is visible, not just the moment the classifier triggered.

How does Cyrano know the camera names if it does not talk to the DVR directly?

It reads them off the multiview pixels. Every DVR paints the camera name onto each tile of its HDMI output as a small text strip. Cyrano OCRs that strip once at install, per layout, and stores the result as the tile.label on the event record. That is also why the review dashboard's camera filter chips say Mailroom Interior and Loading Dock NE instead of Channel 4 and Channel 7. The names are stable across channel swaps, because a property manager renames the painted label on the DVR UI before re-cabling. Reviewing by painted name is the review model that survives real-world property operations. Reviewing by channel number is not.

Can I actually do all three review jobs from my phone?

Yes, and this is where the separation matters. On the phone: live triage is the notifications tab, filtered to the last 60 seconds; shift triage is the event list with a tile.label chip and an iso8601_ts window; forensic lookup is the same list with a tighter time window and an event_class pin. All three use the same underlying event record on the same underlying dashboard. What makes it usable on a phone is that none of them require video scrubbing. Scrubbing is a desktop-only motion because it demands a scrub bar and a mouse. Event triage fits in a single scrolling thumbnail strip.

What should a Redditor reviewing footage for a specific incident tonight actually do?

First, name which job you are doing. If the incident is ongoing and you want to see what is happening now, that is live triage and the DVR cannot help you; the multiview is not a live-triage tool. If last night had a reported problem and you are hunting for it, that is shift triage, and 4x scrubbing for 50 hours is the wrong answer; the right answer is any tool that produces a reverse-chronological event list across all your tiles (Cyrano does this in under 2 minutes of install off the HDMI). If a lawyer or cop is asking for a specific clip, that is forensic lookup, and your DVR's Playback screen is actually fine once you have the time and the channel; the problem is usually you have neither. Naming the job first saves hours on every one of them.

🛡️CyranoEdge AI Security for Apartments
© 2026 Cyrano. All rights reserved.

How did this page land for you?

React to reveal totals

Comments ()

Leave a comment to see what others are saying.

Public and anonymous. No signup.