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.7k stars 176 forks source link

Help Fix bitrate and super slow errors #1194

Open airbornetrooper82573 opened 6 months ago

airbornetrooper82573 commented 6 months ago

I have 2 V4 cams and 1 v3. I'm getting these errors now and I'm not sure how to fix them. I can't seem to load the feeds on my iPhone anymore either.

My compose:

version: '2.4' services: wyze-bridge: container_name: wyze-bridge network_mode: host restart: unless-stopped image: mrlt8/wyze-bridge:latest ports:

My errors: [WyzeBridge] 192.168.1.102 - - [13/May/2024 17:08:44] "GET /signaling/front-porch-cam?webrtc HTTP/1.1" 200 - [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 23%) FW: 4.52.3.9455 🔒 [front-porch-cam] Re-encoding audio for compatibility with WebRTC in MTX [front-porch-cam] 🔊 Audio Enabled - AAC_ELD > LIBOPUS/16,000Hz [front-porch-cam] WARNING: Skipping wrong frame_size at start of stream [frame_size=1] [front-porch-cam] [video] super slow [front-porch-cam] WARNING: clear buffer [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] [video] super slow [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] [video] super slow [WyzeBridge] ✅ '/front-porch-cam stream is UP! (3/3) [WyzeBridge] 📖 New client reading from front-porch-cam [front-porch-cam] [video] super slow [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [WyzeBridge] 📕 Client stopped reading from front-porch-cam [front-porch-cam] WARNING: Audio pipe closed [front-porch-cam] Stream stopped [WyzeBridge] ❌ '/front-porch-cam' stream is down [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [WyzeBridge] ❌ '/front-porch-cam' stream is down [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 25%) FW: 4.52.3.9455 🔒 [front-porch-cam] [Exception] Unable to identify audio. [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 24%) FW: 4.52.3.9455 🔒 [front-porch-cam] [Exception] Unable to identify audio. [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 23%) FW: 4.52.3.9455 🔒 [front-porch-cam] [Exception] Unable to identify audio. [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 21%) FW: 4.52.3.9455 🔒 [front-porch-cam] Re-encoding audio for compatibility with WebRTC in MTX [front-porch-cam] 🔊 Audio Enabled - AAC_ELD > LIBOPUS/16,000Hz [front-porch-cam] WARNING: Skipping wrong frame_size at start of stream [frame_size=1] [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] WARNING: Still waiting for first frame. Updating frame size. [front-porch-cam] Requesting frame_size=3, bitrate=180, fps=0 [front-porch-cam] WARNING: Audio pipe closed [front-porch-cam] [Exception] Did not receive a frame for 20s [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 25%) FW: 4.52.3.9455 🔒 [front-porch-cam] Re-encoding audio for compatibility with WebRTC in MTX [front-porch-cam] 🔊 Audio Enabled - AAC_ELD > LIBOPUS/16,000Hz [front-porch-cam] WARNING: Skipping wrong frame_size at start of stream [frame_size=1] [front-porch-cam] [video] super slow [front-porch-cam] WARNING: clear buffer [WyzeBridge] ✅ '/front-porch-cam stream is UP! (3/3) [WyzeBridge] 📖 New client reading from front-porch-cam [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] WARNING: Audio pipe closed [front-porch-cam] Stream stopped [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [WyzeBridge] ❌ '/front-porch-cam' stream is down [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [WyzeBridge] 📕 Client stopped reading from front-porch-cam [WyzeBridge] ❌ '/front-porch-cam' stream is down [WyzeBridge] 🎉 Connecting to WyzeCam V4 - Front Porch Cam on 192.168.10.166 [front-porch-cam] 📡 Getting 180kb/s 2K stream (H264/20fps) via LAN mode (WiFi: 25%) FW: 4.52.3.9455 🔒 [front-porch-cam] Re-encoding audio for compatibility with WebRTC in MTX [front-porch-cam] 🔊 Audio Enabled - AAC_ELD > LIBOPUS/16,000Hz [front-porch-cam] WARNING: Skipping wrong frame_size at start of stream [frame_size=1] [WyzeBridge] ✅ '/front-porch-cam stream is UP! (3/3) [WyzeBridge] 📖 New client reading from front-porch-cam [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0 [front-porch-cam] WARNING: clear buffer [back-yard-cam] bitrate=108 does not match 180 [back-yard-cam] Requesting frame_size=0, bitrate=180, fps=0

mrlt8 commented 6 months ago

Can you try the latest dev build to see if that helps with the stability of the streams?

airbornetrooper82573 commented 6 months ago

I switched to dev and same thing. Still getting bitrate does not match and super slow errors. I can't even get streams to play on the bridge web GUI and definitely not Home app. I did change the rtsp url to rtsp://wb:thekeythatisdisplayedatthebottomofthebridgegui@192.168.1.215:8554/driveway-v4

airbornetrooper82573 commented 6 months ago

I figured out the web gui part, I had my truenas server's IP as the WB_IP. I can see the feeds on WB gui fine now. Still can't get it to show up in Scrypted or Home app.

mrlt8 commented 6 months ago

hmm, what kind of cam is back-yard-cam? I'm not sure where bitrate=108 is coming from...

FYI, the bridge will generate a random API key on startup if you don't define one or it doesn't find one in the local directory. You can either set WB_AUTH=False if you keep everything local, or manually set the WB_API key:

environment:
...
    - WB_API=MyCustomAPIKey

or volume mount the token directory:

environment:
...
volumes:
      - /path/to/store/tokens/on/host:/tokens

and it will reuse the same data on subsequent starts.

airbornetrooper82573 commented 6 months ago

I added the custom key. In scrypted, I'm leaving user/pass blank and putting in rtsp://wb:mycustomkey@192.168.1.215:8554/driveway-v4 and still no snapshot or anything.

The back-yard-cam is a v3.

mrlt8 commented 6 months ago

can you open rtsp://wb:mycustomkey@192.168.1.215:8554/driveway-v4 in another media player like VLC?

airbornetrooper82573 commented 6 months ago

It's not loading in VLC

mrlt8 commented 6 months ago

What about just rtsp://192.168.1.215:8554/driveway-v4? VLC should prompt for some credentials if auth is enabled.

airbornetrooper82573 commented 6 months ago

I got both ways to work in VLC. I think my phone changed rtsp to rtps and I did't catch it.

In scrypted do I put in wb for username and my api as password and put the plain RTSP stream URL in?

mrlt8 commented 6 months ago

I would try the plain RTSP url with the credentials in the fields since it has that option and will make it easier to maintain in the future.

airbornetrooper82573 commented 6 months ago

I did that for all 3 cameras and still not working on scrypted or Home.

[Back Yard Cam] rebroadcast error Error: rtsp socket closed at Socket. (/@scrypted/prebuffer-mixin/main.nodejs.js:1:140295) at Socket.emit (node:events:519:28) at Socket.emit (node:domain:488:12) at TCP. (node:net:338:12) [Front Porch Cam] rebroadcast error Error: rtsp socket closed at Socket. (/@scrypted/prebuffer-mixin/main.nodejs.js:1:140295) at Socket.emit (node:events:519:28) at Socket.emit (node:domain:488:12) at TCP. (node:net:338:12) [Driveway v4] rebroadcast error Error: rtsp socket closed at Socket. (/@scrypted/prebuffer-mixin/main.nodejs.js:1:140295) at Socket.emit (node:events:519:28) at Socket.emit (node:domain:488:12) at TCP. (node:net:338:12)

airbornetrooper82573 commented 6 months ago

I can only get the RTSP feed to work in Scrypted if I set WB_AUTH=False

WarrenSchultz commented 5 months ago

This seems tangentially related, but I'm getting the same error as mentioned above. I've had the issue for a while, but haven't had time to dig into it. It's a Cam v3, with the light socket add-on.

bitrate=108 does not match 180

Camera info:
audio | false
apartalarmParm | { "heightY": "100", "longX": "100", "startX": "0", "startY": "0", "type": "1" }
audioParm | { "sampleRate": "16000" }
basicInfo | { "firmware": "4.36.12.9751", "hardware": "0.0.0.0", "mac": "xxxxxxxx", "model": "WYZE_CAKP2JFUS", "type": "camera", "wifidb": "37" }
channelResquestResult | { "audio": "0", "video": "1" }
recordType | { "type": "1" }
sdParm | { "capacity": "30424", "detail": "0", "free": "1327", "status": "1" }
settingParm | { "logSd": "1", "logUdisk": "1", "nightVision": "3", "osd": "1", "stateVision": "1", "telnet": "2", "tz": "-4" }
uDiskParm | { "capacity": "0", "free": "0", "status": "2" }
videoParm | { "bitRate": "30", "fps": "15", "horizontalFlip": "1", "logo": "2", "resolution": "2", "time": "1", "type": "H264", "verticalFlip": "1" }
connected | true
dtls | 1
enabled | true
firmware_ver | 4.36.12.9751
hls_url | http://xxxxxx:8888/garage-entry/
img_time | 1720236481369
img_url | img/garage-entry.jpg
ip | 192.168.126.157
is_2k | false
is_battery | false
mac | D03F27133A7E
model_name | V3
motion | false
motion_ts | 0
name_uri | garage-entry
nickname | Garage Entry
on_demand | true
p2p_type | 3
parent_dtls | 0
parent_mac |  
product_model | WYZE_CAKP2JFUS
record | false
req_bitrate | 180
req_frame_size | 0
rtmp_url | rtmp://xxxxx:1935/garage-entry
rtsp_fw | false
rtsp_fw_enabled | false
rtsp_url | rtsp://xxxxxx:8554/garage-entry
snapshot_url | snapshot/garage-entry.jpg
start_time | 1720236034.5602236
status | 3
stream_auth | false
substream | false
thumbnail | https://rest.cache.cell-2-us-west-2-1.pr...
thumbnail_url | thumb/garage-entry.jpg
timezone_name | America/New_York
webrtc | true
webrtc_url | http://xxxxx:8889/garage-entry/

audio   false
apartalarmParm  { "heightY": "100", "longX": "100", "startX": "0", "startY": "0", "type": "1" }
audioParm   { "sampleRate": "16000" }
basicInfo   { "firmware": "4.36.12.9751", "hardware": "0.0.0.0", "mac": "D03F27133A7E", "model": "WYZE_CAKP2JFUS", "type": "camera", "wifidb": "37" }
channelResquestResult   { "audio": "0", "video": "1" }
recordType  { "type": "1" }
sdParm  { "capacity": "30424", "detail": "0", "free": "1327", "status": "1" }
settingParm { "logSd": "1", "logUdisk": "1", "nightVision": "3", "osd": "1", "stateVision": "1", "telnet": "2", "tz": "-4" }
uDiskParm   { "capacity": "0", "free": "0", "status": "2" }
videoParm   { "bitRate": "30", "fps": "15", "horizontalFlip": "1", "logo": "2", "resolution": "2", "time": "1", "type": "H264", "verticalFlip": "1" }
connected   true
dtls    1
enabled true
firmware_ver    4.36.12.9751
hls_url http://xxxxxx:8888/garage-entry/
img_time    1720236481369
img_url [img/garage-entry.jpg](http://xxxxxxx:5000/img/garage-entry.jpg)
ip  xxxxxxxxx
is_2k   false
is_battery  false
mac xxxxxxxxxxxxxx
model_name  V3
motion  false
motion_ts   0
name_uri    garage-entry
nickname    Garage Entry
on_demand   true
p2p_type    3
parent_dtls 0
parent_mac  
product_model   WYZE_CAKP2JFUS
record  false
req_bitrate 180
req_frame_size  0
rtmp_url    rtmp://xxxxx:1935/garage-entry
rtsp_fw false
rtsp_fw_enabled false
rtsp_url    rtsp://xxxxx:8554/garage-entry
snapshot_url    [snapshot/garage-entry.jpg](http://xxxxx:5000/snapshot/garage-entry.jpg)
start_time  1720236034.5602236
status  3
stream_auth false
substream   false
thumbnail   
thumbnail_url   [thumb/garage-entry.jpg](http://xxxxxx:5000/thumb/garage-entry.jpg)
timezone_name   America/New_York
webrtc  true
webrtc_url  http://xxxxx:8889/garage-entry/
mrlt8 commented 5 months ago

@WarrenSchultz are you running the latest version of the bridge?

WarrenSchultz commented 5 months ago

@mrlt8 Correct. I've tried both latestand latest-hw (pulling just relevant lines, there are other cameras as well)

More details: wyze-bridge | [WyzeBridge] 🎉 Connecting to WyzeCam V3 - Garage Entry on xxxx wyze-bridge | [garage-entry] 📡 Getting 180kb/s HD stream (H264/15fps) via LAN mode (WiFi: 39%) FW: 4.36.12.9751 🔒 wyze-bridge | [garage-entry] WARNING: Skipping wrong frame_size at start of stream [frame_size=1] wyze-bridge | [WyzeBridge] ✅ '/garage-entry stream is UP! (3/3) wyze-bridge | [WyzeBridge] 📖 New client reading from garage-entry

wyze-bridge  | [garage-entry] bitrate=108 does not match 180
wyze-bridge  | [garage-entry] Requesting frame_size=0, bitrate=180, fps=0
mrlt8 commented 5 months ago

That bug should have been fixed a while ago. Can you confirm you're running v2.9.10 which is the current version?

WarrenSchultz commented 5 months ago

image

mrlt8 commented 5 months ago

Thanks @WarrenSchultz!

Does the bitrate=108 does not match 180 message continuously show up in the logs?

Can you try manually changing the bitrate?

http://xxxxx:5000/api/garage-entry/bitrate/300
WarrenSchultz commented 5 months ago

Command successful, same error

{
    "command": "bitrate",
    "payload": "300",
    "status": "success",
    "value": 300
}

[garage-entry] bitrate=108 does not match 300
wyze-bridge  | [garage-entry] Requesting frame_size=0, bitrate=300, fps=0
wyze-bridge  | [garage-entry] bitrate=108 does not match 300
wyze-bridge  | [garage-entry] Requesting frame_size=0, bitrate=300, fps=0
wyze-bridge  | [garage-entry] bitrate=108 does not match 300
wyze-bridge  | [garage-entry] Requesting frame_size=0, bitrate=300, fps=0
wyze-bridge  | [garage-entry] bitrate=108 does not match 300
wyze-bridge  | [garage-entry] Requesting frame_size=0, bitrate=300, fps=0
mrlt8 commented 5 months ago

Hmm, can you reboot the problematic camera to see if that helps?

letrain02 commented 5 months ago

I have this bitrate error no matter what bitrate I set. It's always complaining it doesn't match. Had it for a long time over several versions. I thought it was normal as everything works regardless. T The only time it goes away is when I set nothing for bitrate. But my network can't handle that

mrlt8 commented 5 months ago

Hmmm, does it actually seem to be setting the correct bitrate even thought camera is reporting the wrong bitrate?

@letrain02 are you also running the beta firmware? And did the error start after updating to v1.9.x or after switching to the beta firmware?

Would appreciate if you could try the following API endpoints to see if the camera is returning the correct bitrate somewhere:

http://xxxxx:5000/api/garage-entry/bitrate
http://xxxxx:5000/api/garage-entry/_bitrate
http://xxxxx:5000/api/garage-entry/param_info/3,46
letrain02 commented 5 months ago

Screenshot 2024-07-06 10 07 25

@letrain02 are you also running the beta firmware? And did the error start after updating to v1.9.x or after switching to the beta firmware?

Not running beta firmware. Sorry. I used my mobile device and missed several comments in this thread. I noticed the bitrate and super slow in the issue. I get the super slow error initially when starting the container, but those subside after the cameras drop connection and come back online. But the bit rate issue always stays.

Edit: bridge is 2.9.10

Screenshot_20240706-095504.png

edit:2

all show bitrate 40 being returned. for me.

{"command":"bitrate","payload":null,"response":40,"status":"success","value":40} {"command":"bitrate","payload":"","response":40,"status":"success","value":40} {"command":"param_info","payload":"3,46","response":{"3":200,"46":40},"status":"success","value":{"3":200,"46":40}}

WarrenSchultz commented 5 months ago

param_info/3,46

Rebooted the camera, restarted docker container so everything is "clean", and this is the only camera in use to simplify debugging.

In order:

{
    "command": "bitrate",
    "payload": null,
    "response": 108,
    "status": "success",
    "value": 108
}

{
    "command": "bitrate",
    "payload": "",
    "response": 108,
    "status": "success",
    "value": 108
}
{
    "command": "param_info",
    "payload": "3,46",
    "response": {
        "3": 120,
        "46": 30
    },
    "status": "success",
    "value": {
        "3": 120,
        "46": 30
    }
}
mrlt8 commented 5 months ago

@letrain02 is it only the panv3s that have the issue?

@WarrenSchultz Can you tell if the quality seems to change when adjusting the bitrate over the api?

WarrenSchultz commented 5 months ago

@WarrenSchultz Can you tell if the quality seems to change when adjusting the bitrate over the api? Hm. I tried cranking it down incrementally all the way to 1, and up to 10000, and I can't seem to tell a difference.

It's very odd, the traffic seems to be bursty instead of constant, and I'm not seeing the time counter increment smoothly by the second either. (Although this may be related to the issue we're looking at here?)

I added another couple cameras which are also v3s. One is attached to a garage door controller, and one is a standalone.

wyze-bridge  | [garage-entry] bitrate=108 does not match 180
wyze-bridge  | [garage-entry] Requesting frame_size=0, bitrate=180, fps=0
wyze-bridge  | [garage-door] bitrate=108 does not match 180
wyze-bridge  | [garage-door] Requesting frame_size=0, bitrate=180, fps=0
wyze-bridge  | [hummingbird-cam] bitrate=108 does not match 180
wyze-bridge  | [hummingbird-cam] Requesting frame_size=0, bitrate=180, fps=0
wyze-bridge  | [garage-entry] bitrate=108 does not match 180
mrlt8 commented 5 months ago

Thanks, are the other v3s also running the beta firmware?

Could you see if the edge image makes any difference? It's using a different message to set the bitrate.

WarrenSchultz commented 5 months ago

Yep, all the v3s are running the latest beta firmware.

I just tried the edge container, and same results.

WarrenSchultz commented 5 months ago

So, I happened to have a new cam in box that I updated to 4.36.10.7146, and got this error instead:

wyze-bridge  | [v3-black-test] bitrate=120 does not match 180
wyze-bridge  | [v3-black-test] Requesting frame_size=0, bitrate=180, fps=0
WarrenSchultz commented 5 months ago

One last bit of info. Updated that cam up to the highest non-beta offered in the app, 4.36.11.8391, and I'm not seeing the message there.

letrain02 commented 5 months ago

@letrain02 is it only the panv3s that have the issue?

pano is pan v2. but yes it appears its only pan cameras; v3 and v2 with bitrate issue. my stationary v3's dont appear to have the bitrate complant, and appear correct when checking api

{"command":"bitrate","payload":"","response":30,"status":"success","value":30}-v3 stationary.

the stationary v3's do get super slow warning... i just blame my wifi and metal buildings though.

edit: i tried edge and still that same.

letrain02 commented 5 months ago

@mrlt8 so for fun i changed bitrate to SD40.... the v3-pans stopped complaining, but the v3 sationary cameras now complain that its not 30 bitrate.

Screenshot 2024-07-06 23 42 31

mrlt8 commented 5 months ago

Thanks for the feedback @letrain02 @WarrenSchultz!

The bitrate=XXX does not match XXX warning should be ok on startup as we wait for the camera to match the requested bitrate, it should however eventually settle once it changes to the desired bitrate.

It seems like wyze might be removing the ability to get the bitrate value from the camera on the latest firmware releases..?

Could you try http://xxxxx:5000/api/cam-name/device_setting in the latest edge build? This attempts to get the camera values from the cloud instead of the camera.

If that doesn't work, then we might just have to ignore the bitrate value entirely.

WarrenSchultz commented 4 months ago

Thanks for the feedback @letrain02 @WarrenSchultz!

The bitrate=XXX does not match XXX warning should be ok on startup as we wait for the camera to match the requested bitrate, it should however eventually settle once it changes to the desired bitrate.

It seems like wyze might be removing the ability to get the bitrate value from the camera on the latest firmware releases..?

Could you try http://xxxxx:5000/api/cam-name/device_setting in the latest edge build? This attempts to get the camera values from the cloud instead of the camera.

If that doesn't work, then we might just have to ignore the bitrate value entirely.

If I understood properly, I accessed that URL, which returned the following.

{
    "response": {
        "1": "1",
        "2": "3",
        "3": "120",
        "4": "1",
        "5": "20",
        "6": "1",
        "7": "1",
        "8": "1",
        "9": "1",
        "10": "1",
        "11": "2",
        "12": "1",
        "13": "1",
        "14": "5",
        "15": "2",
        "16": "5",
        "17": "2",
        "18": "2",
        "19": "0",
        "20": "1440",
        "21": "1",
        "22": "-4",
        "23": "124",
        "24": "122",
        "25": "1",
        "26": "1",
        "27": "2",
        "28": "2",
        "29": "0",
        "30": "0",
        "31": "100",
        "32": "100",
        "33": "1",
        "34": "-1",
        "35": "-1",
        "36": "0",
        "37": "0",
        "38": "0",
        "39": "0",
        "40": "0",
        "41": "0",
        "42": "0",
        "43": "0",
        "44": "0",
        "45": "1",
        "46": "30",
        "47": "2",
        "48": "50",
        "49": "2",
        "50": "1",
        "51": "1",
        "52": "1438",
        "53": "8566",
        "54": "1",
        "55": "255",
        "56": "300",
        "57": "0",
        "58": "2",
        "59": "1",
        "60": "0",
        "61": "65024",
        "62": "65280",
        "63": "65408",
        "64": "65504",
        "65": "65520",
        "66": "65528",
        "67": "65532",
        "68": "65534",
        "69": "65535",
        "F2": "1",
        "F3": "1",
        "F4": "1"
    },
    "status": "success"
}

This was the result in the console:

wyze-bridge  | [garage-entry] bitrate=108 does not match 180
wyze-bridge  | [garage-entry] Requesting frame_size=0, bitrate=180, fps=0
wyze-bridge  | [WyzeBridge] [CONTROL] ☁️ get_device_Info for garage-entry via Wyze API
wyze-bridge  | [WyzeBridge] 192.168.xxxxxx - - [07/Jul/2024 22:04:39] "GET /api/garage-entry/device_setting HTTP/1.1" 200 -
wyze-bridge  | [WyzeBridge] [CONTROL] ☁️ get_device_Info for garage-entry via Wyze API
wyze-bridge  | [WyzeBridge] 192.168.xxxxxx - - [07/Jul/2024 22:04:43] "GET /api/garage-entry/device_setting HTTP/1.1" 200 -
wyze-bridge  | [garage-entry] bitrate=108 does not match 180
wyze-bridge  | [garage-entry] Requesting frame_size=0, bitrate=180, fps=0
wyze-bridge  | [garage-entry] bitrate=108 does not match 180
wyze-bridge  | [garage-entry] Requesting frame_size=0, bitrate=180, fps=0
mrlt8 commented 4 months ago

Thanks @WarrenSchultz "3": "120" and "46": "30" represent the high and low bitrate values (#825) however, the result looks to be the same as param_info values directly from the camera.

Still looking to see if might be some issue decoding the responses from the camera.

WarrenSchultz commented 4 months ago

@mrlt8 Thinking further about this, since I did see a different version of that error on an earlier firmware during the upgrade process for the new cam, I'm wondering if it's some weird regex wonkiness going on with certain combinations of characters/values/etc.

letrain02 commented 4 months ago

update from me. i moved some wifi nodes around, changed wyze-bridge to HD60, had a few mismatch errors at first, but letting it run all night (ondemand=false), and no errors, the logs are incredibly quite. not sure if it just didn't like SD30, or if it was just a wifi issue (too many collisions on 2.4ghz)...

i have have some superslow warnings occasionally and my pano-v2 drops, and then complains. [pano] [CONTROL] ERROR - error='[-20010] AV_ER_INVALID_SID', cmd='_bitrate'

its most likely wifi for that as i moved some things around.

mrlt8 commented 4 months ago

Any improvement with adjusting the bitrate value on v2.9.12? Note: the actual bitrate response will not change since the camera doesn't seem to return the correct value.

WarrenSchultz commented 4 months ago

@mrlt8 It says it's pulling 180 when initializing, but the log continues to show the warning. Just for grins, I submitted a beta feedback note about it. Don't know if we'll see any response, but doesn't hurt since it's obviously intentional to have 108 vs 180 if it's a code issue on their side. (And if a firmware bug, may actually be causing them issues too.)

image

mrlt8 commented 4 months ago

@WarrenSchultz could you try the edge branch to see if that gets rid of the log spam?

WarrenSchultz commented 4 months ago

@mrlt8 Yup, log spam is gone. Oddly, Frigate is getting 401 errors trying to pull from the cameras now though. Haven't had time to dig into why that would be.

WarrenSchultz commented 4 months ago

@mrlt8 Ah, fixed in the latest code. Some of the auth stuff changed I see.

WarrenSchultz commented 4 months ago

So to go back to the other part of the OP's issue, the "super slow" reports are odd, given the high wifi signal strength. What is the metric used to issue that warning?

wyze-bridge  | [v3testnew] 📡 Getting 180kb/s HD stream (H264/15fps) via LAN mode (WiFi: 95%) FW: 4.36.11.8391 🔒
wyze-bridge  | [v3testnew] WARNING: Skipping wrong frame_size at start of stream [frame_size=1]
wyze-bridge  | [WyzeBridge] ✅ '/v3testnew stream is UP! (3/3)
wyze-bridge  | [WyzeBridge] 📖 New client reading from v3testnew
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [v3testnew] WARNING: clear buffer
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [back-deck-cam] [video] super slow
wyze-bridge  | [back-deck-cam] WARNING: clear buffer
wyze-bridge  | [back-deck-cam] [video] super slow
wyze-bridge  | [back-deck-cam] [video] super slow
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [back-deck-cam] [video] super slow
wyze-bridge  | [back-deck-cam] [video] super slow
wyze-bridge  | [perroscope] [video] super slow
wyze-bridge  | [garage-entry] [video] super slow
wyze-bridge  | [WyzeBridge] 📕 Client stopped reading from back-deck-cam
wyze-bridge  | [back-deck-cam] [Exception] Did not receive a frame for 20s
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [WyzeBridge] ❌ '/back-deck-cam' stream is down
wyze-bridge  | [WyzeBridge] 🎉 Connecting to WyzeCam V3 - Back Deck Cam on 192.168.200.64
wyze-bridge  | [back-deck-cam] 📡 Getting 180kb/s HD stream (H264/15fps) via LAN mode (WiFi: 85%) FW: 4.36.13.0416 🔒
wyze-bridge  | [back-deck-cam] WARNING: Skipping wrong frame_size at start of stream [frame_size=1]
wyze-bridge  | [WyzeBridge] ✅ '/back-deck-cam stream is UP! (3/3)
wyze-bridge  | [WyzeBridge] 📖 New client reading from back-deck-cam
wyze-bridge  | [WyzeBridge] 📕 Client stopped reading from v3testnew
wyze-bridge  | [WyzeBridge] 📖 New client reading from v3testnew
wyze-bridge  | [back-deck-cam] [video] super slow
wyze-bridge  | [back-deck-cam] WARNING: clear buffer
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [back-deck-cam] [video] super slow
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [back-deck-cam] [video] super slow
wyze-bridge  | [back-deck-cam] [video] super slow
wyze-bridge  | [WyzeBridge] 📕 Client stopped reading from back-deck-cam
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [WyzeBridge] 📖 New client reading from back-deck-cam
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [back-deck-cam] [video] super slow
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [v3testnew] [video] super slow
wyze-bridge  | [v3testnew] [video] super slow
mrlt8 commented 4 months ago

The timestamp returned with each video frame is drifting behind the current time on the bridge.

Is it worse on the latest version?

WarrenSchultz commented 4 months ago

Had some power flickers last night, it's possible that something was up with the wireless after all that. I've restarted APs and the camera to see how it behaves, and so far I'm not seeing the message.