Create snapshot functionality from History view by nrlcode · Pull Request #22639 · blakeblackshear/frigate

nrlcode · 2026-03-25T18:55:42Z

Please read the contributing guidelines before submitting a PR.

Proposed change

This PR adds snapshot support to the History/Recording player flow.

Adds a snapshot action in History player controls.
Captures the snapshot from the active playback frame (video element), not from the live snapshot endpoint.
Uses playback/timeline timestamp for filename generation (with timezone-aware formatting) so downloaded filenames align with the History timeline context.

This improves user workflows when reviewing recordings and exporting a frame from a specific playback moment.

I tried to re-use the functionality from Frigate+ and keep the scope of changes minimal.

VideoControls.tsx: adds snapshot button API/UI.
HlsVideoPlayer.tsx: wires button to capture/download in History player.
snapshotUtil.ts: playback-timestamp + timezone filename and capture-from-current-video support.
DynamicVideoPlayer.tsx: passes supportsSnapshot down.
RecordingView.tsx: enables snapshot for History.

Type of change

Dependency upgrade
Bugfix (non-breaking change which fixes an issue)
New feature
Breaking change (fix/feature causing existing functionality to break)
Code quality improvements to existing code
Documentation Update

Additional information

This PR fixes or closes issue: fixes #
This PR is related to issue:
Link to discussion with maintainers (required for large/pinned features): Add the ability to take snapshots when viewing history of cameras #22624

For new features

There is an existing feature request or discussion with community interest for this change.
- Link: Add the ability to take snapshots when viewing history of cameras #22624

AI disclosure

No AI tools were used in this PR.
AI tools were used in this PR. Details below:

AI tool(s) used (e.g., Claude, Copilot, ChatGPT, Cursor):
ChatGPT/Codex

How AI was used (e.g., code generation, code review, debugging, documentation):
Used for implementation assistance, debugging, and refinement of targeted frontend changes.

Extent of AI involvement (e.g., generated entire implementation, assisted with specific functions, suggested fixes):
Assisted with specific functions and targeted fixes. Final scope and selected commits were manually controlled.

Human oversight: Describe what manual review, testing, and validation you performed on the AI-generated portions.
I manually reviewed all changed files, validated commit scope against origin/dev, and tested snapshot behavior in the History viewer. I also ran frontend checks used during iteration (lint/build flow) and validated behavior in containerized test deployment.

Checklist

The code change is tested and works locally.
Local tests pass. Your PR cannot be merged unless tests pass
There is no commented out code in this PR.
I can explain every line of code in this PR if asked.
UI changes including text have used i18n keys and have been added to the en locale.
The code has been formatted using Ruff (ruff format frigate) [N/A]

hawkeye217 · 2026-03-25T19:57:54Z

web/src/components/player/dynamic/DynamicVideoPlayer.tsx

  setFullResolution: React.Dispatch<React.SetStateAction<VideoResolutionType>>;
  toggleFullscreen: () => void;
  containerRef?: React.MutableRefObject<HTMLDivElement | null>;
+  supportsSnapshot?: boolean;


supportsSnapshot is a pure pass-through prop that adds noise here. Since it ends up as snapshot: supportsSnapshot in the features object inside HlsVideoPlayer, the cleaner approach is just to infer it from whether onSnapshot is provided - the same way plusUpload is already gated on onUploadFrame existing. That would eliminate this prop chain entirely.

I would just mirror what we already do with onUploadFrame.

I removed the supportsSnapshot prop chain entirely and now infer snapshot support directly from onSnapshot presence in HlsVideoPlayer (same pattern as other callback-gated features like upload).

hawkeye217 · 2026-03-25T19:58:35Z

web/src/components/player/HlsVideoPlayer.tsx

    const currentTime = videoRef.current?.currentTime;

-    if (!currentTime) {
+    if (currentTime == undefined) {


This change here seems unrelated to snapshots. Am I missing something?

Agreed. That change was unrelated to snapshot scope. I reverted the logic back to its previous behavior so this PR only carries snapshot-specific changes.

hawkeye217 · 2026-03-25T19:58:57Z

web/src/components/player/HlsVideoPlayer.tsx

            const frameTime = getVideoTime();

-            if (frameTime && onUploadFrame) {
+            if (frameTime != undefined && onUploadFrame) {


This change also seems unrelated to snapshots.

Reverted this to the previous check to keep scope tight and avoid unrelated behavioral changes in this snapshot PR.

hawkeye217 · 2026-03-25T19:59:11Z

web/src/components/player/HlsVideoPlayer.tsx

              const frameTime = getVideoTime();

-              if (frameTime) {
+              if (frameTime != undefined) {


This change also seems unrelated to snapshots.

Also reverted for the same reason

hawkeye217 · 2026-03-25T20:02:53Z

web/src/utils/snapshotUtil.ts

+  });
+
+  const safeTimestamp =
+    timestamp === "Invalid time"


formatUnixTimestampToDateTime returns the string "Invalid time" on bad input, and this is meant for UI display. But you are pattern-matching on that magic string as error handling. If that return value ever changes, this silently breaks. I would just validate the input before calling the formatter instead, or don't use a formatter at all (since Live view's snapshot download has no formatting, either).

Sounds good. I removed the check and now validate the input timestamp before calling the formatter (finite-number validation). If invalid/missing, it falls back to current time; if valid, it uses the playback timestamp. This avoids coupling to formatter UI text.

nrlcode · 2026-03-25T21:54:26Z

I pushed a cleanup commit that narrows this PR to snapshot functionality only: removed supportsSnapshot pass-through, restored unrelated time guard changes, and replaced "Invalid time" string matching with explicit input validation in snapshot filename generation.

hawkeye217 · 2026-03-26T13:39:04Z

web/src/components/player/HlsVideoPlayer.tsx

    return currentTime + inpointOffset;
  }, [videoRef, inpointOffset]);

+  const handleSnapshot = useCallback(async () => {


We'll need some kind of loading guard that disables the button while the snapshot is being downloaded (like is done in LiveCameraView's snapshot handler), because a user could spam click the snapshot button, which in most cases will cause the browser to just download a bunch of black frames.

Added in the guarding features!

hawkeye217 · 2026-03-27T14:10:21Z

web/src/components/player/HlsVideoPlayer.tsx

-      toast.error(t("snapshot.captureFailed", { ns: "views/live" }), {
-        position: "top-center",
-      });
+    if (isSnapshotLoading) {


There's some unnecessary redundancy here, I would remove this guard from the callback entirely and let VideoControls handle it. The onClick in VideoControls already has if (snapshotLoading) return, so the callback never fires while loading. That would match the existing pattern of other things here where the component prevents re-triggering, not the handler.

hawkeye217 · 2026-03-28T13:21:24Z

web/src/components/player/VideoControls.tsx

+              ? "cursor-not-allowed opacity-50"
+              : "cursor-pointer",
+          )}
+          title={snapshotTitle}


I'd remove this. None of the other buttons here have a title.

History: add snapshot support in recording player

c5e816f

hawkeye217 requested changes Mar 25, 2026

View reviewed changes

Snapshot: simplify control wiring and scope cleanup

84c1836

hawkeye217 requested changes Mar 26, 2026

View reviewed changes

Snapshot: guard against repeated download clicks

9e56382

hawkeye217 reviewed Mar 27, 2026

View reviewed changes

Snapshot: move spam-click guard to controls layer

bef2ecd

hawkeye217 reviewed Mar 28, 2026

View reviewed changes

Uh oh!

Conversation

nrlcode commented Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed change

Type of change

Additional information

For new features

AI disclosure

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hawkeye217 Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nrlcode commented Mar 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nrlcode commented Mar 25, 2026 •

edited

Loading

hawkeye217 Mar 25, 2026 •

edited

Loading