Random "No snapshot available"

[mabed-fr]

Hello

I use ntfy + discord with mqtt and y have 2 times out of three Random "No snapshot available"

How to debug ? Do you know the problem ?

Frigate (0.14.0-bccffe6) eclipse-mosquitto:latest

## SAMPLE CONFIG FILE
# For more info, see docs at https://frigate-notify.0x2142.com/config/file/

## Event Collection Methods
# Note: Only enable one - webapi OR mqtt
frigate:
  # Frigate host URL (ex. https://frigate.yourdomain.tld)
  # This is required for both collection methods
  server: http://192.168.1.254:5000
  # Set to true if using SSL & a self-signed certificate
  ignoressl: true
  # Public / internet-facing Frigate URL, if different from above server address
  public_url: https://******.test.fr

  # List of HTTP headers to send to Frigate, in format Header: Value
  headers:
    # Example:
    # - Authorization: Basic abcd1234

  # On startup, frigate-notify will check reachability of Frigate server
  startup_check:
    # Max number of attempts (Default: 5)
    attempts: 10
    # Interval between attempts, in seconds (Default: 30)
    interval: 30

  webapi:
    # Set to true to enable event collection via the web API
    enabled: 
    # Interval between checking for new events, in seconds (Default: 30)
    interval: 

  mqtt: 
    # Set to true to enable event collection via MQTT
    enabled: true
    # MQTT host IP
    server: 192.168.1.254
    # MQTT host port. (Default: 1883)
    port: 1883
    # MQTT Client ID (Default: frigate-notify)
    clientid:
    # MQTT Authentication. Leave both blank for anonymous
    username: 
    password: 
    # Optionally set custom topic prefix (Default: frigate)
    topic_prefix: 

  cameras:
    # List of cameras to exclude from being monitored
    # Camera names must match frigate configuration
    exclude:

## Alerting methods
# Any combination of alert destinations can be configured
alerts:  
  # General config applies to all alert methods below
  general:
    # Title for any alert messages (Default: Frigate Alert)
    title:
    # Optionally modify default time format in notifications
    # Use Golang's reference time format, or see docs for more info
    timeformat:

  zones:
    # Allow notifications for events outside a zone
    # Set to `drop` to disallow this
    unzoned:
    # List of valid zones to generate alerts
    # If blank, all events with a zone will generate notifications
    allow:
    # List of zones to never generate notifications
    block:

  labels:
    # Filter notifications to only specific labels allowed here
    allow:
      - person
    # List of labels to never generate notifications
    block:

  discord:
    # Set to true to enable alerting via Discord messages
    enabled: true
    # Insert full webhook URL below
    webhook: ***********************
    # Custom notification template, if desired
    template:

  gotify:
    # Set to true to enable alerting via a Gotify push notification server
    enabled: false
    # Server URL (ex. https://push.yourdomain.tld)
    server:
    # Application token generated by Gotify
    token: 
    # Set to true if using SSL & a self-signed certificate
    ignoressl:
    # Custom notification template, if desired
    template:

  smtp:
    # Set to true to enable alerting via SMTP
    enabled: false
    # SMTP server host (ex. smtp.gmail.com)
    server: 
    # SMTP port
    port: 
    # Whether or not the SMTP server requires TLS (Default: true)
    tls: 
    # Sending address / username
    user:
    # SMTP password for above user
    password:
    # Email alerts sent to any addresses listed below, separated by comma
    recipient:
    # Custom notification template, if desired
    template:

  # Telegram Config
  telegram:
    # Set to true to enable alerting via Telegram
    enabled: false
    # Chat ID of alert recipient
    chatid:
    # Bot API token
    token:
    # Custom notification template, if desired
    template:

  # Pushover Config
  pushover:
    # Set to true to enable alerting via Pushover
    enabled: false
    # Pushover API token for this application
    token:
    # User or Group key for recipients
    userkey:
    # Optional list of target devices by name, separated by comma
    devices:
    # Optional message priority, default is 0
    priority:
    # If priority is 2, retry & expiration must be set
    # Values in seconds. Retry must be 30 or higher
    retry:
    expire:
    # Optional message lifetime
    ttl:
    # Custom notification template, if desired
    template:

  # Nfty Config
  nfty:
    # Set to true to enable alerting via nfty
    enabled: true
    # URL of Nfty server
    server: https://ntfy.sh
    # Nfty topic for notifications
    topic: ****************
    # Set to true if using SSL & a self-signed certificate
    ignoressl:
    # Custom notification template, if desired
    template:

  # Webhook Config
  webhook:
    # Set to true to enable alerting via webhook
    enabled: false
    # URL of webhook receiver
    server:
    # Set to true if using SSL & a self-signed certificate
    ignoressl:
    # List of HTTP headers to send to webhook receiver, in format Header: Value
    headers:
      # Example:
      # - Authorization: Basic abcd1234
    # Custom notification template, if desired
    # Note that template must be valid JSON
    template:

## App Monitoring
# Sends HTTP GET to provided URL for aliveness checks
monitor:
  # Set to true to enable app monitoring
  enabled: false
  # URL for monitoring server
  url: 
  # Interval between monitoring check-in events, in seconds
  interval: 
  # Set to true if using SSL & a self-signed certificate
  ignoressl:

[0x2142]

Hi there - So when an event is received from Frigate, it will contain a field named has_snapshot. If this is true, then we'll reach out to Frigate, grab the snapshot, and attach it to the notification. But if has_snapshot is false, then we still send a notification - but instead append text that says no snapshot was available for the event. So likely if you're receiving these notifications, then Frigate told us in the event message that it didn't have any snapshot images for the event at the time.

I've noticed since testing Frigate 0.14 beta, I've been getting more events like this - so I'm wondering if perhaps events are getting sent out quicker than it can generate snapshot images. Usually for me, I'll get 1-2 notifications with no snapshot - then the rest for that event will have an image.

On my todo list for the next release will be a config option to drop events without a snapshot, so that someone could modify that behavior if they like.

[mabed-fr]

I would like to advance this point because I have just checked that I have a snapshot on my disk corresponding to the event, should we continue here or on the frigate project?

the option doesn't interest me unfortunately but nice work

[0x2142]

So you would eventually have a snapshot on disk, because Frigate will generate one - but it may not have one ready by the time the MQTT event goes out. From this app's perspective, I don't try to retrieve a snapshot from Frigate unless the MQTT message says one is available. If the event continues to be updated by Frigate, we usually receive an MQTT message that updates has_snapshot to true - at which point we can send an updated notification that includes the image.

Admittedly, I haven't dug into it too much yet - but my guess at this point is that Frigate might just be taking a little while longer to generate & save a snapshot to disk. In my experience so far, it's not every event - just a small handful. How frequently are you seeing this?

[mabed-fr]

Yes i agree .

I use your system from yesterday i must wait for give my feedback from snapshot missing

[mabed-fr]

I have lot of missing snapshot

[NickM-27]

a couple things to clarify here. Frigate does not write the snapshot to the disk until the event is over. Until then it holds the snapshot in memory. has_snapshot is only based on the criteria of an event (snapshot -> required_zones for example).

[mabed-fr]

a couple things to clarify here. Frigate does not write the snapshot to the disk until the event is over. Until then it holds the snapshot in memory. has_snapshot is only based on the criteria of an event (snapshot -> required_zones for example).

What is you idea for resolving the problem ?

[NickM-27]

maybe just don't send any notification until a snapshot is available, or send a thumbnail instead of a snapshot.

Usually this happens because an object has not moved or has not entered the required zone, the mqtt payload will answer all questions related to this

[freefd]

Dear @NickM-27,

Since the most important thing for any event-based notifications is responsiveness, so from a UX pov, the notification should appear almost instantly to the consumer.

Therefore, the first essential question is how long can take the transition from snapshot is stored in memory to snapshot was written to a disk? And the second one: can this action (the snapshot was written to disk) be reported by the Frigate over MQTT (or even via websocket) somehow?

[NickM-27]

I think the wrong thing is being focused on here. The snapshot being written to disk or not is entirely irrelevant. Whether it is on the disk or in memory does not matter at all from the notification perspective, it is accessible from the api regardless

[NickM-27]

In general, the new /reviews topic in 0.14 would be easier and more reliable to only deliver notifications that the user would care about since they designate if it is an alert or a detection https://github.com/blakeblackshear/frigate/discussions/11554

[mabed-fr]

@0x2142 what do you mean ? use thumbnail before rewrite for 0.14 /reviews MQTT topic ?

[0x2142]

@mabed-fr Please try the new release and let me know if you're still seeing this issue. I made a few changes to reduce notifications by events that may be filtered by Frigate.

I'm working on the /reviews stuff - but no ETA yet

[mabed-fr]

For now it's 100% I close if ok Friday

[freefd]

Hi @mabed-fr,

Just a friendly reminder, last Friday has already gone 👋

[mabed-fr]

Yes is true.

since y have 0 « snapshot not available »