I am not sure it’s the same issue as yours, but I have 2 cameras with 256Gb cards and a third one with a 128 Gb card (all running the Beta software) and all three are dropping a few frames once every minute, for about half a second each time.
It always occur at the same time every one minute interval, and the clock at the bottom right skips one second, and jumps from :42 to :44 on a given camera, or moves very quickly from :47 to :48 on another camera
When a person walking by is appearing on the recording during that time, I can see there are missing frames as that person “jumps” ahead quickly.
It occurs on all three cameras but each camera is doing it at a different time during the minute
I tested that back when it was first reported on the Beta thread and could not reproduce the anomaly. I just tested it again and couldn’t reproduce it.
I have smooth playback through every minute rollover (with one exception… See last paragraph).
Since the point at which you experience that anomaly is the exact time when the in app player is stitching together two adjacent one minute video files from within the same date folder on the card, it would lead me to believe that you are experiencing some sort of buffering delay in the player getting the next file. Possible causes: slow read capability on the digital card reader in the cam, slow read access speed on the SD card itself, slow P2P WiFi transfer speed to your device (distance, intereference, congestion, router QOS throttling), slow processing capability on the player device.
Troubleshooting I would do to isolate the cause would be to test it on multiple cams running the ẞFW with multiple variables: (1) at their current location and moved very close to the router; (2) testing them each individually at each location with no other devices on the 2.4GHz network and with full network load; (3) test with current SD card and a new UHS3 V30 HE uSD; (4) test on multiple viewer devices.
EDIT:
Additionally, with the timeline in it’s default scale, it advances to the left at the top of each minute. Another test I would do is to expand the timeline to it’s limit so that you can see it advancing with every second and see if it reproduces the affect, ruling out an app player issue. I would also be sure to be running the latest app PR. I would also pull the card and read it on a player\scrubber to see if it is something embedded in the recorded file metadata or if it is occuring as a result of the read\transmit\play process. If it occurs there, I would test the same on a new UHS3 V30 HE uSD for comparison.
Exception from above : A glitch has been reported by @SirDom and confirmed by @carverofchoice that causes the playback to skip over the first minute of each hour when the player is stitching together the last one minute video file from that hour into the first video file of the next hour in the next indexed folder. The video file for that minute is still there and can be played, it just gets skipped by the in app player. This doesn’t happen when playing from the last minute if a day to the first minute of the next.
@SlabSlayer
I have the Wyze app installed on 2 devices (Android phone and iPad) and the issue occurs at the exact same time, every minute, on both players.
I am also ruling out a WiFi latency problem since the lost frames can be played back many times and always occuring at the same place in the recorded stream…WiFi latency issues would cause jittering and lost frames randomly throughout the stream playback.
The microSD cards I am using are decent quality Sandisk Ultra UHS-I A1 @ 120 Mbps, and are not dropping any frames other than at the one minute interval when playing back the stream. However it could still be causing the issue when writing to the card when it starts a new one minute video file.
Unfortunately I don’t have another microSD card of better quality that I can use to test…
I think that a delay occuring when two adjacent one minute files are stitched together is an interesting avenue to explore, so I will pull out the microSD card out of a camera and play back the videos on a computer to see if there are any lost frames.
Also, I couldn’t figure out how to change the scale of the playback timeline; if you can tell me how to do this, I will try and see if the issue with lost frames is still there
In landscape orientation on the playback window, touch the screen to bring up the timebar, playback controls etc. using 2 fingers on the time bar spread your fingers to decrease the time interval or squeeze to increase it. As you do this you will see 2 arrows on the time bar indicating the action.
Great info! This rules out the device as a contributor. Although if both devices are running the same PR or Beta build iteration, both may have app player issues although I would tend to think it would be highly unlikely.
Agreed. Since it has a definable occurance pattern, it would suggest that it isn’t a data transmission buffering issue as those would appear in a more random pattern.
Agreed. This is happening for you when the card is reading from one file to the next. One thing I thought of just now from your post, and one that @Slammer99uk might test to confirm as well: my 256GB card has been formatted by the cam. I believe this is a FAT32 format (if someone can confirm that). The cards are sold pre-formatted with EXFAT. I have a new card here I am going to insert out of the box and start testing on another Cam using the EXFAT to see if that may be the issue.
Pinch the timeline smaller for large scale, stretch w\ two fingers to widen to small scale
@SlabSlayer I have tried testing everything from the list you provided, including using a range extender right next to the bedroom window cam. which shouldn’t be needed as the router is less than 6 feet from the extender. I have checked this on 128 and 256 Gig cards SanDisk HIGH ENDURANCE Video Monitoring for Dashcams & Home Monitoring 256 GB microSDXC Memory Cards in both the important cams I have.
Ok, the really weird thing is this, and please understand I can reproduce this 100% on all 3 cams. The problems of freezing/buffering only occurs on playback that is exactly less than 1 hour old. Anything older than exactly 60 minutes plays back fine with no freeze or buffering.
This is the reason I asked for users to test playback on recordings under 60 minutes old. Again, I state that this is 100% reproducible on my end.
I believe you are reproducing it. I watched the videos you posted. Yes… Weird that it is only on file transitions within the current hour. My theory:
The cam read or app play is having issues with the transition between adjacent video files located only in the currently indexed (newest and active) hour video folder (named on a 24 hour format). Because it is only happening within the currently indexed folder that is still being actively written to and read from simultaniously, it may be a FAT issue for the cam to read and write to the current folder and causes a conflict with two way data transfer.
I tried pinching the timescale but wasn’t paying attention to the time displayed, …I was rather focusing on the white vertical bars that were not moving which made me think it wasn’t changing the time scale.
I’m OK now and after changing the timeline to one minute increments, I can still see the issue occurring at the same place.
Will resume testing later today when I have some time available
Thanks
I just tested the new 255GB EXFAT card in the newly upgraded Beta FW cam which is within its first hour of recording. It transitioned over the X:00 minute mark smoothly. The top of the hour 1 minute skip is still there.
One interesting observation I made is that there is regularly a fluctuation in the data transfer rate that seems to coincide with the seconds time progression of the watermark timer. As each second clicks off, the data rate drops from 87.x KB/s to 47.x KB/s. My other V3 on ẞFW FAT32 remains steady in the 145+ KB/s range BUT… It is located close to a range extender whereas the new EXFAT cam is using the extender from a greater distance with significant barriers.
Would be interested to see what the data rate does when this anomaly presents.
Hi all, any updates on this beta going into production soon? I have several cameras impacted by the ~90gb limit on my 256gb SD cards. When can we expect this to be ready to download via the normal update process?
Hi SlabSlayer, I’m very confused by this reply. My Wyze Cam v3 on firmware 4.36.9.139 (May 2022) is still stuck at 87.94GB recording on a 256gb SD card. Based on the comments above by carverofchoice, I understood that the fix was going into public beta in August. So how was this fixed several releases ago?
The new firmware 4.36.10.2864 (November 2, 2022) is out, but according to their change log, they are doing a rolling push over two weeks, so it might take some time before you receive it.
I am also waiting for the same firmware for all my V3 camera.
Thank you for the quick reply. The fact that 4.36.10.2700 is missing from the Wyze Cam v3 Firmware Release Notes page (presumably along with the description of the fix) was the source of my confusion on this.
I do find it strange that 4.36.10.2700 was released a few weeks ago and hasn’t made it to my cameras yet - must be a very gradual release.
I’ll wait for the release to be made available to my cameras and then download the update through the app and test.
I sent a message asking for clarification. Right now I can only speculate that the newest release, 4.36.10.2864, was dropped before a majority of V3’s got the .2700 version. I really don’t understand the recent trend of slow rollout for all the FW. Making users wait for features and fixes that other users are posting about is so frustrating! I pushed all my V3 cams to Beta FW as soon as .2700 was released for Beta testing just to get this very feature for my 256GB cards.
As I indicated though, you are able to download it and flash it to the cam if you don’t want to wait.
My cameras got the update on November 4. A word of warning: Any recordings prior to the firmware update appear to only have loud staticky noise as the audio track.
If that was a known side-effect of their fix, it ought to have been communicated to customers PRIOR TO THE UPDATE! Some customers might have wanted to save clips with useful audio before the firmware comes in and destroys it.
last paragraph).
: A glitch has been reported by 