NickM-27
commented
2 years ago Does this only affect a specific camera in the config or call of them? Also describe the event, was a someone walking by, a stationary car, etc?
Closed TheQue42 closed 2 years ago
NickM-27
commented
2 years ago Does this only affect a specific camera in the config or call of them? Also describe the event, was a someone walking by, a stationary car, etc?
TheQue42
commented
2 years ago This specific time, it was in a (to the best of my knowledge) a still livingroom, with a false positive on some cushions in a sofa. Since 99% of my clip-triggers are on the front porch (which is an imou bullet new, instead of a unifi flex in the livingroom), it feels like it doesnt have to do with the camera, but thats a bit of a wild guess.
NickM-27
commented
2 years ago One thing is I notice the record and events have recordings set as active_objects. So a still couch cushion may never have "moved" so no clips were saved as a result.
TheQue42
commented
2 years ago Ah, okey that sounds logical. Its a bit tricky to keep the consequences of all the settings in my mind :-)
But how did it trigger to begin with then? Doesnt it take some movement for the object-detection to kick-in? And whats the relation to sending MQTT notifications if there is a clip available?
What is unfortunately a bit confusing, is the HA log. The automation listed above: motionpcon_send_mqtt_snapshots_to_telegram_camera_group, does NOT try to send any clips.
But the log clearly seems to indicate that my OTHER automation, that waits for the "END" marker in the mqtt and has a {{ trigger.payload_json.after.has_clip == true }} condition, HAS triggered.
NickM-27
commented
2 years ago Ah, okey that sounds logical. Its a bit tricky to keep the consequences of all the settings in my mind :-)
But how did it trigger to begin with then? Doesnt it take some movement for the object-detection to kick-in? And whats the relation to sending MQTT notifications if there is a clip available?
What is unfortunately a bit confusing, is the HA log. The automation listed above:
motionpcon_send_mqtt_snapshots_to_telegram_camera_group, does NOT try to send any clips.But the log clearly seems to indicate that my OTHER automation, that waits for the "END" marker in the mqtt and has a
{{ trigger.payload_json.after.has_clip == true }}condition, HAS triggered.
That does add to the complexity. Motion is required for an object to be detected, and if has_clip is set then it likely had a clip at some point but that clip may have been deleted.
Without steps to reproduce (which would require consistent behavior) it is difficult to say what the issue is as there could be a number of different things happening. If you can get the mqtt payload (viewing in the HA debug trace) of an event that triggered but didn't have any clip that may be helpful.
blakeblackshear
commented
2 years ago Frigate scans for objects on startup regardless of motion. Also, has_clip is based on whether or not recording was enabled and does not actually confirm that a file exists. It assumes if you have recording enabled that recordings were captured.
TheQue42
commented
2 years ago @blakeblackshear : Trying to wrap my head around this. It was not at startup of frigate. We had left the house some time ago, and frigate had definitely been running for a while. But, if I understand correctly, could this have been caused by light-changes in the livingroom window, that triggered motion/object detection, found a false positive, but since my since my retain_mode: is set to active_objects, no recording was made? And this is by design? Its a bit confusing that has_clip can be set, even when no clip is saved. I have verified that recording was enabled, at least according to HA entity states.
blakeblackshear
commented
2 years ago You shouldn't see events for objects that never move (bounding box movement, not lighting changes) from the initial location. If the bounding box grows and shrinks a lot while detecting lighting changes, this is often seen as an object changing location. Active objects should save any recording segment with a frame where that movement occurred.
I most often see this happen because the of corrupt recording segments from flaky connections to the camera. Do you ever see Discarding a corrupt recording segment in the logs? has_clip should always be accurate unless your recordings are unexpectedly missing. It is not by design for has_clip to be true and the video to not be available.
TheQue42
commented
2 years ago I cant of course be sure, but I dont think I've had any issues with these cameras. My two unifi cameras (receiving the stream from unifi-video) are my best performers(stability-wise), and if this had concered my reolink 520, I wouldnt even have bothered creating a ticket, since I know that frigate doesnt seem to fond of the stream it recieves from that one.
stale[bot]
commented
2 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Describe the problem you are having
Once every blue moon, I run into having HA notifications receieved with snapshots, and what is supposed to be a clip as well.
Initially it had to do with the fact that the clip wasnt ready yet, but with the mqtt-updates indicating "end" of event,. most of those problems go away.
Whats left is scenarios, when there for some reason, is no file at all. No clip/recording has been made at all. I can find the event in the event log, but the clip/recording just isnt there when I try to play it.
Version
Debug 0.10.1-83481af
Frigate config file
Relevant log output
FFprobe output from your camera
Frigate stats
Operating system
Other Linux
Install method
Docker CLI
Coral version
M.2
Network connection
Wired
Camera make and model
Mix of hikvison, reolink and unifi.
Any other information that may be helpful
The frigate instance has been restarted since the issue, which may affect the stats output I suspect.
All attempts when I manually turn on the detect/recording switches in HA, everything works fine. Logg-state on the switch.fr_vardagsrum shows that recording was active at the time of the event.