You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This commit was created on GitHub.com and signed with GitHub’s verified signature.
A Tools tab with the measurements that used to need a terminal. Off by default;
switch it on under Settings → Does it work?. It runs three analyses that so far only
existed as scripts: how fast a recognition is, how well each person is covered, and why
events yield no usable face.
This is not a convenience wrapper around the scripts — it could not be. scripts/ is not
in the app image at all (the Dockerfile ships app/ and static/), and the delay
measurement read journalctl, which does not exist in a container without systemd. For
anyone running FaceID as a Home Assistant app, those analyses were unreachable, not just
inconvenient.
The delay measurement therefore uses a different source than the script: the history
instead of the log. The event's start time is in the Frigate event id anyway, and the
moment the name went out is in the history entry — so it needs neither the log nor camera
access, and answers instantly.
Recognitions from a history scan are excluded from the delay figures rather than silently
averaged in; they lag their event by weeks and would wreck every median. The count of
what was dropped is shown.
Corrected: there is no 3-second floor. README and the notification blueprint said the
name takes 3 seconds at the very best, "because that is how long Frigate takes to produce
the first snapshot". The new tool made it checkable, and 18% of recognitions land below
that, the fastest in 0.8s. The old figure was the median of first attempts in an older
sample, written up as a physical limit. Both measurement paths — the log-based script and
the history — now agree: median 8-9s, fastest around 1s, and the floor varies per event.
Clocks were compared between Frigate and the container first; they match to the second.
The history no longer prints a similarity of 1.0 as if it meant something. Every such
entry was a face that had since been assigned, so it is one of that person's reference
photos and matches itself. It now reads "now assigned: ", without a number.
retry_seconds: 1.2 (down from 2.5) is confirmed to have worked: attempt 2 went from a
median of 6.5s to 4.0s.
Two long-standing bugs in the background jobs, found while reviewing the new one and
fixed for the history scan and the calibration analysis as well:
A failing import inside a worker killed the thread before the finally that clears the
running flag. The job then stayed "running" forever and every later start answered 409 already running until a service restart — with that message as the only clue, pointing
at everything except the real cause. Verified by breaking the import on purpose.
Starting a job checked the running flag and set it in two separate steps, so two
simultaneous starts could both get past the guard. Now held under one lock.