Your DVR does not have a search feature. It has a timeline with a motion filter.

Because what the menu labels Search is a timeline scrub with a motion filter on top. The DVR stored raw pixel differences frame by frame while recording, and when you hit Search it redraws the timeline with the motion-dense segments highlighted. There is no event row, no class label, no actor identity, no zone. A plastic bag drifting across the lot produces the same highlight as a person loitering at the mailroom. Real search requires a pre-built index where each row represents a discrete event with a label (person_in_zone, vehicle_dwell, loiter, tamper, and so on) and a timestamp, so you can filter by what happened. Consumer DVRs do not build that index, which is why the workflow collapses into scrubbing.

Nine fields plus a thumbnail. tile.label is the camera name the DVR stamps on its multiview strip (for example Mailroom Interior), which is the stable key a property manager remembers. tile.index is the row-major position on the multiview grid. tile.coords is the pixel rectangle inside the composite frame, which lets the pipeline crop the tile cleanly. property is the site identifier. layout_id is the recorder layout (4x4-std, 3x3-std, custom), which is how the overlay mask template gets picked. overlay_mask is the list of DVR chrome regions that got blanked before inference (typical: clock, cam_name_strip, channel_bug). event_class is the semantic label the classifier assigned. iso8601_ts is the recorder clock time. latency_ms is capture-to-delivery. That shape is what lets filtering work. Remove any one of those fields and search either becomes unreliable (drop overlay_mask and the detector scores boxes on the clock glyph) or brittle (drop tile.label and your queries break when maintenance swaps channels).

A DVR composite signal is not a clean feed. Every recorder paints a clock strip, a per-tile camera name banner, and a channel bug onto the mosaic before pushing it out the HDMI port. A classifier that sees those pixels will occasionally score a confident bounding box on the colon glyph inside the clock, or on the letterforms of the camera name. For a search index that is catastrophic: every such false positive becomes an event row, the index fills with noise, and real events get buried. The overlay_mask field records exactly which overlay regions were blanked out on a given layout_id, once at install time. Once a layout is masked, the detector only sees the scene inside each tile. No consumer DVR does this because consumer DVRs do not run classifiers at all, and no third-party cloud-NVR does it because they get clean per-camera RTSP streams rather than composite video.

Because storage and search are different products. The DVR's disk is a blob of H.264 or H.265 that is addressable by (channel, timestamp). That lets you play back footage if you already know the channel and the time. It does not let you ask a question like 'show me every time someone stood in the mailroom alcove for longer than 20 seconds outside 9 a.m. to 8 p.m. last week.' To answer that you need a row per event with the zone, the dwell, and the timestamp. The raw video keeps its job, the index does its job, and the two are tied together by iso8601_ts so a click on a thumbnail in the index opens the full clip on the DVR.

You filter the index. In the Cyrano dashboard the filters are: property, tile.label (the camera name the DVR already stamps on the multiview), event_class (person_in_zone, loiter, vehicle_dwell, tamper, or all), and an iso8601_ts window. The results render as a reverse-chronological thumbnail strip. Click a thumbnail and the full clip opens. No scrubbing, no 4x playback, no channel-number math. For integrators who want to script against the index, there is a SQL surface that reads the same underlying event table with the same nine fields.

Channel numbers are assigned by the DVR. When a tech swaps cameras on a re-cable, or when maintenance rearranges the multiview to put the loading dock on a bigger tile, the channel number on a given camera changes. Every saved search that referenced CH6 now points at a different camera. tile.label is the human-readable name that gets painted onto the tile itself (Loading Dock NE, Mailroom Interior, Lobby W). Property managers already know those names because that is what they see on the monitor. Cyrano reads them off the composite frame using OCR at install time, then uses them as the stable key. A search for Mailroom Interior keeps working even if the recorder channel underneath changes.

Median capture-to-delivery is 7 to 8 seconds on a 25-tile multiview, 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 the dashboard. A person who walks into a detection zone at 2:04:12 p.m. is searchable at 2:04:20 p.m. No end-of-day batch indexing. No cloud upload waiting on a residential uplink.

No. Cyrano plugs into the HDMI output that already drives the monitor in the office or guard booth. One HDMI cable in, one HDMI cable out to the monitor, one network cable, one power plug. Under two minutes of physical install on a running DVR. Nothing on the recorder changes. The cameras stay exactly where they are, whether they are analog over coax, IP over PoE, or a mixed fleet. Supported recorders include Hikvision DS-7xxx, Dahua XVR and NVR, Lorex, Amcrest, Reolink NVR, Uniview, Swann, Night Owl, Q-See, ANNKE, EZVIZ, Bosch DIVAR, Honeywell Performance, and Panasonic WJ-NX, along with the long tail of rebrands. If your recorder has an HDMI port, the search index is a plug-in.

Yes. The event index is a single table keyed by the property field. A regional manager with 12 sites can open one dashboard, leave property unset, and filter by tile.label or event_class across the whole portfolio. Before this, searching across mixed-brand recorders (say a Hikvision at one property and a Dahua at another) was impossible at the DVR level because each recorder has its own proprietary playback UI and export format. Moving search up into the index layer makes the underlying recorder irrelevant to the search experience.

Nothing. The DVR continues recording continuously to its own disk under whatever retention policy was already in place. The index is a parallel structure. About 99 percent of the time, a property manager can answer a review question from the index alone. For the 1 percent case (a subpoena asking for a specific two-hour window with no events, or the five minutes leading up to a flagged event) the full DVR recording is still there to pull from. Fast search for the common case, unchanged archive for the long tail.

If you have an unsolved incident sitting on a DVR right now, stop scrubbing the timeline. Write down the two or three tile names you remember from the multiview, the rough time window, and the event class (person, vehicle, loiter, tamper). Those are the four filters a real search index needs. If your DVR does not expose those filters, the answer is not to keep scrubbing faster. The answer is to put a search index on top of the recorder, which is what Cyrano does off the HDMI output in under two minutes of install time.