[Bug]: Autotracking silently stops until restart if the camera drops during a RelativeMove (exception kills _process_move_queue)

[specializedken]

Checklist

• I have updated to the latest available Frigate version.
• I have cleared the cache of my browser.
• I have tried a different browser to see if it is related to my browser.
• I have tried reproducing the issue in incognito mode to rule out problems with any third party extensions or plugins I have installed.
• I have asked the AI at https://docs.frigate.video about my issue.

Describe the problem you are having

If a camera goes offline while a RelativeMove is in flight, autotracking on that camera stops for good until Frigate is restarted. Detection, recording and the autotracker state all look normal: the toggle stays ON, the camera comes back, and GetStatus works. Frigate keeps logging Enqueue movement, but no move is ever sent, and nothing is logged at warning or error level to say so.

From reading the source, the likely cause is this:

• _move_relative awaits RelativeMove with no try/except (ptz/onvif.py). The neighbouring _move catches and logs the same kind of failure.
• _process_move_queue (ptz/autotrack.py) only catches TimeoutError around move_queue.get(), so an exception from the move escapes the while loop and ends the coroutine.
• The coroutine is started with asyncio.run_coroutine_threadsafe(...) and the returned future is discarded, so the exception is never retrieved or logged.
• _enqueue_move only checks the timestamps and the queue lock. Both pass, so moves keep going into a queue nobody reads.

GotoPreset in _move_to_preset is also unguarded, and it runs from camera_maintenance, so it may be worth a look too. I did not observe a failure there.

The same code is in dev today: _process_move_queue still catches only TimeoutError around the queue read, and RelativeMove is still awaited unguarded.

I have not captured the exception itself, because nothing logs it. The cause above comes from the source plus the log pattern below.

Observed

Times are UTC, on one camera, with frigate.ptz debug logging on:

Time	What happened
06:13:32.645	called RelativeMove, the last one ever logged
06:13:52	No frames received ... in 20 seconds, RTSP connection times out
06:14:24	Camera garage does not support the ONVIF GetStatus method (camera unreachable)
~06:18:04	Camera finishes rebooting
06:18:27	GetStatus answers IDLE again, polled by camera_maintenance
06:18:27 to 07:03	325 Enqueue movement lines, 0 called RelativeMove, 0 dequeueing

The camera head did not move on any event after that, including a person who walked across the full frame for 72 s. The stall was still present at the last event I checked, 6 hours later.

Steps to reproduce

1. Enable autotracking on an ONVIF PTZ camera.
2. While it is tracking, make the camera unreachable so a RelativeMove fails (power it off or drop it from the network mid-move).
3. Bring the camera back.
4. Walk through the frame. The object is detected, Enqueue movement is logged at debug level, and the camera does not move.
5. Restart Frigate. Tracking works again.

I hit this once, from a real camera crash. I have not reproduced it on purpose yet.

Version

0.18.2-cfa08c5

In which browser(s) are you experiencing the issue with?

No response

Frigate config file

# yaml-language-server: $schema=http://192.168.1.162:5000/api/config/schema.json
go2rtc:
  streams:
    front_room_nest: 
      nest:?client_id={FRIGATE_NEST_OAUTH_CLIENT_ID}&client_secret={FRIGATE_NEST_OAUTH_CLIENT_SECRET}&refresh_token={FRIGATE_NEST_DEVICE_REFRESH_TOKEN}&project_id={FRIGATE_NEST_DEVICE_ACCESS_PROJECT_ID}&device_id={FRIGATE_NEST_CAMERA_ID_FRONT_ROOM}&protocols=WEB_RTC&video=h264&audio=opus

mqtt:
  enabled: true
  host: localhost

birdseye:
  enabled: false

# Optional: logger verbosity settings
logger:
  # Optional: Default log verbosity (default: shown below)
  default: info
  # default: debug
  logs:  # debug on 2026-10-20 to catch stale-frame overshoot (kitchen 10:44 JST event); remove again after capturing one
    frigate.ptz.autotrack: debug
    frigate.ptz.onvif: debug

ffmpeg:
  hwaccel_args: preset-vaapi
  #hwaccel_args: preset-intel-qsv-h265
  output_args:
    # preset-record-generic-audio-copy doesn't work for some reason
    #record: preset-record-generic-audio-aac
    record: preset-record-generic-audio-copy

snapshots:
  enabled: true
  retain:
    default: 180

detect:
  enabled: true
  fps: 5

face_recognition:
  enabled: true

lpr:
  enabled: true
  min_plate_length: 4        # drop partial reads like "50"
  recognition_threshold: 0.9 # default, explicit
  # known_plates:            # fill in to get sub_labels instead of just recognized_license_plate
  #   Kevin's car:
  #     - "12-34"
  match_distance: 1
  debug_save_plates: true

# Optional: Object configuration
# NOTE: Can be overridden at the camera level
objects:
  # Optional: list of objects to track from labelmap.txt (default: shown below)
  track:
    - person
    - bicycle
    - car
    - motorcycle
    - airplane
    - bus
    - car
    - bird
    - cat
    - dog
    - horse
    - sheep
    - elephant
    - bear
    - zebra
    - hat
    - backpack
    - shoe
    - eye glasses
    - handbag
    - suitcase
    - skis
    - snowboard
    - kite
    - baseball bat
    - baseball glove
    - skateboard
    - tennis racket
    - bottle
    - plate
    - wine glass
    - cup
    - fork
    - knife
    - spoon
    - bowl
    - banana
    - apple
    - sandwich
    - orange
    - broccoli
    - carrot
    - hot dog
    - pizza
    - donut
    - cake
    - potted plant
    - mirror
    - dining table
    - window
    - desk
    - door
    - mouse
    - remote
    - keyboard
    - cell phone
    - microwave
    - oven
    - toaster
    - sink
    - book
    - clock
    - vase
    - scissors
detectors:
  ov:
    type: openvino
    device: GPU
  #coral:
  #  type: edgetpu
  #  device: usb

model:
  width: 300
  height: 300
  input_tensor: nhwc
  input_pixel_format: bgr
  path: /openvino-model/ssdlite_mobilenet_v2.xml
  labelmap_path: /openvino-model/coco_91cl_bkgr.txt

record:
  enabled: true
  alerts:
    retain:
      days: 180
  detections:
    retain:
      days: 180

  continuous:
    days: 15
  motion:
    days: 15
cameras:
  nest_front_room:
    enabled: true
    detect:
      enabled: true
      width: 1280  # explicit: probing a cold Nest stream at startup times out
      height: 720
      fps: 5
    ffmpeg:
      inputs:
        - path: rtsp://127.0.0.1:8554/front_room_nest
          roles:
            - record
            - detect
            - audio

  garage:
    onvif:  # native ONVIF service on the cam (atomcam_tools fork)
      host: 192.168.1.129
      port: 80
      user: ''
      password: ''
      autotracking:
        enabled: true
        calibrate_on_startup: false  # off 2026-10-15: weights varied up to 2x between calibrations, so every restart changed tracking; recalibrate deliberately (remove movement_weights + set true + restart, then set back to false). Garage recalibrated 2026-10-16 08:26 UTC.
        zooming: disabled
        required_zones:
          - autotrack_all
        return_preset: home
        timeout: 15
        movement_weights: 0.0, 1.0, 1.0, 0.16595622841868557, 
          0.5584486744922691, 0
    zones:
      autotrack_all:  # full frame; Frigate requires >=1 zone for autotracking
        coordinates: 0,0,1,0,1,1,0,1
        loitering_time: 0
    ffmpeg:
      # GPU decode again (global preset-vaapi) since 2026-10-12: the "ref loss storm" was the cam's 50 KB RTSP send buffer dropping keyframe packets, fixed in the cam firmware (v15)
      # no audio track on the cam any more (RTSP_AUDIO2=off), so no audio role and no audio in the recordings
      # QSV decode on this cam since 2026-10-13: VAAPI died (-EIO 'Failed to sync surface') on any corrupt/missing-ref frame, 226 crashes in 16.8 h vs 0 for QSV on kitchen.
      # Revert to VAAPI: delete the next line (backup: config.yml.pre-garage-qsv).
      hwaccel_args: preset-intel-qsv-h265
      # low-latency input 2026-10-15 (autotrack lag): preset-rtsp-generic args + nobuffer/low_delay. Revert: delete input_args (backup: config.yml.pre-garage-lowlat)
      input_args: -user_agent FFmpeg_Frigate -avoid_negative_ts make_zero 
        -fflags +genpts+discardcorrupt+nobuffer -flags low_delay -rtsp_transport
        tcp -timeout 10000000 -use_wallclock_as_timestamps 1
      output_args:
        record: preset-record-generic
      inputs:
        # HEVC / h265
        - path: rtsp://192.168.1.129:8554/video2_unicast
          roles:
            - record
            - detect

        # h264
        # - path: rtsp://192.168.1.129:8554/video0_unicast
        #   roles:
        #     - record
        #     - detect
        #     - audio
        # sub stream 640x360
        # - path: rtsp://192.168.1.129:8554/video1_unicast
        #   roles:
        #     - detect

    motion:
      mask:
        motion_mask_1:
          friendly_name: Motion Mask 1
          enabled: true
          coordinates: 
            0,0.277,0.115,0.209,0.213,0.147,0.474,0.068,0.483,0.194,0.556,0.372,0.646,0.407,0.758,0.351,0.738,0.151,0.776,0.049,1,0.194,1,0,0.001,0.002,0,0.123
        motion_mask_2:
          friendly_name: Motion Mask 2
          enabled: true
          coordinates: 0.723,0.931,0.974,0.931,0.974,0.983,0.719,0.978
      threshold: 30
      contour_area: 10
      improve_contrast: true
  kitchen:
    onvif:  # native ONVIF service on the cam (atomcam_tools fork)
      host: 192.168.1.50
      port: 80
      user: ''
      password: ''
      autotracking:
        enabled: true
        calibrate_on_startup: false  # off 2026-10-15: weights varied up to 2x between calibrations, so every restart changed tracking; recalibrate deliberately (remove movement_weights + set true + restart, then set back to false)
        zooming: disabled
        required_zones:
          - autotrack_all
        return_preset: home
        timeout: 15
        movement_weights: 0.0, 1.0, 1.0, 0.20214029640279793, 
          0.32022326300221104, 0
    zones:
      autotrack_all:  # full frame; Frigate requires >=1 zone for autotracking
        coordinates: 0,0,1,0,1,1,0,1
        loitering_time: 0
    ffmpeg:
      # GPU decode again (global preset-vaapi) since 2026-10-12: the "ref loss storm" was the cam's 50 KB RTSP send buffer dropping keyframe packets, fixed in the cam firmware (v15)
      # no audio track on the cam any more (RTSP_AUDIO2=off), so no audio role and no audio in the recordings
      # A/B 2026-10-12: QSV decode on this cam only (garage keeps global preset-vaapi). VAAPI dies (-EIO) on corrupt slice data; QSV survived the offline repro. Software decode (hwaccel_args: []) gave 0 crashes in 118 min.
      # Revert to software: hwaccel_args: [] (backup: config.yml.pre-kitchen-qsv); to VAAPI: delete the line.
      hwaccel_args: preset-intel-qsv-h265
      # low-latency input 2026-10-16, same as garage (A/B probe: image onset ~0.25 s earlier). Revert: delete input_args
      input_args: -user_agent FFmpeg_Frigate -avoid_negative_ts make_zero 
        -fflags +genpts+discardcorrupt+nobuffer -flags low_delay -rtsp_transport
        tcp -timeout 10000000 -use_wallclock_as_timestamps 1
      output_args:
        record: preset-record-generic
      inputs:
        # HEVC / h265
        - path: rtsp://192.168.1.50:8554/video2_unicast
          roles:
            - record
            - detect

        # h264
        # - path: rtsp://192.168.1.50:8554/video0_unicast
        #   roles:
        #     - record
        #     - detect
        #     - audio

        # sub stream 640x360
        # - path: rtsp://192.168.1.50:8554/video1_unicast
        #   roles:
        #     - detect

    motion:
      mask:
        motion_mask_1:
          friendly_name: Motion Mask 1
          enabled: true
          coordinates: 0.722,0.932,0.72,0.98,0.976,0.983,0.974,0.934
        motion_mask_2:
          friendly_name: Motion Mask 2
          enabled: true
          coordinates: 0,0,1,0,1,0.34,0,0.347
      threshold: 30
      contour_area: 10
      improve_contrast: true

version: 0.18-0

docker-compose file or Docker CLI command

services:
  frigate:
    container_name: frigate
    privileged: true # this may not be necessary for all setups
    restart: unless-stopped
    image: ghcr.io/blakeblackshear/frigate:stable
    shm_size: "512mb" # update for your cameras based on calculation above
    devices:
      - /dev/bus/usb:/dev/bus/usb # passes the USB Coral, needs to be modified for other versions
      # - /dev/apex_0:/dev/apex_0 # passes a PCIe Coral, follow driver instructions here https://coral.ai/docs/m2/get-started/#2a-on-linux
      - /dev/dri/renderD128 # for intel hwaccel, needs to be updated for your hardware
    volumes:
      - /etc/localtime:/etc/localtime:ro
      # - /home/kevin/frigate/config.yml:/config/config.yml
      - /home/kevin/frigate:/config
      - /media/Tac/frigate:/media/frigate
      # - type: tmpfs # Optional: 1GB of memory, reduces SSD/SD Card wear
      #   target: /tmp/cache
      #   tmpfs:
      #     size: 100000000
    network_mode: host
    # json-file log rotation: unbounded growth + NULs after hard resets broke `docker logs` (2026-10-11)
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "5"
    environment:
        ****REDACTED****

Relevant Frigate log output

2026-10-31 06:13:32 frigate.ptz.autotrack  DEBUG   : garage: Enqueue movement for frame time: 1793427211.840375 pan: -0.0489...
2026-10-31 06:13:32 frigate.ptz.onvif      DEBUG   : garage called RelativeMove: pan: -0.0489...
2026-10-31 06:13:32 frigate.ptz.onvif      DEBUG   : garage: PTZ start time: 1793427212.251859
2026-10-31 06:13:52 watchdog.garage        INFO    : No frames received from garage in 20 seconds. Exiting ffmpeg...
2026-10-31 06:14:24 frigate.ptz.onvif      WARNING : Camera garage does not support the ONVIF GetStatus method. ...
2026-10-31 06:18:27 frigate.ptz.onvif      DEBUG   : garage: Pan/tilt status: IDLE, Zoom status: IDLE
2026-10-31 06:18:27 frigate.ptz.onvif      DEBUG   : garage: PTZ stop time: 1793427212.920967
...
2026-10-31 07:01:50 frigate.ptz.autotrack  DEBUG   : garage: New object: 1793430109.247058-1ruxo3 (1740, 300, 1763, 382) 1793430109.844624
2026-10-31 07:01:50 frigate.ptz.autotrack  DEBUG   : garage: Enqueue movement for frame time: 1793430109.844624 pan: 0.825, tilt: 0.3722, zoom: 0
(no "called RelativeMove" follows)

Relevant go2rtc log output

Not relevant, ffmpeg reads this camera's stream directly over RTSP.

Operating system

Other Linux

Install method

Docker Compose

Network connection

Wireless

Camera make and model

ATOM Cam Swing running atomcam_tools custom firmware (ONVIF via onvif_simple_server). The bug is in Frigate's error handling, so any ONVIF PTZ camera should show it.

Screenshots of the Frigate UI's System metrics pages

Any other information that may be helpful

No response

[inkeep-ai-assistant[bot]]

I can't confirm the internal behavior you describe. The material I have covers autotracking configuration and usage, not the implementation of _move_relative, _process_move_queue, _enqueue_move, or _move_to_preset, so I can't quote that code or verify the exception-handling path you traced.

A few things I can speak to that relate to your setup:

• Frigate uses the ONVIF MoveStatus parameter to determine when the PTZ motor is moving or idle, and cameras that don't update this value correctly cause autotracking to misbehave.(1) Your log shows Camera garage does not support the ONVIF GetStatus method, which is relevant context for this camera.
• A full-frame zone in required_zones is not recommended, especially when movement_weights are defined in the config.(1) Both garage and kitchen use autotrack_all covering the full frame.
• Recalibration is recommended if you change return_preset, change the detect fps, or enable zooming after calibrating with it disabled.(1)
• Autotracking can be enabled or disabled via the configuration or by MQTT.(1)

For the code-level report itself, the right place is the Frigate repository: GitHub. Related community threads on ONVIF movement handling: Auto-Tracking using absolute movement, Universal ONVIF PTZ Tracking Question.

If you'd like, I can give a general answer about how a stalled async consumer task typically presents, without tying it to specific Frigate internals.

📚 Sources:

1. Camera Autotracking

---

Have another question? Just tag @inkeep.

[specializedken]

Thanks, but I've checked Issues / PRs / Discussions and this problem isn't covered. Your 3 comments are not directly relevant to that problem; only the first one would apply had the timeling been right : the problem had already occurred when that log line was written (it's a consequence of the camera rebooting).

[hawkeye217]

We can add a simple try/except so a failed move doesn't stop a relative move call until a restart, but the camera crashing mid-move isn't something we can fix on our side. That's most likely a firmware issue or something else with the camera itself, so you'll want to look into why it's rebooting.

[specializedken]

Actually the camera isn't crashing, it's on WiFi and drops off the connection mid-move, causing this issue.

[hawkeye217]

This is improved in #24835

[specializedken]

Thanks