PSA: 2024.7 recorder problems

That doesn’t sound promising.

I installed 2024.7.2 and removed the workaround. Everything works fine for now.

Hoping it‘s fixed.

After installing update. These logs are after reboot with the workaround reintroduced…

1 Like

I am rebooting again, with auto_purge deleted from config
Now everything is starting, and as expected all missing data is shown in energy dashboard, all at once (all in one bar between 18:00 - 19:00). So, behaviour is as previously reported.

I want auto_purge turned off to avoid purging breaking recording at 4:00 hr… hmm

New reboot, now with auto_purge: false, has succeded…
Do not understand why the 19:55 reboot failed. But fingers crossed is keeps recording now…

Anyway, the original problem is not resolved. After isntalling 2024.7.2 the recorder does still stop recording…

Update: also with auto_purge: false the recorder did not seem to work… but I am not sure and I am not willing to risk further experiments.

I have done a rollback to 2024.7.1

not happy, and would like confirmation by other users that 2024.7.2 is fixing the issue

The database fix seems to have worked for me, but I have to wait and see if it survives the 4:11 purge…so far things are looking good and the logs confirm that the database fix was applied.

You didn’t specify, but what I read about your problem, it is “ISSUE 2” in the first post. The fix for this issue is in the upcoming 2024.8.0.

“ISSUE 1” was fixed by the latest 2024.7.2

Please see the solution post from @petro for more information. :slight_smile:

For what it is worth, 2024.7.2 seems to be working now and fixed the issue for me (unless it was something else I did). I assume I had issue 1 from the original post because I don’t run any of the mentioned integrations, but had the issue with middle of the night purge sending CPU high and locking the recorder.

I worked around the issue, by rolling back to 2024.6.4 which is a workaround, as my database would have grown too big without doing this when the assumption as that it would be fixed in 2024.8.

While normally I have the recorder set to keep 4 days of records, I did a manual recorder:purge to keep only 1 day and repacked the DB which brought its size down from 8Gb to about 3GB (in fact the recorder was probably only storing about 3 days of data at this time). I this took a bit less than half an hour. Of course this was all working on 2024.6.4.

Then I did an upgrade to 2024.7.2 and again manually ran a recorder:purge keeping only 1 day which seemed to complete without issues without hanging the recorder. So assume issue is fixed. It finished very quickly because I assume not much is being purged because I only just did it. In a few days when it is running over night and purging more, I will know for sure, but looks good.

Hope that is useful to others.

3 Likes

Thank you for your reply, I will wait for the 2024.8.0 update for now :slight_smile:

1 Like

Fixed it for me as well.

So far it seems fixed for me as well. No unusual CPUn or RAM useage, no missing history graph…
It was only one night and potential Purge so far, but at least as far as I can tell it’s OK now.

Everything is working fine after updating to 2027.7.2 :+1:

No data loss anymore!
Great work and thy for solving the problem!

It is apparently the issue 2 fix was in 2024.7.2.

Hi everyone…
For me, the problems started after updating to 2024.7.2.
Recorder stopped working after the update, and HA is no longer tracking any entity history. Even a restart doesn’t solve the issue, therefore I’m not sure if it’s the same problem as discussed in this thread.
Also, my database sizes more or less doubled after the update…

Any advise?

happened to me aswell! fortunatelly started working again after an hour or so,

it must have been doing some verrry important stuff in the background…

mindthegap

It has been 36h hours since it stopped logging history data
I don’t think that this is still normal :confused:

for me recording still stops at ~4:12 am, even with the 2024.7.2 update

Check the logs to make sure you didn’t run out of disk space or RAM during the table rebuild. If you did get close to running out of RAM, and the safeties kicked in, you’ll have to restart again to get the recorder up and running.

2024.7.3 will improve the safety check for systems with low RAM so it’s less likely another restart is needed. If your system isn’t resource constrained it won’t matter either way.

If you did run out of disk space, free up some space, restart, and it will try again.

6 Likes

On 2024.7.2 I experienced high memory usage (4GB at 97%) and elevated CPU usage (25%), along with slow full reboots taking 3 to 5 minutes. Additionally, the recorder still stopped functioning at 4.

I temporarily increased the memory to 8GB, and after a reboot, both memory and CPU usage returned to normal levels. Even after reducing the memory back to 4GB, the usage remained stable (4GB at 37% usage and CPU at 3%).

Still have to check if it survives a nightly purge.

Edit: no it didn’t survive a nightly purge, same result as before, high memory use, high cpu use and recorder stopped working.

1 Like

This happend to me aswell. Befor the update the recorder starts working again after a restart for a couple of hours.
No it stopped completly.

I would be grateful for your help

I’m sorry to say, that I still haven’t found a solution…
I think it might be a database issue… Filtering through the log for “recorder”, I get these entries: