2-way audio (webrtc) for TAPO stops working after a short while

[Eastravel]

The audio stream to the camera stops working after some time (1 minute or so).

• I start a stream without the microphone
• I start a stream with the microphone. And it works fine and will keep working until this window is closed.
• I close the stream with the microphone
• I start another stream with the microphone more than one minute later. No audio is sent to the camera.
• I close all streams from the producer. Causing the producer to close down.
• Repeat

So it seems like the producer stops functioning correctly (2-way audio) after the stream without microphone has been open for some time.

I have used the webrtc.html builtin page.
log.txt

Log enclosed.

[Eastravel]

Done a bit more debugging.

It seems as if only the first video+audio+microphone connection to the camera is working after the tapo producer is started.

So if I close the video+audio+microphone window, but keeps the video+audio window running, the next time I open the video+audio+microphone window, the microphone (from browser to camera) will not work. (Unless I reopen before the stream is cancelled)

Still if I close all windows and wait until the producer is closed, it will work again.

I also found this TODO in the code, that might be related :)

pkg/tapo/client.go:118 "/ TODO: fix closing connection"

Any help will be highly appreciated :) And let me know, if I can do anything to help

[AlexxIT]

Can check in two weeks

[Eastravel]

Did you get a chance to check it?

Let me know if I can help.

[AlexxIT]

This source in the process of rewriting

[AlexxIT]

It was rewritten in the latest master version

[Eastravel]

Absolutely great, thanks Alex

I have tested in the docker container - and will test on the pi-server in a few days.

[Eastravel]

Hi again, Alex

I have tried with the Pi server now - and unfortunately gets the exact same problem as before. It works fine the first time, but when I try again after the stream (consumer) is closed, it stops working. The logs are a little bit different:

I don't understand where it gets the IP address 192.168.8.21 and 192.168.8.22. The subnet 192.168.8 is not in the config. It might be an old configuration, as I have used this subnet before.

I have tested it in the docker version (1.6.2), which worked. So it is an option to switch from the Pi to a linux server running docker, if you think that is a more viable solution.

Thanks in advance.

[Eastravel]

I will try to run it on a Linux server with Docker instead and get back with the result.

Thanks.

[Eastravel]

Works much better on Docker :)

Thanks.

[leaskovski]

I am seeing this exact same problem, and logged an issue with the Frigate guys as I noticed this there, blakeblackshear/frigate#14066

Whats the best way to debug this issue @Eastravel / @AlexxIT

[AlexxIT]

@leaskovski If two way works at first, but when reopening it doesn't work - it's better to open a separate issue