Shorter first recording after sleep

[aaronjh]

I've recently installed an Arlo system to protect the front entry of my house (one camera outdoors, two inside the entry).

I'm seeing excessive delays in recording after motion, which have been raised in the "Outside Recording Delay" thread. I've followed advice there, but even with ideal placement, there are still significant delays on motion after sleep.

After some more time with the system, I've noticed a separate issue that really seems to be the root cause of the issue...

After the cameras have been asleep for a while, I always lose the first four seconds of each recording. Subsequent recordings are fine. But the first one is shorter. This occurs on all three cameras I have installed.

If I set the cameras to 10s recordings, the first recording after sleep is always 6s. If I set it to 20s, the first recording is always 16s.

This suggests some sort of delay in establishing the streaming which causes the system to lose the first few seconds of video. If I wasn't missing these four seconds, I don't think I would have a problem with the delay.

Any suggestions?

[jguerdat]

That's weird. Just offhand, all I can come up with is possibly a router issue, maybe a delay in DNS lookups? What DNS servers are in use by the router or your devices?

[aaronjh]

It would be using my router's DNS settings, which are set to my ISP's nameservers. They are generally flawless.

I could switch to Google DNS for a bit, but I can't imagine that would do anything but degrade performance.

However, even though I'm on a fast fibre connection (100 Mbit downstream, 40 Mbit upstream), I'm in Australia. Even with the fastest possible connection, latency to the US and Europe is painful at times. Latency to the US is rarely much less than 200ms, and to Europe, 400ms is the norm.

Looking at the videos, it seems that they are hosted on an AWS server in the AP region, with sub-10ms latency. However, if authentication or some other services/lookups are going to a server in the US or Europe, then that could very easily explain the delays.

Regardless, I'd hope the videos are buffered locally, and the system isn't waiting for a cloud server to respond before it starts recording.

[aaronjh]

I changed DNS settings on my router to Google DNS, reset the Arlo base station, then waited a while before testing again.

This time, I got a 18 second recording rather than a 16 second one (recordings are set to be 20 seconds).

So it may have made a marginal difference, or it could be coincidence.

If the difference is related to the change in DNS servers, then perhaps network latency is the culprit. This simply shouldn't happen. Latency on the internet shouldn't cause recording to be delayed by multiple seconds. The system should buffer video, so it records immediately on wake-up, rather than delaying it until it has negotiated with a cloud server.

Either way, I'd really like to know the technical reason for these shorter recordings after sleep. They seem to be the real reason I'm seeing excessive delays between motion detection and recording.

[jguerdat]

I agree - latency is a major part of the issue.  However, the system doesn't buffer, it just streams.  The closest you can get with Arlo is with the Q which still streams but gives you a few seconds of video prior to the motion detection since it's constantly streaming.

[aaronjh]

---

jguerdat wrote:

I agree - latency is a major part of the issue.  However, the system doesn't buffer, it just streams.  The closest you can get with Arlo is with the Q which still streams but gives you a few seconds of video prior to the motion detection since it's constantly streaming.

---

I'm not asking for constant video, just for the video to be buffered in memory on the base station between when the camera device wakes up and when the cloud connection is established. This is an absolute necessity to avoid delays due to internet latency.

If the device has insufficient memory, then local or attached storage could serve as buffer space.

I work as a software engineer on wireless video systems in the industrial space. Temporary buffering at the data concetrator is not rocket science, and is standard practice. A system can't rely on direct streaming to the cloud without any form of intermediate buffering. That is madness, and makes the system extremely susceptible to data loss resulting from latency spikes.

[jguerdat]

All we can say is that it's not gonna happen in the current product.  Unless someone wants to open the base to see how much memory is installed, it's not even known if buffering can occur.  It's a moot point given that buffering was not at least an initial design spec.

[aaronjh]

I just want a product that works.

After changing to Google DNS, I'm now regularly losing eight seconds on the first recording. It's become very unpredictable in terms of timing, so I'll change back to my ISP's DNS servers. At least there, I was consistently only losing four or five seconds on the first recording.

After installing a traffic monitor, it seems that the base station is exchanging traffic with an AWS instance in the US when it first receives a recording. Therefore, it seems there isn't much I can do from my end, given that I'm going to inevitably see high latency when this occurs, due to the fact that the traffic is traversing half the globe.

It seems that when the base station has not received any camera events for a while, it goes into some form of sleep state itself, where it needs to reinitialise a connection back to the cloud server before it can stream.

In software, without buffering, a solution would be to minimise the number of round trips between the base station and the cloud server when this occurs, to expedite this connection process. Alternatively, having all services hosted locally on an APAC AWS instance, and ensuring that Australian users connect exclusively to this instance, could certainly help reduce this latency.

In the meantime, I'm going to experiment with some scraper scripts, to see if I can trick the base station into staying connected to the server. If I can make sure the base station is always connected and ready to go, then maybe I'll be able to occasionally get recordings where the subject is still in the frame by the time the AWS instance starts receiving streaming data.