A pre-release for field validation. HACS offers this only to users who have enabled beta versions for this repository; it is not a public release and the changes below still ship in the next monthly bundle as 3.43.0.
Cut so @andymcmanus can validate the Ring event-recording path from #491 on battery Ring cameras with Ring Protect, which no maintainer has. Supersedes v3.43.0-beta.2, whose first field run showed the download refusing Ring's redirect and falling back to snapshots on every event.
What changed since beta.2 (#674)
Ring's signed recordingUrl is a transcoding endpoint that answers 302 with a Location on a node-specific subdomain of the same host. beta.2 refused every redirect. The downloader now follows redirects by hand, each hop held to the same rule as the signed URL: https only, same host or a subdomain of the redirecting host, a public-resolution check on the target before fetching, at most three hops. Off-host, plaintext, or missing-Location redirects remain final errors.
What to validate
Turn on Analyze Ring event recordings in the integration's Global Options (gear icon on the integration page). With custom_components.home_generative_agent.core.video_analyzer: debug logging, each Ring event on a camera whose select.<name>_event_select carries a recordingUrl should produce one line [camera.x] Event <id> recording: N bytes, M frames extracted, K kept, and the resulting notification should describe the event rather than the scene from the retained interval snapshot. The hourly metrics line gains recording_frames, recording_failures and replaced_by_recording; replaced_by_recording ≥ 1 per event on a battery camera is the sign the stale frame was displaced.
The feature (#673, #491)
Battery Ring cameras refresh their interval snapshot at best every 600 s, so a capture window opened on an eventId change could not show the event: the newest frame could be ten minutes older than it. With Ring Protect, ring-mqtt publishes a signed recordingUrl for the event's MP4 on the same entity, present the instant the eventId changes and fetchable about a second later (field data on #491). When the new option is on, the video analyzer downloads that clip, extracts one frame per second with ffmpeg, keeps up to 8 spread across the clip, and analyzes those in place of the snapshots the window captured before the clip landed. Cameras without a recordingUrl keep the snapshot behavior. Needs the ffmpeg binary the official Home Assistant image ships; without it the analyzer logs one warning and keeps using snapshots. Not-yet-fetchable recordings are retried for about 15 s; failures warn at most hourly per camera and the snapshot window stands in. The URL and event id arrive over MQTT and are not trusted: https-only, public hostnames only, redirects followed only to a subdomain of the same host, a 64 MB download cap, a three-minute decode cap, and no attribute ever names a path. Details in Ring cameras via ring-mqtt.
Everything else already on main since v3.42.0 is included. See CHANGELOG.md under Unreleased.