Sometimes, P2P stream cannot be started

[fuatakgun]

Following on timeout discussion, opening new issue to discuss further p2p timeout.

Sometimes, when i call start_livestream to initiate p2p stream, client does not receive any livestream started event and further video data.

This is happening randomly and all cameras behave same and i checked with mobile app and cameras are accessible and streaming on demand through mobile app.

Getting all logs might be too much as it is happening randomly, do you have any advice to track this?

[bropat]

@fuatakgun

I looked in the source code to see how I had implemented this timeout (MAX_STREAM_DATA_WAIT). The timeout starts when the device/station receives the OK that the start livestream command was received correctly. Currently this timeout is set to 5 seconds, so if either a video/audio packet is not received within 5 seconds, the reception of the stream is interrupted and the following error message is displayed in the log:

Stopping the station stream for the device <serial>, because we haven't received any data for 5 seconds.

I can imagine the following problem:

1. start command of the livestream is sent
2. receiving the confirmation of the command from the device/station (timeout timer starts)
3. no stream data is received within 5 seconds. The reception of the stream is terminated by the timeout.
4. The stream data arrives after the 5 seconds and the client library drops it because no stream is running from its perspective.

This behaviour can only be seen with the complete debug logs.

Possible solutions:

• Increase the timeout
• When the timeout occurs, a stop livestream is also sent so that no data can arrive afterwards.

Any suggestions on your part?

Can you reproduce the problem systematically?

[fuatakgun]

Thanks for deep dive investigation, i will try to generate the issue systematically, so we can decrease possible log size to investigate. One possible option to change log level on demand, so i can enable debug when any further issue happens. Not sure if it is feasible though.

[bropat]

@fuatakgun

What do you think, should I increase the timeout or make it adjustable?

[fuatakgun]

I do not think it will help any further, I have switched to LAN connection today, I will keep you updated if this will happen further. There are others users reporting similar users, 5 seconds should be long enough to receive bytes. Under normal conditions, it is very fast.

[teamjpx]

I had an issue similar to this and when checking the logs I think it said it could not open the stream because the stream was already running. I waited a few minutes and then tried again and it worked.

It seems the issue was starting the stream but not capturing it at the moment, then HAss was not able to re-capture the stream and all I was doing was sending it the command to start it... MAYBE system freakout with too many requests? It has not happened again. If it does, I will try to get the logs and post.

[bropat]

@fuatakgun

Any news?

[fuatakgun]

I missed this, sorry guys, I will try to generate it locally this week and let you know.

[fuatakgun]

I sent the log files to your email address, please check after time 17:13, log is very huge, I did not want to remove any lines.

[bropat]

@fuatakgun

I never find a battery value of 0 in the log for any of the devices. For information: The internal Eufy parameter ID for the battery is 1101 (for both interfaces Cloud+P2P it can be found in the log through the parameter param_type). The normalised value is stored in the battery parameter. Both seem to have no 0 value on any device as of 17:13.

[fuatakgun]

Hey, this issue is about stream start timeout problem :-) i haven't had experience battery 0 issue on this log.

[bropat]

Sorry, my mistake :D

[bropat]

@fuatakgun

Found issue and fixed. Thanks for the logs ;)

Will be fixed in the next version.