search

mrlt8 / docker-wyze-bridge

WebRTC/RTSP/RTMP/LL-HLS bridge for Wyze cams in a docker container
GNU Affero General Public License v3.0
2.46k stars 151 forks source link

Video Sync Issue #1108

Open Haddix239 opened 5 months ago

Haddix239 commented 5 months ago

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 commented 5 months ago

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.

KaneHart commented 5 months ago

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

thehijacker commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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'll report back in a day or so if the timing gets off and/or the resource usage increases.

RUHavingFun commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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)

KaneHart commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

letrain02 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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.

kk246 commented 4 months ago

Anyone know how to downgrade to a version supported by https://github.com/gtxaspec/wz_mini_hacks ?

Everytime I try to hold the button upon power cycle on my Wyze cam v3 for flashing, it just completely ignores the firmware file I put in the sd card.

It just goes into pairing mode.

On 2 Mar 2024, at 12:04 am, letrain02 @.***> wrote:



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.

— Reply to this email directly, view it on GitHubhttps://github.com/mrlt8/docker-wyze-bridge/issues/1108#issuecomment-1973161989, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACRSQCIO7D3MYPXJQRC6SYDYWB4FZAVCNFSM6AAAAABCN7H5PKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZTGE3DCOJYHE. You are receiving this because you commented.Message ID: @.***>

leatherlipps commented 4 months ago

I had to make sure I was using an SD card formatted to fat32. Not sure if that's your issue but it was mine.

From: kk246 @.> Sent: Friday, March 1, 2024 8:24:40 PM To: mrlt8/docker-wyze-bridge @.> Cc: Subscribed @.***> Subject: Re: [mrlt8/docker-wyze-bridge] Video Sync Issue (Issue #1108)

Anyone know how to downgrade to a version supported by https://github.com/gtxaspec/wz_mini_hacks ?

Everytime I try to hold the button upon power cycle on my Wyze cam v3 for flashing, it just completely ignores the firmware file I put in the sd card.

It just goes into pairing mode.

On 2 Mar 2024, at 12:04 am, letrain02 @.***> wrote:



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.

— Reply to this email directly, view it on GitHubhttps://github.com/mrlt8/docker-wyze-bridge/issues/1108#issuecomment-1973161989, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACRSQCIO7D3MYPXJQRC6SYDYWB4FZAVCNFSM6AAAAABCN7H5PKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZTGE3DCOJYHE. You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHubhttps://github.com/mrlt8/docker-wyze-bridge/issues/1108#issuecomment-1974162169, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AE775KR5CPSZC7VCCYC3X3TYWES5RAVCNFSM6AAAAABCN7H5PKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUGE3DEMJWHE. You are receiving this because you are subscribed to this thread.Message ID: @.***>

Deach01 commented 4 months ago

@kk246 I think your in the wrong thread in the wrong project. You could ask in the wz_mini_hacks project on Github rather than in the entirely different Wyze Bridge project and in a thread discussing a completely different issue.

Technoslave commented 3 months ago

I had to make sure I was using an SD card formatted to fat32. Not sure if that's your issue but it was mine.

I thought this might be the issue too (with how delayed things were getting, and BI wasn't having any issues with other cameras, so it seemed the obvious issue), so I removed the SD card completely, still had the issue, so reverted my docker instance back to 2.6, and have been fine for the past two weeks.

Raul-7-7 commented 3 months ago

Same experience here, 2.6 is working fine, 2.7 had sync issues.

swarshah commented 3 months ago

I thought it was an issue with frigate that event clips were delayed, but it turns out version 2.7 is the issue.

KaneHart commented 3 months ago

I use docker, how do I change it to use 2.6 correctly?

version: '2.4'
services:
    wyze-bridge:
        container_name: wyze-bridge
        restart: unless-stopped
        image: mrlt8/wyze-bridge:dev
        ports:
            - 1935:1935 # RTMP
            - 8554:8554 # RTSP
            - 8888:8888 # HLS
            - 8889:8889 #WebRTC
            - 8189:8189/udp # WebRTC/ICE
            - 8080:5000 # WEB-UI
        environment:
            - WYZE_EMAIL=xxxxxxxxxxxxx
            - WYZE_PASSWORD=xxxxxxxxxx
            - SUBSTREAM=False
Raul-7-7 commented 3 months ago

@KaneHart you need to change the image tag from :dev to :2.6.0

KaneHart commented 3 months ago

@KaneHart you need to change the image tag from :dev to :2.6.0 Thank you, That was simple. I kept trying google it and got nowhere hehe.

DAcodedBEAT commented 3 months ago

So while using 2.6 is an interim fix for users, are any devs currently looking into this issue / uncovered the root cause so it can be fixed going forward?

jarrah31 commented 3 months ago

I have video lag on 2.5.3, 2.6, and 2.7 on my WyzeCam v3 and v3 pro devices that can easily end up being a couple of hours behind. :(

squirrelchew commented 3 months ago

Cross posting from the video delay thread in the discussion forum:

I actively monitor cameras to watch a dog elsewhere in the house, as well as for deliveries, so having feed delays are glaring issue here. I moved from RTSP firmware to the modern firmware + wyze bridge in hopes I could use new hardware a week or so ago and have been fighting this since.

I currently have three v2 cams (only two active), two v3 cams, and one v2 doorbell deployed.

I am running the wyze bridge in UNRAID backed by some number of Xeon X5680 cores.

The wyze bridge feeds are being consumed by Frigate on the same UNRAID instance, with a GTX1650 forwarded and six CPU cores pinned to it. There are zero performance issues with Frigate that I can find, and I have gone as far as fully disabling object detection to test this.

When running with audio enabled, AAC codec specified, I would get a lot of macroblocking on moving objects. I turned off audio a day or two ago and that appears to have been fixed, but the delay was not fixed.

I restarted the bridge this morning and after 1-2 hours it was already out of sync by over a minute. After 1-2 days I approach 30 minutes on some cameras. The cameras that fall out of sync are seemingly random -- nothing to do with wifi signal, version, etc.. I do have a dedicated access point arriving later this week for the cameras to run on, but I don't expect that to fix anything.

I have downgraded to 2.6.0 as of this writing and will monitor it throughout today. Currently, the cameras are reporting a spread of 10 seconds on their timestamps.

Since writing that, the 10 second spread has shrunk to 5 seconds. The cameras that were ten seconds apart are now less than 1 second apart.

Interestingly, the wyze bridge UI is showing video that's 15 seconds out of date for the camera that was initially most up to date, when compared to that same camera's feed within Frigate.

squirrelchew commented 3 months ago

Almost two hours in and sync seems fine. The spread is almost 9 seconds again, and at time point I assume it's just the time on the cameras instead of streaming/encoding delays.

At 11:57:00, the cameras in Frigate showed 56:56, 56:59, 56:59, 57:01, and 57:05.

This was achieved running mrlt8/wyze-bridge:2.6.0 with the following env vars:

FRESH_DATA=True
WB_IP=
WYZE_EMAIL=lol@no.pe
WYZE_PASSWORD=hunter2
ON_DEMAND=False
LAN=LAN

Update - it absolutely appears to be the in-camera time. A car drove by where two cameras overlap, and despite the 3 second difference between the cameras, the car was in the same place.

Mark me down as someone who found 2.6.0 to be a successful workaround to the video delay. Hopefully the dev is just on vacation or something. :)

jarrah31 commented 2 months ago

I updated to 2.8.1 earlier this morning - 12 hours later and so far so good, no video lagging at all!