Video Sync Issue

[Haddix239]

Video quickly gets out of sync when streaming. I can restart wyzebridge to sync it again, but it gets severely out of date in a matter of minutes. It's currently off by 45 minutes after running for less than an hour. I am using the latest image. This has rendered wyzebridge unusable for me.

[Haddix239]

This started after a recent firmware update. I only updated one camera at a time and the issue only presents itself with the newer versions of Wyze Cam firmware. I have a few that have not been updated and they are not having any issues.

[StoneLegion]

I just don't get the wyze itself seems fine just the bridge with it seems broken?

[thehijacker]

I've had tons of variables set in docker compose like:

      - IGNORE_OFFLINE=true
      - FPS_FIX=true
      - ENABLE_BOA=true
      - NET_MODE=LOCAL
      - QUALITY_VHOD=HD60
      - QUALITY_TERASA=HD60

Since I removed them this morning all is stable and no more out of sync. Which one of this solved this I have no idea.

[cturra]

sharing my findings so far -- the only one of the options @thehijacker mentions above that i had was NET_MODE=LAN. removing it made no difference for me.

[maclarel]

Same issue here. This also manifests with the wyze-bridge container eating up massive amounts of CPU and memory compared to its usual load.

The only extra configuration option I'm using from the scenario above is QUALITY. I'm testing removing it now, but this has led to other buffering problems historically.

Update 2 days later - drift is only a few seconds now. This definitely looks like a bug in Wyze Bridge.

Update 3 weeks later - on latest I've also been significant significant CPU and RAM utilization as noted above - this did not get resolved by removing the QUALITY settings. I've reverted back to 2.6.0 at this point and all issues appear to be resolved adding further evidence to this being a bug in wyze-bridge rather than on the Wyze side.

[curtisbarnard]

This is the same issue as #1086

Some additional info from my side after I've upgraded to 2.7.0 I've noticed:

• I have two Wyze Cam V3 on firmware 4.36.11.8391
  • one of them seems to drift and was off by almost two hours today
  • the other seems to stay on time
  • restarting the add-on via home assistant seems to have put them back in sync
  • After restart I'm sitting at 5% CPU and 6% RAM usage.
• Wyze Cam V2 is connecting with the add-on, but is no longer playing nice with a home assistant card.

I'll report back in a day or so if the timing gets off and/or the resource usage increases.

[RUHavingFun]

I am seeing the same issue.

I am currently testing with almost no parameters now (just the creds and camera list). Seems a bit better. Will see.

*** UPDATE ***

Did not work. Still having the same issue.

services:
    wyze-bridge:
        container_name: wyze-bridge
        network_mode: host
        restart: always
        pull_policy: always
        image: mrlt8/wyze-bridge:latest
        environment:
#            - NET_MODE=LAN
#            - FRESH_DATA=true
            - WYZE_EMAIL=
            - WYZE_PASSWORD=
#            - QUALITY=HD120
#            - RTSP_READTIMEOUT=10s
#            - RTSP_PROTOCOLS=tcp
#            - RTSP_PATHS_ALL_READUSER=
#            - RTSP_PATHS_ALL_READPASS=
            - FILTER_NAMES=

[34t614t1254y]

It's same for me.

If I leave it for a week, the delay goes too long like few hours.

But the camera doesn't change any options like video stream quality.

Don't know why.

I have 5 wyze cam.

Only one camera connected docker seems to be okay.

Two camera connected docker has the hourly delay issue.

And another two camera connected docker has the issue but only for more than 10 seconds delay issue.

[kk246]

Here's a strange observation. (Please respond if you can replicate).

The initial stream that had drifted behind can be brought back to being up to date if I start a seperate stream in parallel from a seperate device using the tinycam android app (and that enough times passes for the initial stream to catch up)

[StoneLegion]

Here's a strange observation. (Please respond if you can replicate).

The initial stream that had drifted behind can be brought back to being up to date if I start a seperate stream in parallel from a seperate device using the tinycam android app (and that enough times passes for the initial stream to catch up)

I find if I leave it all running for many hours even days it all sync's up again in the end. I don't even dare reboot because that is when it desyncs. I actually now keep both the camera and software timestamps on to compare them lol. Right now it's about 2-5 seconds off via all my camera's but been running for like a week.

[MochiLata]

I just downgraded back to 2.4 and it seems like it works fine again. My purely random bet is that it's the upgrade to 64bit code that is the problem.

[RUHavingFun]

I just downgraded back to 2.4 and it seems like it works fine again. My purely random bet is that it's the upgrade to 64bit code that is the problem.

I am try this now too. Any reason you went that far back? 2.6 is where I see 64 bit introduction.

[MochiLata]

I am try this now too. Any reason you went that far back? 2.6 is where I see 64 bit introduction.

It was the last version that worked for me with no problems. I'm slowly testing versions after 2.4.0. So far 2.5.0 works without video sync problems for me. I'll try a couple of days and move to 2.6.0.

[RUHavingFun]

I am try this now too. Any reason you went that far back? 2.6 is where I see 64 bit introduction.

It was the last version that worked for me with no problems. I'm slowly testing versions after 2.4.0. So far 2.5.0 works without video sync problems for me. I'll try a couple of days and move to 2.6.0.

You were right. 2.4.0 has been stable and video lag completely gone. I will step up to a 2.5 version too and see.

[Deach01]

I don’t think it’s really a video sync issue, although it could be caused by the attempts to fix the sync problems possibly dropping frames to “catch up”. The creeping lag has been mentioned in many reports by now. I’m running 2.7 on Home Assistant on a Pi4b with three cam pan V3’s V4.50.4.8409 and a cam V3 V4.36.11.8391. After 24 hours, all the cams timestamp and pictures are one hour old, but still running and streaming. Audio is turned OFF in wyzebridge. It resets if I go I to the Wyze bridge web page directly and refresh all the cameras manually. I hope that this thing isnt thrashing my sd card to death. Four hours of video has to be stored somewhere. Il try to remember to cpu, ram and a storage tomorrow. This occurs using both the generic and ffmpeg camera options.

EDIT/UPDATE I figured out how to downgrade Wyzebridge in Home Assistant. Happy to report that V2.5.3 (which is what you get when you download V2.6) has been working now for over 8 hours with 4 cameras and they are between one and three seconds delayed. I definately looks like Wyzebridge 2.7 is broken, just revert to 2.5.3 (2.6 download) and it’s fine.

[ctml91]

Same issue here with wyze doorbell, over time the feed becomes more delayed. After a restart of wyze bridge it's only about 5 seconds (not ideal, but okay) and several ours later it's a few minutes behind.

[RUHavingFun]

I don’t think it’s really a video sync issue, although it could be caused by the attempts to fix the sync problems possibly dropping frames to “catch up”. The creeping lag has been mentioned in many reports by now. I’m running 2.7 on Home Assistant on a Pi4b with three cam pan V3’s V4.50.4.8409 and a cam V3 V4.36.11.8391. After 24 hours, all the cams timestamp and pictures are one hour old, but still running and streaming. Audio is turned OFF in wyzebridge. It resets if I go I to the Wyze bridge web page directly and refresh all the cameras manually. I hope that this thing isnt thrashing my sd card to death. Four hours of video has to be stored somewhere. Il try to remember to cpu, ram and a storage tomorrow. This occurs using both the generic and ffmpeg camera options.

Agreed - this has to be something buffered on the WyzeBridge - as direct connections via Wyze app all show current. As you suggested it has to be reading it from somewhere - either memory or SD card - both are bad. I want this to be light weight and current.

[ctml91]

I wouldn't mind it writing a small buffer to swap/memory but definitely not persistent disk, which will kill drives. My ssd recently failed, now I wonder if this was writing 24/7 to it 😆

[ctml91]

Reverted back to v2.6, haven't seen the video delay after running several hours. Only 1-2 second back of live.

[letrain02]

I wouldn't mind it writing a small buffer to swap/memory but definitely not persistent disk, which will kill drives. My ssd recently failed, now I wonder if this was writing 24/7 to it 😆

so from your comment i've mapped tmp to ram on my server. its gone from 300mb to 550mb in about 2 hours. we shall see what a longer run produces. the tmp directory has mtx_event in it.

[RUHavingFun]

Reverted back to v2.6, haven't seen the video delay after running several hours. Only 1-2 second back of live.

I am on 2.5.3 and is good. I may try to go to 2.6 as well then.

[RUHavingFun]

I wouldn't mind it writing a small buffer to swap/memory but definitely not persistent disk, which will kill drives. My ssd recently failed, now I wonder if this was writing 24/7 to it 😆

so from your comment i've mapped tmp to ram on my server. its gone from 300mb to 550mb in about 2 hours. we shall see what a longer run produces. the tmp directory has mtx_event in it.

Seems like a great idea. I would rather something like a tmp be in RAM. I have 4GB and only use a few hundred MB. I have not done this before - can you explain real quick how?

Also, wouldn't it be better for speed and all if things like this were in RAM anyway? Seems very little should be written to the disk other than logging to me.

[letrain02]

I wouldn't mind it writing a small buffer to swap/memory but definitely not persistent disk, which will kill drives. My ssd recently failed, now I wonder if this was writing 24/7 to it 😆

so from your comment i've mapped tmp to ram on my server. its gone from 300mb to 550mb in about 2 hours. we shall see what a longer run produces. the tmp directory has mtx_event in it.

Seems like a great idea. I would rather something like a tmp be in RAM. I have 4GB and only use a few hundred MB. I have not done this before - can you explain real quick how?

Also, wouldn't it be better for speed and all if things like this were in RAM anyway? Seems very little should be written to the disk other than logging to me.

I mapped /tmp:/tmp/docker-wyze

Tmp happens to be my ram in unraid. Not sure how it is mapped on your system. It's just like any other path you map in docker.

[BinLagging]

I don’t think it’s really a video sync issue, although it could be caused by the attempts to fix the sync problems possibly dropping frames to “catch up”. The creeping lag has been mentioned in many reports by now. I’m running 2.7 on Home Assistant on a Pi4b with three cam pan V3’s V4.50.4.8409 and a cam V3 V4.36.11.8391. After 24 hours, all the cams timestamp and pictures are one hour old, but still running and streaming. Audio is turned OFF in wyzebridge. It resets if I go I to the Wyze bridge web page directly and refresh all the cameras manually. I hope that this thing isnt thrashing my sd card to death. Four hours of video has to be stored somewhere. Il try to remember to cpu, ram and a storage tomorrow. This occurs using both the generic and ffmpeg camera options.

EDIT/UPDATE I figured out how to downgrade Wyzebridge in Home Assistant. Happy to report that V2.5.3 (which is what you get when you download V2.6) has been working now for over 8 hours with 4 cameras and they are between one and three seconds delayed. I definately looks like Wyzebridge 2.7 is broken, just revert to 2.5.3 (2.6 download) and it’s fine.

Can you explain how to downgrade? Thanks

[letrain02]

I wouldn't mind it writing a small buffer to swap/memory but definitely not persistent disk, which will kill drives. My ssd recently failed, now I wonder if this was writing 24/7 to it 😆

so from your comment i've mapped tmp to ram on my server. its gone from 300mb to 550mb in about 2 hours. we shall see what a longer run produces. the tmp directory has mtx_event in it.

Seems like a great idea. I would rather something like a tmp be in RAM. I have 4GB and only use a few hundred MB. I have not done this before - can you explain real quick how?

Also, wouldn't it be better for speed and all if things like this were in RAM anyway? Seems very little should be written to the disk other than logging to me.

I mapped /tmp:/tmp/docker-wyze

Tmp happens to be my ram in unraid. Not sure how it is mapped on your system. It's just like any other path you map in docker.

So after 3 days of running with tmp:tmp(ram) mapped to docker-wyze container I've only had one camera out of sync by a few hours one time, after reconnecting camera it has never manifested again. A few seconds here and there but pretty much in sync on them all. Funny thing is during this issue my snapshots were accurate. My cameras could be out for sync by up to 4 hours, but the snapshots I get every 15 minutes work fine, and both the time stamp and time taken match.

I have a grafana dashboard running almost 18 hours a day with hls streams for the cameras on it. I haven't tried any other streams.

[DAcodedBEAT]

I am facing the same issue on >=2.7.0 when running this in docker on a Raspberry Pi, where the video exponentially gets out of sync the longer wyze bridge is running.

Reverting to 2.6.0 is good, where it maintains the same amount of video sync delay. Any ideas about what might be going wrong?

[Deach01]

@DAcodedBEAT there seems to be some issues with version numbering. V2.70 can show as V2.6 sometimes. I think it depends on how the version is queried. I suspect it didn’t get changed somewhere in the code.

I selected the code “V2.6” to download in GitHub and, after install, the local Docker Wyze-Bridge web page says it’s V2.5.3

I don’t understand what you meant about maintaining the same amount of sync delay. Do you mean that the delay is still increasing? Or that there is now a fixed delay. There’s always up to a few seconds delay. It can also get longer if the cpu/disk/network has high load.

[Deach01]

@BinLagging Here’s what I did to downgrade WyzeBridge in Home Assistant on a Pi4b running HA OS.

It assumes: You can copy files to the HA machine You can use a command line terminal session on the HA machine You are familiar with the following terminal commands: unzip rm

IMPORTANT! Before doing this, make a complete backup of HA and keep a copy on a different machine!

WARNING / DISCLAIMER You can easily destroy your system, especially working in command line and mossy especially if you get the syntax of the rm and mv commands wrong! ALWAYS check that there’s no typos before hitting the enter key!

notes: The HA OS is somewhat (very) crippled and locked down. The “HA file editor” won’t allow direct upload to anything outside its restricted little world. This is why I used the command line terminal to get the apps folder from the zip file into the /root/addons directory. There may be other, safer and easier ways off doing this. Samba is one option if installed and configured. As always in Linux, there are multiple ways to reach a goal. I’m comfortable with command line, so that’s how “I” did this…

The procedure!!!

Download the zip file for the version you want from GitHub to your computer (I used my windows laptop). Upload the zip file to the Home Assistant system (I use HA file editor Use a terminal on HA to unzip the file mv the apps folder you just unzipped to /root/addons/ In HA, refresh addons, Settings, add-ons, add-on store, top right three vertical dots, Check for updates, back to settings, then Add-ons, Add-on store It will show up as local addons Install it

If you haven’t yet uninstalled the 2.7 Wyzebridge, you will see two Docker Wyze Bridge add-ons in the Add-ons page Do NOT run both at once! If the 2.7 is still running it will have a green “jigsaw piece” badge Click on that one and confirm it says “current version 2.7 under the bold white title. Go ahead and STOP that one from this screen Now, select the other one and confirm that it says Current Version 2.5.3 START this one Confirm it’s all working, you can click on “Open Web UI” to check If all is good, it’s ok to go back to the 2.7 one, make sure you ARE on the 2.7 one and uninstall 2.7

For good housekeeping, go back into the terminal and remove the zip file and anything left over from the unzip in wherever you uploaded too.

[DAcodedBEAT]

Hi @Deach01, thanks for the quick reply

I pulled 2.7.0 from Dockerhub so it should be v2.7 (regardless of what the installed web ui says).

I don’t understand what you meant about maintaining the same amount of sync delay. Do you mean that the delay is still increasing? Or that there is now a fixed delay. There’s always up to a few seconds delay. It can also get longer if the cpu/disk/network has high load.

Yes, the delay continues to increase the longer that the process/container is running. Nothing else is running on the machine and using the 2.6.0 tag doesn't have this compounding delay issue.

[letrain02]

I wouldn't mind it writing a small buffer to swap/memory but definitely not persistent disk, which will kill drives. My ssd recently failed, now I wonder if this was writing 24/7 to it 😆

so from your comment i've mapped tmp to ram on my server. its gone from 300mb to 550mb in about 2 hours. we shall see what a longer run produces. the tmp directory has mtx_event in it.

Seems like a great idea. I would rather something like a tmp be in RAM. I have 4GB and only use a few hundred MB. I have not done this before - can you explain real quick how?

Also, wouldn't it be better for speed and all if things like this were in RAM anyway? Seems very little should be written to the disk other than logging to me.

I mapped /tmp:/tmp/docker-wyze

Tmp happens to be my ram in unraid. Not sure how it is mapped on your system. It's just like any other path you map in docker.

So after 3 days of running with tmp:tmp(ram) mapped to docker-wyze container I've only had one camera out of sync by a few hours one time, after reconnecting camera it has never manifested again. A few seconds here and there but pretty much in sync on them all. Funny thing is during this issue my snapshots were accurate. My cameras could be out for sync by up to 4 hours, but the snapshots I get every 15 minutes work fine, and both the time stamp and time taken match.

I have a grafana dashboard running almost 18 hours a day with hls streams for the cameras on it. I haven't tried any other streams.

Follow-up... So the delay issue has started manifesting again. Nothing I've tried mitigates it completely. It's even started making my snapshots incorrect. Tried nightly and that seemed to work for a few days. But eventually manifests usually around noon-1pm my time and the cameras just seem to keep repeating about the same 30 minutes over and over. 2.6.0 is working fine so far. We will see what today brings around noon.