Closed fuatakgun closed 2 years ago
@fuatakgun Is already present (look above):
retries: 1, <==== this is a counter; max retries = 10
So, it is retrying up to 10 and sending back the response whenever it can get a response, correct?
@fuatakgun Exactly.
@fuatakgun
I have now analysed the above error and the problem in this case is as follows:
The problem here could be that we get the answer after the above timeout or that the UDP packets get lost on the way. I can increase the timeout, but the higher the timeout, the longer we wait for an "internal" response of the command.
This timeout error also occurs from time to time with @rpitera, now that I am running tests with his environment. I am trying to understand where exactly the problem lies. I'm sure I'll have to do some network traces...
I am currently trying to replicate the problem. It does not always occur... It could be some race condition in the code...
@fuatakgun
One difference between the official app and my integration is that the app only sends one command at a time to the station, not several at once.
Example:
Perhaps the solution to the problem could be to run a send queue that is processed sequentially and only sends 1 command after the other, once the result (or the command times out) of the previous command has been received.
Perhaps the solution to the problem could be to run a send queue that is processed sequentially and only sends 1 command after the other, once the result (or the command times out) of the previous command has been received.
This makes a lot of sense to me. And btw, welcome back - hope you enjoyed your holiday!
@rpitera
And btw, welcome back - hope you enjoyed your holiday!
I enjoyed it very much. Maybe a little short, but better than nothing ;)
With the next version (1.2.0) that I would like to release today, I should have this problem under control :)
So have you determined the issue with having a number of cams connected to one homebase? Cause my older Arlo hub is starting to fail so I was considering replacing them with a couple of smaller Eufycams and that's a concern for me.
@rpitera
So have you determined the issue with having a number of cams connected to one homebase? Cause my older Arlo hub is starting to fail so I was considering replacing them with a couple of smaller Eufycams and that's a concern for me.
I have implemented the following which seems to solve the problem:
Perhaps the solution to the problem could be to run a send queue that is processed sequentially and only sends 1 command after the other
Please also check it yourself. If the problem occurs again, just give feedback here. If I don't hear anything after a few days, I will close this issue.
Thanks for taking the time to explain it; also thanks so much for the support and fix!
I guess I have to wait for @fuatakgun to implement the new code downstream, but as soon as he does I will test it and report back to you one way or the other. Again, my thanks.
i am not seeing this anymore, but sometimes p2p streaming just stuck and i am not able to start it without restarting docker instance. i call start p2p livestream and ws throws an error saying that 5 seconds left and nothing arrived. Not sure if we should investigate this separately or together with timeouts
i am not seeing this anymore, but sometimes p2p streaming just stuck and i am not able to start it without restarting docker instance. i call start p2p livestream and ws throws an error saying that 5 seconds left and nothing arrived. Not sure if we should investigate this separately or together with timeouts
@fuatakgun
This is a timeout I introduced if for some reason no more livestream data arrives to stop the stream internally. Without this timeout it can happen in some cases that the library still thinks that a stream is running even if it is not.
In short, this timeout has nothing to do with the other P2P timeout error ;)
it is clear @bropat , thanks. i will create a separate issue to discuss stuck p2p case.
Hi @bropat ,
Do you think, we can add a simple or exponential retrial mechanism into
eufy-security-client
? I have seen many warnings in docker output as below and retrial might help us to resolve this.