Minor UI tweak suggestions - System page

[leccelecce]

Hi folks. As I'm experimenting with Frigate I'm spending a lot of time tweaking Frigate config, camera config, firewall rules etc as well as recording observations on performance etc. The System page (as upgraded in 0.12 beta) is hugely helpful, but I had to put some effort into understanding it.

As many people will likely have to go on the same journey I was thinking of some minor UI tweaks which might help explain things. I know some of the information is in the API docs, but most people won't have any reason to go near there.

Detectors

-Detection start - this might be a bit more understandable expressed as number of milliseconds ago? If you don't know what an epoch timestamp is, it just looks like a very large number
-Similarly might help to put "ms" after Inference speed so people understand the units here.
-Maybe also round it to 1dp - as I assume few of us have machines capable of <0.09ms inference times
-CPU usage would be nice - I can see the PID's util% is included in /api/stats already. You show the CPU% for each cameras detect process, but this is usually low single digits for me with the detector processes themselves occupying 50%+
-It would be interesting to be able to see the size of the detection queue across all detectors

Cameras

-Explain different FPS measures e.g. there is an ffmpeg process/FPS, but I see up to 4x ffmpeg processes per camera - 1 each for record/detect streams, 1 for copying cache to recordings. What is "Capture" vs "ffmpeg"?
-If detect is disabled for a camera, preferably state "disabled" rather than showing it with 0 fps (though arguably should the detect process even be running...)
-Pretty-print JSON ffprobe output - it's not particularly easy to read, I end up copying it into Notepad++ and re-formatting it

If you agree some of these would be helpful I would be happy to submit a PR.

[NickM-27]

I have been brainstorming about having some sort of ? icon next to certain parts of the UI that when hovered over would show a tooltip explaining in more detail. I do agree the information is only helpful when it is understood so that is important.

-Detection start - this might be a bit more understandable expressed as number of milliseconds ago? If you don't know what an epoch timestamp is, it just looks like a very large number

for me this value is always 0, I think it represents something different than the epoch of when it started but I haven't ever worked on that part so not 100% how it works

-Similarly might help to put "ms" after Inference speed so people understand the units here

agreed

-Maybe also round it to 1dp - as I assume few of us have machines capable of <0.09ms inference times

maybe, but I don't see the harm in having 2

-CPU usage would be nice - I can see the PID's util% is included in /api/stats already. You show the CPU% for each cameras detect process, but this is usually low single digits for me with the detector processes themselves occupying 50%+

that should only be the case when using a CPU detector, which means that field would have nothing to show for most users that have a detection accelerator

-Explain different FPS measures e.g. there is an ffmpeg process/FPS, but I see up to 4x ffmpeg processes per camera - 1 each for record/detect streams, 1 for copying cache to recordings.

it depends how your config is setup. There may be 1 ffmpeg process for both detect & record or there may be 1 for each. In any case, the ffmpeg shown in the system page is the one that is running detect since that is the only ffmpeg process that will be using a non-negligible amount of CPU. the recording, faststart (mover), etc. ffmpeg processes use basically no CPU.

What is "Capture" vs "ffmpeg"?

Capture is the process that manages the ffmpeg process, checks that it is running & continuing to output new frames. Ffmpeg is the actual process decoding the camera stream

-If detect is disabled for a camera, preferably state "disabled" rather than showing it with 0 fps (though arguably should the detect process even be running...)

yes the detect should still be running as motion detection is still used to decide recording retention and to feed the birdseye view.

[leccelecce]

-Detection start - this might be a bit more understandable expressed as number of milliseconds ago? If you don't know what an epoch timestamp is, it just looks like a very large number

for me this value is always 0, I think it represents something different than the epoch of when it started but I haven't ever worked on that part so not 100% how it works

It's definitely the epoch - sticking the number into a converter tells me it's usually a time in the last few seconds. At time of writing mine says 1673294659.695666. Weirdly when I was searching the repo I couldn't actually find what populates it though to prove it.

-CPU usage would be nice - I can see the PID's util% is included in /api/stats already. You show the CPU% for each cameras detect process, but this is usually low single digits for me with the detector processes themselves occupying 50%+

that should only be the case when using a CPU detector, which means that field would have nothing to show for most users that have a detection accelerator

Option column that's only visible if detector type: cpu? I think it's valuable information to show for those using cpu detectors, if for no other reason to make them aware of the impact.

What is "Capture" vs "ffmpeg"?

Capture is the process that manages the ffmpeg process, checks that it is running & continuing to output new frames. Ffmpeg is the actual process decoding the camera stream

OK, so the capture process isn't that interesting then. In my environment, the Capture fps is always identical to the ffmpeg fps - if that is always the case, is there value in showing it? Or am I missing something? I've tried looking in the code but the internal variables seem to be named Camera, Process and Detection and I've not traced them through to how they map to Capture, ffmpeg, Detect.

[NickM-27]

It's definitely the epoch - sticking the number into a converter tells me it's usually a time in the last few seconds. At time of writing mine says 1673294659.695666. Weirdly when I was searching the repo I couldn't actually find what populates it though to prove it.

I wasn't saying it wasn't an epoch, I said it wasn't when the detector started.

I found it here

frigate/frigate/object_detection.py

Line 119 in e79eab7

start.value = datetime.datetime.now().timestamp()

you can see that it sets the start value and then after running the detection it sets the start value back to 0. This basically is a way to keep track of the last detection and if it is running longer than 10 seconds the detection process is considered stuck and is killed.

So it could make sense instead of showing a number to change that column to be Detector Status or something and show "Idle" when the value is 0 and "Started X milliseconds ago" otherwise

Option column that's only visible if detector type: cpu? I think it's valuable information to show for those using cpu detectors, if for no other reason to make them aware of the impact.

yeah it could probably be added just for CPU detectors.

OK, so the capture process isn't that interesting then. In my environment, the Capture fps is always identical to the ffmpeg fps - if that is always the case, is there value in showing it? Or am I missing something? I've tried looking in the code but the internal variables seem to be named Camera, Process and Detection and I've not traced them through to how they map to Capture, ffmpeg, Detect.

Of course there is, because it may not be the case and that will give info on whether or not the capture process is keeping up with the ffmpeg output

[leccelecce]

I wasn't saying it wasn't an epoch, I said it wasn't when the detector started.

Ah sorry this is my fault - I meant detect_ion_ rather than detector. Agree your column changes would be clearer.

Of course there is, because it may not be the case and that will give info on whether or not the capture process is keeping up with the ffmpeg output

That makes sense to me now, thanks. In that case, as well as tooltips to explain the fields, I think it would be useful to re-order them ffmpeg -> capture -> detect if that's the data flow?

As before, happy to send a PR with at least some of the simpler tweaks in it if you guys are open to that.

[NickM-27]

That makes sense to me now, thanks. In that case, as well as tooltips to explain the fields, I think it would be useful to re-order them ffmpeg -> capture -> detect if that's the data flow?

yeah that makes sense to me, I did it alphabetically

As before, happy to send a PR with at least some of the simpler tweaks in it if you guys are open to that.

we are always happy to accept contributions / PRs

[leccelecce]

PR #4985 sent for some of the minor tweaks that didn't require core changes - will send those separately once local core dev env is working