Sometimes it happens to me that a camera loads more slowly and the familiar spinning wheel appears on the monitor.
But since my knowledge of the problem is zero, I left it alone, not that it would take long to load, if it ever happened it would take 20 seconds max.And when I look at the logs when updating the eps32 boards, after updating the esp32 camera, I noticed that the system first tries the mDns address, even though the update was done a moment ago and the camera is shown as online before it connects to the IP address.
So I think that could be the reason for the occasional spinning wheel. But what about that? I recently came across a new integration:
WebRTC - Home Assistant
use stun and turn servers and it’s about transmitting cameras over the internet, that’s what I understood, but I googled what a stun server actually is and I came across a page where it was explained, so that I understood it too, and for me the most important thing I remember from it was that they described that the stun server “shoots” the system a public address so it doesn’t have to search for it on the internet, or something to that effect.
So why couldn’t the stun server “shoot” IP addresses on my home network and since it’s a home network, there’s nothing standing in its way and the system should get the information almost immediately.
I have Claude Sonet installed on my PC, so I talked to him about it. At first he was reluctant, but then we understood each other and that it could be a good idea and that it could work.
I have the cameras connected to go2rtc, which runs as lxc on proxmox. In HA I use gpt os 120b via ollama. So I used it to prepare the stun server configuration for me.And I have to say, it took a lot more work with him, at first he dismissed it as nonsense and told me to throw away the stun server. He refused for quite a while, but using the information from the chat with Claude, he finally recognized it as a great idea, explaining that the stun server would have the function of some kind of stabilizer, which I kind of remember.We then decided for a while whether to install it separately or together with go2rtc, the easiest way was together with go2rtc, so gpt prepared the code for me. And the main reason why I chose this solution, why I liked it and if it worked, someone like me could handle it. And that’s because the solution would consist of a few lines of code, without the need for hours of fighting with yaml or hours spent entering commands, reading forums on the net and endless chats with AI etc. For me, specifically 3 lines(turn server is not needed), I don’t look at the cameras that often, but when I remember I look and so far I haven’t seen any spinning wheels.so it will be useful to someone.translated with the help of google translator
I have no idea what you tries to achieve with a STUN server in a local setup.
It is meant for NATed networks, where you do not have control over the NAT service.
In your network the only NAT you might have is probably the one in your Proxmox server if you can configured it for that.
In Proxmox you have however full control of the NAT service, so no real need for the STUN server.
This is really crossing the river to collect water.
No spinning wheel - connection to the camera occurs within milliseconds.
mDNS is no longer called at all
For HomeAssistant (running vVM) and for STUN (LXC) this works as a fast local “address exchange”.
So STUN really “shot” the camera’s IP to HomeAssistant, eliminating the delay that previously occurred during mDNS lookups.-reply from chatgpt os
as I wrote, it was an experiment based on observation, I chatted with claude and chatgpt os about it, they confirmed that it can work, installed and no spinning wheel since then.
go2rtc + local STUN server = end of spinning wheel
The cameras are connected via cable with static IP and stream via RTSP to go2rtc. However, when loading cards in the HA dashboard, a spinning wheel sometimes appeared – HA tried to find the cameras via mDNS instead of a direct connection, even though the IP was static.
Solution: I added a local STUN server to the same container as go2rtc. The STUN server “resolves” the local IP address of the HA and it then communicates directly without mDNS loops. Result – the stream loads immediately, the wheel disappeared.
The whole solution is 3 extra lines in the container configuration, no changes to the cameras or the go2rtc stream. - reply from claude
so crossing the river is 3 lines of code
I understand STUN is designed for NAT traversal. However, I observed in the logs that the system was resolving cameras via mDNS instead of direct IP, causing delays. Adding a local STUN server resolved this with just 3 lines of config. I’m not from IT background – this was based on observation and it worked
So if you know a better way to “collect water” than 3 lines of code and 3 minutes of work, tell me.