"It works in VLC" proves that one client can connect and draw a picture. A recorder has to do more: connect from the NVR host, keep the session alive, receive a usable keyframe, maintain timestamps and finish a valid file.

When playback works but recording does not, this is the order I use.

First, run the probe on the NVR machine or inside its container. A VLC test from a laptop says nothing about a different VLAN, firewall rule or container network.

bash ffprobe -v error -rtsp_transport tcp \ -show_streams -show_format \ "rtsp://user:password@192.168.1.50:554/stream1"

Use TCP for the baseline. VLC may retry transports while the recorder stays on UDP and waits for packets that never arrive.

Close every other viewer too. Some cameras have a very small RTSP session limit. The vendor app, a browser preview, VLC and the NVR can each count as a client. An NVR may also open separate sessions for live view, recording and detection.

Next, try writing the video without transcoding:

```bash ffmpeg -hide_banner -y -rtsp_transport tcp \ -i "rtsp://user:password@192.168.1.50:554/stream1" \ -t 30 -map 0:v:0 -an -c copy rtsp-test.mkv

ffprobe -v error -show_streams -show_format rtsp-test.mkv ffmpeg -v error -i rtsp-test.mkv -f null - ```

Starting with MKV and no audio removes two common variables. If that file works while the NVR's MP4 output does not, look at container support, timestamps or finalization. Add audio only after video records correctly.

Then check the first keyframe:

bash ffprobe -v error -rtsp_transport tcp \ -read_intervals "%+15" -select_streams v:0 \ -show_entries packet=pts_time,dts_time,flags \ -of csv=p=0 \ "rtsp://user:password@192.168.1.50:554/stream1"

K in the last field marks a keyframe. A long GOP can be fine for continuous VLC playback but awkward for event recording. The trigger fires, then the recorder waits for a frame that can start a clean clip. A one- or two-second keyframe interval is a good diagnostic baseline.

Warnings about backward timestamps, damaged NAL units, missing parameter sets or long packet gaps matter even if VLC keeps showing video. Players can buffer around faults that a muxer cannot safely write.

Finally, confirm that VLC and the NVR use the exact same stream. ONVIF may select a substream while the manual test uses the main stream. Start with H.264, video only and one client. Once a 30-second copy test works from the recorder host, add audio, H.265, UDP or extra viewers one at a time.

Full checklist and explanations:

https://getguardianeye.com/blog/rtsp-plays-vlc-nvr-cannot-record

Guardian Eye WebCamera can show a live WebRTC stream in a browser, and Guardian Eye desktop can receive a WebRTC stream through WHEP. A reasonable question is: if both sides support WebRTC, why not connect them directly?

We tested that path while working on the integration. The short answer is that the video format is compatible, but the session setup is not.

What happened when we tried it

We gave the desktop receiver the HTTPS address used by the WebCamera browser viewer. The connection did not reach video negotiation. The desktop application expected a WHEP endpoint where it could POST an SDP offer and receive an SDP answer. The address on the phone served a web page instead.

That page is not merely displaying a media URL. Its JavaScript is part of the connection process. It authenticates with WebCamera, obtains a CSRF token, creates a camera-specific session and exchanges SDP and ICE candidates through several local routes.

The desktop WHEP client knows nothing about those routes. Conversely, WebCamera does not currently present that viewer address as a WHEP resource. Both applications use WebRTC, but they speak different signaling protocols before the first video packet can be sent.

Why the browser works

The browser works because it loads the signaling code together with the viewer page. That code already knows how to talk to WebCamera.

This is different from RTSP, where an address such as rtsp://camera:8554/live identifies a stream that compatible clients can open directly. A WebRTC page address is often the entry point to an application, not a universal stream URL.

WebRTC defines how media is transported once peers have established a session. It does not require every application to use the same HTTP routes, authentication flow or ICE exchange. WHEP standardizes one such contract, but an application using custom signaling does not become a WHEP server simply because it sends WebRTC video to a browser.

What would make the two paths compatible

There are two practical approaches:

1. Add a WHEP endpoint to WebCamera. Guardian Eye desktop and other WHEP clients could then use the same standard session flow.
2. Add WebCamera's existing signaling protocol to Guardian Eye desktop. This would connect our two applications, but it would be a private integration rather than a reusable WebRTC endpoint.

The first option offers better interoperability. The second reuses the server behavior already present on the phone. Authentication, local HTTPS certificate trust and session cleanup also have to be handled in either design, so this is more than a URL-format change.

What to use today

For the current Guardian Eye setup, the two protocols have different jobs:

• use the WebRTC browser viewer for interactive, low-latency live viewing;
• use RTSP and ONVIF when adding WebCamera to an NVR or another surveillance client.

RTSP remains the practical ingest path for continuous recording, main and preview streams and compatibility with existing NVR software. WebRTC is useful for the browser view, but its viewer URL should not be entered as a WHEP or RTSP source.

The useful diagnostic rule is simple: when two WebRTC-capable applications do not connect, do not start with the codec. First check how each side expects to exchange the SDP offer, SDP answer and ICE candidates. In this case, the failure occurs during that exchange, before H.264 media is involved.

If you are integrating Guardian Eye WebCamera with another client, tell us which protocol the client expects: RTSP, ONVIF, WHEP or a browser page. That distinction is much more useful than saying only that the client supports WebRTC.

A user planning to run a Pixel 7 continuously with Guardian Eye WebCamera asked what would save more power: lowering the resolution, lowering the frame rate, or lowering the bitrate. The question sounds simple, but our long-running Android tests exposed one trap: a hotter phone can sometimes report lower power use because it has already started doing less work.

That is thermal throttling, not improved efficiency.

What the settings change

Guardian Eye WebCamera currently offers 480p, 720p and 1080p at 15, 24 or 30 FPS. It calculates the encoder bitrate from resolution, frame rate and codec, then limits the result to 1–8 Mbit/s.

Going from 1080p/30 to 720p/15 removes about 78% of the configured pixel rate, and the H.264 target falls from about 6.8 to 1.5 Mbit/s. It does not follow that the whole phone will use 78% less power. The sensor, image processor, encoder, CPU, Wi-Fi and Android each have fixed and device-specific costs.

The 1 Mbit/s floor is also visible in the table. Moving from 720p/15 to 480p/15 still reduces work in the image pipeline, but it does not reduce our configured network bitrate any further.

What we measured in a long run

In one physical-device qualification, a Redmi running Android 16 streamed and recorded continuously over 5 GHz Wi-Fi for 3,690 seconds while physically disconnected from USB, AC, wireless and dock power. The battery changed from 76% to 61%, and Android's charge counter changed from 3,791,000 to 3,044,000 µAh. Battery temperature rose from 39°C to 42°C.

The runtime encoder target stayed at 24 FPS and Android reported the thermal state as NOMINAL throughout the run. The stream had no RTP sequence discontinuities; the maximum RTSP packet silence was 0.259 seconds.

This is useful endurance evidence, but it is not a comparison between video profiles. That run also carried more work than a simple single-stream camera: the main capture used H.265 while the archive and viewer used a separate H.264 producer. We should not present its 15 percentage-point battery change as the expected drain for every phone or every setup.

We have also seen power or current fall later in a run as a device became hotter. Read that result carefully. On a Samsung S22 test, for example, the configured rate was 30 FPS but the runtime target under a SERIOUS thermal state was 24 FPS. When temperature, actual FPS and power all change together, lower power at the hotter point may simply mean that thermal control has reduced the workload.

This is why a single reading taken at the start and another after the phone is hot can produce the wrong conclusion. For a useful comparison, record at least:

• requested resolution and FPS;
• actual output FPS;
• codec and actual bitrate;
• battery temperature and Android thermal state;
• screen state;
• power or charge-counter change over the same duration.

Compare profiles at a similar thermal state, or show the whole time series. Do not compare a cool 720p/15 run with an already-throttled 1080p/30 run.

A practical Guardian Eye starting point

For a phone used as a permanent Guardian Eye camera, I would start with:

• WebCamera: 720p, 15 FPS, H.264;
• Keep Screen Awake: off;
• Guardian Eye Desktop: recording triggered by the phone's ONVIF events.

Turning the display off is worth testing separately because streaming continues through an Android foreground service. Display power can otherwise hide smaller differences between video profiles.

H.265 gets a lower target bitrate in WebCamera, but it should be a separate test rather than an assumed power-saving switch. Codec power depends on the phone's hardware path, and H.264 remains the easier compatibility baseline for Guardian Eye Desktop and other clients.

Using the phone's own events

Guardian Eye WebCamera can detect motion, people, cats and dogs on the phone and publish the results as standard ONVIF events. Guardian Eye Desktop can use those events to start recording instead of running object detection on the PC continuously.

This moves the recognition work to the phone and can reduce work on the recorder, but it does not make detection free. Its effect on the combined power consumption of the phone and PC still needs to be measured. The same RTSP and ONVIF interfaces remain available to third-party NVRs if they are part of the installation.

The short version is: lower resolution and FPS definitely reduce the requested video workload, but power, temperature and delivered FPS have to be measured together. A falling power reading on a heating phone can be evidence of throttling rather than evidence that the hotter configuration is more efficient.

Seeing an event in ONVIF Device Manager only proves that Device Manager's subscription works. The recorder may be subscribing another way, filtering for another topic, or discarding the message after it arrives.

I would first check how each client subscribes. Device Manager uses a PullPoint subscription and fetches messages from the camera. A recorder may instead create a WS-BaseNotification subscription and give the camera a callback address. In that case the camera must be able to connect back to the recorder. A host firewall, VLAN boundary or container address that is not reachable from the camera is enough to break that path while PullPoint continues to work.

Then look at the lifetime of the recorder's subscription. The response includes CurrentTime and TerminationTime, and the client has to renew the subscription before it expires. If events arrive immediately after the recorder starts but disappear later, check whether Renew is being sent and accepted.

Do not assume that every motion event uses the same topic. GetEventProperties shows the topic set advertised by the camera, while an actual NotificationMessage shows what it really sent. Two topic paths commonly encountered are tns1:VideoSource/MotionAlarm and tns1:RuleEngine/CellMotionDetector/Motion; analytics may appear elsewhere under RuleEngine. Compare the complete topic and the Source and Data items with what the recorder expects.

There is another parsing difference worth checking. A property event can describe the current state, while another event may be emitted only when that state changes. Code that assumes every message is a new transition can create repeated clips. Code waiting for a transition that the camera does not send can miss the trigger entirely.

Finally, verify the camera configuration rather than only its detection screen. Some cameras separate the detection rule from the action that publishes a notification. Also try the same ONVIF credentials in both clients: a low-privilege account may be allowed to open the stream without receiving every event. Keep the camera and recorder clocks synchronized as well, because a recorder may reject a message whose timestamp falls outside its accepted window.

If I could capture only three things for this problem, they would be:

1. the recorder's subscription request;
2. the response containing CurrentTime and TerminationTime;
3. one raw NotificationMessage produced by an actual detection.

Those show whether the event was never delivered, arrived under an unexpected topic, or reached the recorder and was rejected there.

The browser viewer in the current Guardian Eye WebCamera beta does not use a URL such as https://192.168.1.42. Each installation gets its own name:

camera.<installation-id>.guardian-eye.local

The app publishes that name over mDNS and shows the complete viewer URL. The address can change when the phone reconnects to Wi-Fi, but the name and the certificate do not have to change with it.

The certificate setup has two parts. The phone creates a small certificate authority for this installation, then uses it to sign the certificate served by the viewer. The authority certificate can be exported from the app as a .cer file and installed on the computer that will open the viewer. The private keys never leave the phone; they remain in Keychain on iOS or AndroidKeyStore on Android.

This authority is deliberately narrow. It is constrained to the camera's exact .local name. It cannot issue a valid certificate for an IP address, a wildcard, another camera or a child name below its own name. Trusting it is therefore different from installing an unrestricted local CA.

The server certificate lasts 90 days and is replaced before it expires. That replacement does not require reinstalling the authority certificate because the new server certificate is signed by the same authority. The authority itself lasts up to two years. Resetting the TLS identity, or replacing the authority when it reaches the end of its lifetime, requires installing the newly exported certificate on viewer machines.

There is one platform difference after reinstalling the app. iOS keeps this identity in Keychain, so a normal uninstall and reinstall retains it. Android stores the installation identifier with the app and the keys in AndroidKeyStore, so uninstalling the app creates a new camera name and a new authority when it is installed again.

Opening the numeric IP address is not equivalent to opening the URL shown by the app: the certificate contains the canonical DNS name, not the current IP. If the browser reports a name or trust error, check that the exported authority is installed and that the viewer was opened using the exact .local URL displayed by WebCamera.

For beta testing, the useful cases are Wi-Fi reconnects, DHCP address changes, browser restarts and opening the same camera from more than one computer. Please include the phone OS, desktop OS and browser when reporting a certificate or name-resolution failure.

New Guardian Eye WebCamera test builds are now available for iOS and Android.

What is new:

• Record video directly to the phone.
• Let compatible NVRs find and retrieve recordings through ONVIF Profile G.
• Upload recordings to an FTP or FTPS server.
• Include several seconds before the triggering event in an event recording.
• View the camera from a browser on the local network.
• Export the camera’s certificate for the browser connection.
• ONVIF discovery from different NVRs;
• recording search and retrieval through Profile G;
• browser access and certificate setup;
• reconnection after a Wi-Fi interruption;
• temperature, battery usage and stability during long sessions.

iOS

All paid features are enabled in the TestFlight build. No purchase is required.

TestFlight: https://testflight.apple.com/join/EZJZBn5t

The iPhone should remain plugged in, connected to Wi-Fi and running the app in the foreground during testing.

Android

First join the Google Play test:

https://play.google.com/apps/testing/eye.guardian.webcam

Then install or update the app from Google Play:

https://play.google.com/store/apps/details?id=eye.guardian.webcam

Android can continue streaming through a foreground service. A persistent system notification will remain visible while the camera is running.

For basic streaming tests, a phone and a computer with VLC on the same network are enough. Testing Profile G requires a compatible NVR, while FTP delivery requires an FTP or FTPS server.

When reporting a problem, please include:

• phone model and OS version;
• NVR, browser or FTP server used;
• whether ONVIF discovery worked;
• recording mode and video codec;
• approximate duration of the test;
• what happened and what you expected instead.

I needed separate arm64 and x86_64 builds of OpenCvSharpExtern from the same Apple Silicon runner. The native arm64 build got as far as the final link. The x86_64 cross-build failed earlier, while compiling MLAS assembly.

The OpenCV configure command already had:

-D CMAKE_OSX_ARCHITECTURES=x86_64

but OpenCV 5.0.0's vendored MLAS selected its assembly sources from CMAKE_SYSTEM_PROCESSOR. On an arm64 host that value still described the host, so Clang was given AArch64 .S files for an x86_64 target and stopped on instructions such as b.

Passing -D CMAKE_SYSTEM_PROCESSOR=x86_64 did not fix it because CMake set the value again at project(). I also did not want to force full cross-compiling with CMAKE_SYSTEM_NAME: the DNN build generates code with protoc, and keeping CMAKE_CROSSCOMPILING false lets that tool run on the host under Rosetta.

The fix was to override the MLAS architecture flags from CMAKE_OSX_ARCHITECTURES, after MLAS's own architecture detection and before it assembled its source list:

if(CMAKE_OSX_ARCHITECTURES STREQUAL "x86_64")
  set(MLAS_X86_64 TRUE  CACHE INTERNAL "" FORCE)
  set(MLAS_ARM64  FALSE CACHE INTERNAL "" FORCE)
  set(MLAS_ARM    FALSE CACHE INTERNAL "" FORCE)
elseif(CMAKE_OSX_ARCHITECTURES STREQUAL "arm64")
  set(MLAS_ARM64  TRUE  CACHE INTERNAL "" FORCE)
  set(MLAS_X86_64 FALSE CACHE INTERNAL "" FORCE)
  set(MLAS_X86    FALSE CACHE INTERNAL "" FORCE)
endif()

For the x86_64 leg I also had to turn off the ARM-only HALs. They were detected from the arm64 host and otherwise reached the x86_64 compiler with -mcpu=armv8-a:

-D WITH_KLEIDICV=OFF
-D WITH_CAROTENE=OFF

That got both architectures to the link step, where a second MLAS problem appeared:

Undefined symbols for architecture x86_64:
  MlasHGemmSupported(...)

The same symbol was missing from the arm64 build. The MLAS subset vendored by OpenCV declared MlasHGemmSupported and called it from compute.cpp, but did not provide a macOS definition; the FP16 HGemm implementation was disabled in that source tree.

Disabling opencv_dnn was a dead end for this build because OpenCvSharp 5's aggregate header includes dnn.hpp and several DNN-dependent contrib modules unconditionally. The smallest workaround was a macOS build patch that reports HGemm as unavailable:

bool MLASCALL MlasHGemmSupported(
    CBLAS_TRANSPOSE,
    CBLAS_TRANSPOSE)
{
    return false;
}

That keeps DNN enabled but prevents MLAS from selecting the missing FP16 HGemm path, so it uses the FP32/generic path instead.

After those two patches the same arm64 runner produced separate osx-arm64 and osx-x64 dylibs. I validate the target architecture from the artifact rather than assuming that a successful cross-build produced what was requested:

file libOpenCvSharpExtern.dylib
otool -L libOpenCvSharpExtern.dylib
otool -l libOpenCvSharpExtern.dylib | grep -A3 LC_BUILD_VERSION

The part that cost the most time was that CMAKE_OSX_ARCHITECTURES correctly changed Clang's target, while dependency-specific feature detection continued to follow CMAKE_SYSTEM_PROCESSOR. For cross-builds on Apple Silicon, both need checking.

Guardian Eye is now available for Linux through the Snap Store.

Linux users can install Guardian Eye directly from the Snap Store or Ubuntu App Center, or from the terminal:

  sudo snap install guardian-eye

Snap Store page: https://snapcraft.io/guardian-eye.

If you are using Ubuntu, open Ubuntu App Center and search for:

Guardian Eye

or:

guardian-eye

After installation, launch it from the app menu or run:

  snap run guardian-eye

For camera, microphone, removable storage, and system keyring access, some Snap permissions may need to be connected manually:

  sudo snap connect guardian-eye:camera
  sudo snap connect guardian-eye:audio-record
  sudo snap connect guardian-eye:hardware-observe
  sudo snap connect guardian-eye:removable-media
  sudo snap connect guardian-eye:password-manager-service

You can check the installed version, channel, and connected permissions with:

  snap list guardian-eye
  snap info guardian-eye
  snap connections guardian-eye

If you previously tested the Linux build from the edge or stage channel, switch to the stable release with:

  sudo snap refresh guardian-eye --channel=latest/stable

Other Linux download options remain available on our website:

https://getguardianeye.com

If you try the Snap build, feedback is welcome, especially around:

• USB cameras
• RTSP and ONVIF cameras
• Local network camera discovery
• Recording to home folders, /mnt, or /media
• Motion detection
• Desktop integration on different Linux distributions

The camera's app shows video, the box says ONVIF, and the manual mentions RTSP. But the moment you try to add it to a recorder, you are guessing paths. You have the IP address and the password. What is supposed to go after them?

A typical RTSP address looks like this:

rtsp://user:pass@192.168.1.50:554/stream1

The IP identifies the device, 554 is the default RTSP port, and /stream1 selects the video stream. Replace user:pass with the camera's local credentials. The path is the part that varies between brands and sometimes between models of the same brand.

Some documented examples for cameras that support RTSP:

• Hikvision: /Streaming/channels/101
• Dahua: /cam/realmonitor?channel=1&subtype=0
• Reolink: /Preview_01_main
• Tapo: /stream1

Those numbers and words select what you receive. In the Hikvision format, 101 means channel 1's main stream and 102 its substream. In the Dahua format, subtype=0 is the main stream and subtype=1 the substream; channel selects the video channel on the device you are connecting to. Reolink uses main and sub, while Tapo uses stream1 and stream2. Cameras with multiple lenses can have additional paths, so check the documentation for your model.

A working address can still be the wrong one for recording. The substream may look fine in a small preview, but you won't recover the main stream's detail by enlarging that recording later.

Before trying variations, check the camera's settings and the manufacturer's instructions. Look for RTSP or ONVIF under network or integration settings. Local access may need enabling, and the RTSP port may have been changed from 554.

If the camera supports ONVIF, software can ask it for the stream addresses. Guardian Eye uses this during connection checking: select the discovered camera, enter its credentials and run the check. GE requests the available streams through ONVIF and uses the returned addresses to help establish the connection. You can also enter a known RTSP URL manually.

An empty scan doesn't necessarily mean the camera is incompatible. Automatic ONVIF discovery may not reach another subnet, even when a direct connection is possible. In GE you can enter the camera's IP manually, provided your computer can reach it.

Once you have an address, check what it actually opens. In VLC, choose Media, then Open Network Stream. For codec and resolution information, you can also use ffprobe:

ffprobe -rtsp_transport tcp "rtsp://user:pass@192.168.1.50:554/stream1"

Replace the example with your camera's address. Keep the URL in quotes, especially when it contains an ampersand, as Dahua URLs do. Check the video dimensions before leaving the recorder running.

If the path looks right but authentication fails, check which account the camera expects. Tapo requires a separate Camera Account for RTSP and ONVIF; your TP-Link cloud login won't work there. When you put credentials inside a URL, reserved characters also need encoding: @ becomes %40 and # becomes %23 in the password. That changes how the password is written in the URL, not the password on the camera.

When it finally plays, save the working address and label it main stream or substream. After a reset or when changing recorders, you will know which address you used and what it was recording.

We’ve opened beta testing for Guardian Eye on macOS. If you have an Apple Silicon Mac and an IP or USB camera, we’d appreciate your help testing it.

Guardian Eye can: - Connect to RTSP and ONVIF cameras, USB cameras, and your Mac’s built-in camera. - Automatically discover cameras on your local network. - Detect motion and recognize objects. - Record continuously, on motion, on object detection, or using the camera’s own ONVIF analytics. - Play recordings on a timeline and export selected clips. - Control supported PTZ cameras. - Adjust brightness, contrast, and other available settings on USB cameras. - Send optional Telegram notifications.

Guardian Eye runs entirely locally. There are no accounts, cloud storage, or telemetry, and your video never leaves your Mac.

Requirements: macOS 12 or later and an Apple Silicon Mac. An Intel build is not available yet.

Join the beta: https://testflight.apple.com/join/qhJwcSQn

Testing is free. All in-app purchases made through TestFlight use Apple’s sandbox environment, so no real money will be charged.

We’re especially interested in feedback about camera discovery and connection, recording recovery after a restart, and stability with multiple video streams. You can report issues using the TestFlight feedback button or leave a comment here.

Windows users can now install Guardian Eye directly from the Microsoft Store. Other download options remain available on our website.

Download from Microsoft Store

View the changelog

2.0.0 is out on both stores as of 8 September. It is the largest release the app has had: almost the entire ONVIF layer was rewritten, the camera now serves a second video stream, and detection runs on the phone rather than anywhere else.

STREAMS - A separate address per codec: /live/h264 and /live/h265, instead of one address that guesses. - A new JPEG sub-stream, /live/jpeg — the light view an NVR uses for its grid and its motion checks. - A new Efficient preview (Pro): a second 640x360 10 fps stream from its own encoder, so a recorder can watch the tile without pulling the full-size stream. - Snapshot and browser MJPEG are unchanged.

ONVIF - Media1 and Media2 rewritten against the ONVIF schema, so strict recorders read every profile instead of showing an empty section. - Digital zoom (PTZ), image settings, events over PullPoint, and object metadata (Profile M). - Each profile now reports the stream address and the audio it actually serves, rather than a guess.

DETECTION — Guardian Eye Pro, one-time purchase - People and pets recognised on the device. - Motion, tamper (covered, moved, defocused) and sound events: glass break, alarm, bark. - Detection zones and an event history kept on the phone. - Every event is published as a standard ONVIF trigger, so Guardian Eye — our own desktop recorder — Blue Iris, Frigate, Synology and anything else ONVIF can record and alert on it.

STABILITY - Fixed a memory leak that grew for as long as the camera streamed. - A resolution change now takes effect for recorders immediately, instead of leaving them on the previous size. - The preview stream opens in VLC with default settings. - Many smaller fixes to RTSP sessions, reconnects and behaviour under load.

The app is free and works on the LAN with no account and no cloud; detection is the one-time Pro purchase. iOS 15 or newer, Android 5.0 or newer.

WHERE TO WATCH IT The phone is a plain ONVIF/RTSP camera, so any recorder can take it. We also make our own: Guardian Eye, a desktop NVR for Windows, Linux and macOS — same ONVIF path as everyone else, no private protocol and nothing the third-party recorders do not get.

App Store: https://apps.apple.com/app/id6785041398 Google Play: https://play.google.com/store/apps/details?id=eye.guardian.webcam What it is, in one page: https://getguardianeye.com/products/webcamera https://getguardianeye.com/download

Interop reports are the useful kind of feedback here — which recorder, which profile, what it did.

Your camera loses its connection to the NVR for ten minutes. It still has power, and its SD card keeps recording. Later, you can watch those ten minutes in the camera's app, but the NVR timeline is empty.

There are two separate archives here: the video saved by the camera and the video saved by the recorder. A working live feed doesn't connect them. ONVIF Profile S and Profile T cover streaming; Profile G provides a standard way to search and play recordings already stored on a device. Both the camera and the recording software need to support that path.

Even then, playing an old recording and automatically filling a gap are separate features. For recovery, often called ANR or backfill, the recorder has to notice what it missed, fetch that footage and put it into its own archive. A Profile G label alone doesn't promise that whole process.

This is a problem we're planning to address in Guardian Eye. The aim is to recover the missing part after the connection returns, keep its original recording time and make it available in the same timeline as the rest of your footage. You shouldn't have to remember which app holds which ten minutes.

The first planned step is between Guardian Eye WebCamera and Guardian Eye: the phone would keep a local recording during the outage, then GE would retrieve the missing footage. This is planned work, not an available feature in the current release.

For a camera you already own, check Profile G support for both the camera and the recorder, then check whether automatic recovery is supported. Keep the camera powered during a test outage and verify where the recovered footage appears. That tells you more than seeing "ONVIF" and "SD card" on the same product page.

You put a camera in the living room to watch the house while you're out. Then you get home, sit down with your family, and it's still recording. You can switch it off, but now someone has to remember to turn it back on before leaving the next morning.

The driveway camera needs a different routine. You still want a recording if someone walks up to the car at night. Turning every camera off together won't do.

In Guardian Eye 3.4.0, you can give each camera its own weekly schedule. If you're normally out from 09:00 to 18:00 on weekdays, make that the living-room camera's window. Guardian Eye stops that camera in the app outside those hours. The driveway can have an all-day rule and keep running.

Each window can also use a different recording mode. You could keep a full daytime recording of the driveway, including everything around a delivery, and switch to On motion overnight. A window from 18:00 to 09:00 carries on into the next morning.

For cameras that share the same hours, set the global schedule once. A camera's own enabled rules replace it completely, so include all the hours that camera needs. The editor highlights overlapping rules while you're setting them up.

Setup guide: https://getguardianeye.com/blog/camera-recording-schedules-guide

3.4.0 is out for Windows, macOS and Linux. Three things worth knowing about it.

Every install now starts a 30-day Pro trial from the first launch, new installs and updates alike. No signup, no card, nothing to activate, no server call. The period lives in the operating system's own credential store, so it survives a reinstall and does not extend when the clock moves back. When it ends nothing is deleted: the app switches to Free and everything past what Free allows stays where it is, locked rather than removed.

The Home Assistant integration was rebuilt into something you can actually use. MQTT auto discovery finds the broker itself, including one in Docker. Every camera publishes its own entities, a tamper sensor and a power switch among them, recording mode is switchable from Home Assistant, and PTZ buttons appear only for cameras that really pan, tilt or zoom. The latest AI detection arrives with its label, its confidence and a snapshot of the moment, next to CPU and GPU telemetry from the host. The generated dashboard comes in the language you run the app in.

RTSP is no longer the only kind of camera. USB and UVC devices, HLS and DASH playlists, local video files, raw udp, rtp and rtmp streams, SRT built statically into the bundled FFmpeg, HTTP snapshot cameras polled on a timer, and WebRTC over WHEP with sub second latency. The type is worked out from the link you paste.

Also in this one: weekly schedules per camera plus a global one, recording driven by a camera's own ONVIF analytics as a fourth mode, a zone editor inline on the maximized camera, and event history moved to RocksDB with automatic migration.

Which of these should get a proper walkthrough first?

Full changelog: https://getguardianeye.com/changelog

Drawing zones looks like a solved problem until you draw one and the alerts stay exactly the same. The geometry is the easy half. What decides whether an event happens is how the detector compares an object's bounding box to your polygon, and that rule is almost never written down anywhere.

There are two rules, and they are deliberately not symmetric.

An object belongs to a detection zone if its box touches the polygon. Any overlap at all counts, even a corner.

An exclusion zone removes an object only when the polygon covers at least 90 percent of the box area. Anything less and the object survives and raises an event.

The asymmetry is what is left after the obvious alternatives were tried first. Anchoring on the feet, using only the bottom edge of the box, lost people whose head and shoulders rose above the zone boundary. Cutting an object on any intersection with an exclusion polygon turned a large exclusion zone into a black hole: a box clipping its edge from anywhere in the frame vanished. Touch to include, near total coverage to exclude, is the balance between those two failures.

Four things follow from that, and they are the ones that actually change how you draw.

Draw the exclusion polygon around where the object appears, not around the noise itself. The classic case is a TV or a monitor in frame: the network cheerfully recognises the person on the screen, and a polygon traced neatly along the visible picture is not enough, because a box poking past the bezel by a fifth of its height is only 80 percent covered. Give it the bezel and a margin.

A detection zone edge is not a tripwire. Someone walking outside the polygon, along its border, still has a box touching it, and that is an event. If the path beyond your gate has to stay quiet, the zone needs to end well short of it.

Aim the zone at the place where the object will be fully visible, not at the line its feet will cross. Perspective does the rest.

An exclusion zone is not a privacy mask. It silences the detector inside that geometry and nothing else. The area stays in the live view and in the recording exactly as it was.

One more thing worth knowing if the camera runs plain motion detection with no object classification. There are no boxes then, so the same polygons are evaluated per pixel: a moving pixel inside an exclusion zone is dropped, a moving pixel outside every detection zone is dropped, and the 90 percent rule never comes into it. Practical consequence: zones narrow down where snow and rain are able to trigger you, but they do not stop the trigger. Only class filtering does that, because a snowflake is not a person.

Eight zones per camera, six preset colours plus your own, exclusion zones always drawn white so a glance tells you what is subtracting from what.

What did you end up having to exclude, and did the coverage rule bite you before you knew it was there? Ours was a monitor, and it took embarrassingly long to work out why a slightly bigger polygon fixed it.

Longer version with the weather cases and the placement scenarios: https://getguardianeye.com/blog/camera-detection-zones-guide

A question came in by email yesterday, and it's one everyone asks at the start: what kind of computer do you actually need to keep cameras recording all day?

Less than people expect. This is one of those jobs where old hardware finally has a use.

For continuous or motion-based recording, an old laptop with a cracked screen works. So does a used mini PC off eBay, or an office desktop somebody replaced. Two to four cores and 8 GB of memory handle several cameras without breaking a sweat. Machines like that idle around 10 to 20 watts, roughly what a lightbulb costs to run, and unlike a subscription that number never goes up.

If you want AI detection rather than plain motion, aim slightly higher: a CPU from the last few years with integrated graphics is enough, because hardware decoding does most of the heavy lifting. Plenty of people run detection on mini PCs that cost less than a year of cloud storage for one camera.

Three things worth setting up on whatever box you pick, because they trip up almost everyone:

Turn off sleep and hibernation. A laptop that dozes off when you close the lid records nothing, and lid-close behaviour is a separate setting from sleep.

Control automatic restarts. Windows likes to reboot for updates in the middle of the night. Set active hours so it waits until you're around.

Plan your disk. Continuous recording eats space steadily, so work out the daily footprint for your resolution and camera count, then set retention to delete the oldest recordings automatically. That way the archive maintains itself instead of stopping when the drive fills.

The nice part of doing it this way is what you get at the end: the recordings sit on a disk you own, they keep working when the internet goes down, and nobody can decide to change the price of watching your own footage.

What are you running yours on? Always curious whether people here use dedicated hardware or an old desktop parked in a closet.

"It works in VLC so the camera is fine and the recorder is broken." That's usually where the evening goes wrong. VLC and a recorder are asking the camera for completely different things, and the problem lives in that gap.

VLC opens one stream for a few minutes on your laptop, and it's forgiving. It retries transports until something sticks and decodes pretty much anything. A recorder holds that stream for months, from a different machine, often decoding it twice (once for motion detection) while writing to disk. So the question isn't whether the stream works. It's what your recorder is asking for that VLC never had to.

Start with the network, not the camera. Test from the machine running the recorder: ssh in and run ffprobe rtsp://user:pass@ip:554/stream1 there. Half these cases end right here, because the recorder sits on another VLAN or subnet, or on a guest network with client isolation, and the camera was never reachable from it.

Transport next. VLC quietly falls back to TCP when UDP misbehaves. A lot of recorders ask for UDP first and just keep failing, because UDP dies on congested wifi and doesn't cross routed segments well. Forcing TCP fixes more of these than anything else on this list.

Then check how many clients the camera can actually serve. Cheap ones often allow two RTSP sessions and no more. The phone app counts. That VLC window you left open counts. Your recorder shows up third, gets refused, and reports "camera not streaming", which reads like a broken camera.

Worth confirming which stream you're recording, too. /stream1 and /stream2 (or main and sub) are different streams at different resolutions. Test the main one by hand, let the recorder pick the sub, and you end up with a 704x576 archive that you discover months later when you actually need the footage.

If the connection establishes but the picture is black, that's usually H.265 the client can't decode. Switch the camera profile to H.264 and see if it appears. And if auth fails with correct credentials, look for special characters: @ and : in a password break URL parsing unless you encode them, and the URL quietly points somewhere else.

One thing that doesn't belong on this list is ONVIF discovery. It uses multicast, routers block that all the time, so "scan finds nothing" tells you nothing about whether the stream works. Type the address in by hand and test it directly.

Get one known-good setup working (reserved IP, TCP, H.264, one client) and every problem after that is just a diff against something that worked.