User adjustable time/length for pre-roll (pre-event) and post-roll (post-event) buffers

What this is about:
I’m not sure, but event recordings seem to capture about one second of video immediately prior to the triggering event.

I would be willing to pay for a model with several seconds of buffering, so that I could see more of what led up to the triggering event. And I would be willing to keep the total event recording time remain 12 seconds, trading post-trigger footage for pre-trigger footage. I appreciate that this is not trivial and that a continuous cloud storage option would largely obsolete this ask.

What this is not about:
This ask is not about increasing the total time of event recording. That’s a valid related but separate topic.


[Mod Edit]: Title modified to be more inclusive and to enhance search clarity.

I think that is what the SD card option is for. The 12 second event video, is just to let you peek and see if you want to review the Playback or not. With the SD card you can record continuously or in 1 minute increments when there is movement.

1 Like

@OverWatch. That’s true. But I’d like to be able to review events quickly, without wading through playback. It just seems natural (to me) to want to see a couple more seconds before the event. When I view an event, in almost every case, the trigger was too late. And, yeah, I have the sensitivity cranked up.


Yes, I keep my sensitivity all the way up as well except for one camera. I tend to get 1-2 seconds before the first motion. Of course that varies and I have had some cases where the movement was six seconds prior to the start of the Event clip. iirc, rebooting the camera helped. I also recommend reformatting the SD card, possibly in another device. That seems to solve a lot of mysterious issues. There seems to be something with full memory cards, but that’s just my wild theory.

You might want to vote on this too.


Thanks the the suggestion. I’ll try that!

1 Like

After typing that, I just received an Event video that started 14 seconds after the movement on one of my cameras. The card is full, so if it happens again, I’ll be reformatting that card.

@OverWatch what kind of card are you using? I had mentioned somewhere else in the forums that certain types of cards (such as low cost sandisk) are not good cards for things that continuously re-write information ( our cameras, dashcameras, etc…) I’m curious as to what you are using, maybe this is a wider problem and if it is, this could be noted by wyze for newer users. maybe Ill make a separate post to see what the user base is utilizing and see where issues are being seen.

1 Like

That particular card is a Samsung EVO Select Class 10 UHS 3 64GB, the Sandisk Ultra class 10 UHS 1 32GB is working fine. I have had one other Samsung EVO Class 10 UHS 1 32GB that had to be reformatted. If the problems are only happening with full cards, I’m not sure if it’s a brand problem or a management problem. Tracking may help narrow it down, but beware of witch trials. Correlation, causation and all that stuff. :slight_smile:

@OverWatch I’m using Samsung pro endurance cards and I haven’t had that issue at all, even with full cards. so far that other post is going pretty smooth…no mobs yet :slight_smile:


What if instead of changing the pre-buffer in the cloud, the local recording would automatically create a longer clip of your choosing?


  • Continuous recording to SD card always recording
  • Event occurs
  • Upload 12 sec cloud clip
  • Generate local clip (X sec pre event, X sec post event) (length is user configurable)
  • Provide link to event time in continuous timeline (to watch whatever you want)

That’s an interesting option! For all the people that are worried about their cameras being stolen they would have a record on their phones.

1 Like

No mobs burning Sandisk cards? Smashing them with hammers on national tv? Throwing them in running blenders? :joy: Awesome!

1 Like


In speaking to the original question about prerecording, the buffer is written to the sd card so on event the logic would be quite different. They would need to read from the card and transmit that data. The question for dev is do you just move your logic to reading from the card? Answer is no as that opens many avenues for failure as well as significant increases in viewing latency.

Sd cards

As to the statement regarding sd cards. SD cards are inherently slow and not high quality flash. What we need from dev is information on the number of write errors occurring. That tells us about bad blocks so we can initiate a reformat to have bad blocks identified and eliminated from writing. The hardware block size is important. An if you write a partial block, at the driver level the data is copied from the card, then erased and finally your changes written. Data should be written as N blocks for fastest performance. I forget the kernel param that controls buffering for you.

Security, my passion

Now on security, I have an excellent history and would be happy to have an offline conversation about the total end-to-end stream from camera to cloud and cloud to device to point out areas that I would attack. For internet connected cams we’d need to look at thr XBurst to see if they have addressed side channel attacks. I haven’t noticed any *nix patches specifically for this chip. Since I’m a user of these cams I’d happily work directly with devs for free instead of my $325/hr rate.

Thank you guys for individually salting the passwords.

Email me directly if interested.


Arlo has a feature that allow their cameras to record 3 seconds prior to an event, it would be nice to be able to see what happened 3 seconds before an event happen. Maybe even add the ability to set how long before an event you want wyze to record if possible,

1 Like

My experience that Arlo is not great. I prefer Wyze over the expensive Arlo system.

I’m sure it wouldnt be hard for them to program. I just reference back on the SD card from the motion event for right now.

Could someone change the title?
Isn’t the discussion on PRE-EVENT recording not PER-EVENT?

I skipped this dozens of times because I don’t have any interest in a longer PER-event buffer, but a longer PRE-event buffer would be handy.


Good catch. I changed it.


My particular scenario includes IFTTT action being originated from a PC event log. If the event is logged, then start a recording. However, the latency between the event log entry and the action (Record a short clip) is unknown. Therefore I need a pre-event recording.

What is know, is the exact time the event occured as extracted from the PC event log.

If this feature is being considered, please allow to record at a fixed UTC time?

If the motion is too fast, I won’t see any motion recorded. Especially lightning strikes.
I’ll need to use the playback manually to see the motion.
Adding a buffer will be a great feature!