Open trvrnrth opened 1 month ago
I had a bit of time to do some local debugging of this and realised I'd not provided my stream config in the issue above:
streams:
front_door:
- nest:?client_id=REDACTED&client_secret=REDACTED&device_id=REDACTED&project_id=REDACTED&refresh_token=REDACTED
- "ffmpeg:front_door#audio=aac
The testing I've done suggests that the fixed 5 second retry I'm seeing stems from the ffmpeg audio transcode I have in place so I am currently testing with a 60 second timeout as follows to see if this helps:
- "ffmpeg:front_door#audio=aac#input=-fflags nobuffer -flags low_delay -timeout 60000000 -user_agent go2rtc/ffmpeg -rtsp_flags prefer_tcp -i {input}"
Did this ever get resolved? I'm trying this inn the go2rtc addon in the frigate docker container and can't seem to get my nest cam working?
Adjusting the timeouts (in both the ffmpeg transcode and also externally in frigate) mitigates the 429 rate limiting, however I am still seeing the stream getting stuck receiving 409 responses (now at 60 second intervals).
At this time I can replicate the responses in the Device Access Sample App as follows:
{
"error": {
"code": 409,
"message": "Failed to retrieve answer SDP due to timeout, please try again.",
"status": "ABORTED"
}
}
Restarting appears to be sufficient to resolve whatever the underlying issue is, although on my last restart I did see a single 409 response before the stream started working again.
@AlexxIT may I know that if I want to add this exponential backoff ability, or maybe even restart the nest subscription, which file should I start looking into?
I have a nest hello gen 1 wired doorbell source which, after some time experiences a 409 response:
It appears that there is no back-off on attempts to re-connect so these are then rate-limited:
The full error message grabbed from the Device Access Sample App at this time is:
At this point a restart is not sufficient to re-connect. go2rtc must be stopped for some time to allow the rate limit to "clear" before being started again (in my case this is a case of manually stopping, waiting a few minutes then starting the HA Frigate add-on).
I am unclear what causes the initial 409 conflict response, but implementing a back-off on at least the 429 response would be good. I guess it might make sense to just back-off on any error which would lessen the chance of hitting the rate limit in the first place.
Here is a full extract from the logs at the time of last failure: