Memory is here very bad as well since installation.
On my machine (intel nuc, haos) i also experience gradual ram consumption rising over time. But this is always solved by restarting core machine - not just HA restart, but HAOS, VMā¦ wherever HA runs on.
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.
1 Like
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.
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.
2 Likes