I solved my issue by making sure WebRTC (not just Go2RTC) is enabled in Frigate itself AND under the Frigate integration options.
It seems the old fallback to HLS no longer works, so if you don’t have WebRTC enabled, you get a static image.
I’ve posted some scenarios where you might still need the go2rtc addon or WebRTC custom integration:
7 Likes
Am unable to update past 2024.10.4. Have tried through the UI and terminal. Each time, there is some time, home assistant restarts and the version remains on 20.10.4.
Seeking help as I have never ran into an issue with an update in 4+ years.
Logs.
Is this really works as designed? To not compare apples with pears (in the last chart were mid statisticts in the history and real data in the last 7 days), here a chart with only long term statistic data (max per hour) for the last 30 days.
The memory consumption was really stable and always below 50%, was happend after installing 2024.11 is quite obvious. Really jumping and twice as much as before.
Can I see some more details, what and why is allocating all the memory? And is this now wanted/planned or why this is happening.
see this
1 Like
Thanks. But currently I don’t have restarts and no memory leak (in terms of rising over time), but more general twice as much memory usage as before (in 2024.6).
I feel, that the system (at least UI) is slower as before, but not in term of a big problem.
I’m on HA Blue. Is such doubling of memory usage and behavior as in screenshot normal in 2024.11 or not the standard?
It depends on the integrations you’re using… Memory is used by what’s loaded. Follow the guide and see what’s eating up the memory.
I had a similar problem back around 2024.4.x or 2024.5.x. My memory utilization went from below 50% to over 80%. I’ve gotten it back down to around 70% after deleting a few things, but by far the biggest user is the “homeassistant” container, so it’s hard to blame other components.
I suspect that development is generally done on higher-end hardware, and memory utilization isn’t really noticed. It’s hard to think of details like that when you’re coding in a high-level language and using a lot of third-party packages. Note all the times a change in the release notes is little more than the word “bump” for some package. Apparently even the developer didn’t know what really changed down at the hardware level.
It’s very easy to blame components when you can find out which one is causing the problem by following the guide I posted above. The home assistant container houses all of home assistant and the integrations. Find out what integration is causing the memory bump and create an issue or remove the integration. HA core is unlikely causing this problem, otherwise bdraco would have found and fixed it. If the problem really is core, then the guide listed above will show that and an issue can be created. And bdraco will likely fix it.
The point I’m making is: Making claims like this in the release thread is pointless because it tells us nothing. We need to know what’s causing the problem in order to fix it. Saying “HA uses more memory after the last update” is as helpful as a strainer at catching water.
2 Likes
No, it isn’t. It was only a starting point and question form me. Let’s assume the answer would be “yes, works as designed, starting with 2024.11 we are allocating more memory as before because of good reasons”.
Don’t expect always the blaming or bad in valid questions.
2 Likes
Sorry, I disagree. The release blog would have mentioned optimizations.
Like I said earlier, we know what causing the memory leak: Go2Rtc.
By transferring the server part to the add-on, the memory leak is transferred as well which is easier to restart every few hours than core. (with an automation)
The memory leak issue in Go2Rtc is an old known problem but because it has been included in core, the issue appears now in core…
Unfortunately we can’t help because there is nothing in the log.
The only thing I noticed is that it appears when there is a stream nor closed in the server, the server is then dead for this cam. I also noticed that, in my case, this “locked” stream occurs only on my Reolink cameras.
1 Like
Please look at the post I linked, it shows you how to identify what integration is causing the leak. That is how you help. There will not be anything in the logs.
2 Likes
What’s missing here is that it depends on your specific setup. That’s why the generalisation isn’t helpful. There are 4 official installation methods with who knows how many variations on that. If HA was just a single application that was identical for everybody, maybe then it would be OK to state just that. Either way, Petro provided the guide to debug this.
4 Likes
I am wondering the same thing… Did you find an answer?
if you’re using Frigate for your camera’s then you can delete the go2rtc addon as it is backed into frigate.
1 Like
Resolved the issue, here’s some info in case anyone runs into something similar.
Thought it was a proxy issue, like go2rtc couldn’t make it past my Traefik internal proxy. Turns out RTSP was turned off on the Unifi Protect integration. After enabling this the streams could then be seen in HA but they were using the slow HLS streaming method in Safari for MacOS.
Found that the cameras within Unifi Protect had Enhanced Encoding enabled which uses H.265 HEVC and for some reason the MacOS version of Safari could not use it. The HA mobile app on MacOS worked fine with HEVC but not Safari.
Changed the camera streams to use Standard encoding (H264 AVC) which provided the best compatibility and MacOS Safari worked fine.
3 Likes
Cleared cache.
This is all i see in the logs
2024-11-15 17:22:19.333 INFO (MainThread) [supervisor.docker.addon] Starting Docker add-on ghcr.io/allenporter/amd64-rtsp-to-web with version 1.4.0
First stopped RtsptoWebRtc from running.
Camera stream is laggy.
Started RtsptoWebRtc again, camera stream still very laggy.
This is not good !!
That looks like a custom addon, so what’s that addon doing?