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.
Thanks
[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.
@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.
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.
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.
@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
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.
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,
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!
Awesome!