Fix slow missing events check

[DobbyAHouseElf]

The purge events were taking 24 seconds to complete for each event. This is strange due to the actual purge command taking around 2 seconds.

The issue is due to the missing events loop taking 23 seconds to complete. The next purge event can't start while this is still active. Moving the sets combination from the if statement to outside the loop reduces this to 0.05 seconds which allows purge events to run on time.

This also reduces the total runtime for the missing events checker on my Raspberry Pi from 55 mins to 2 mins and 36 seconds.

[ep1cman]

Wow that's a huge improvement, nice one

[marvin-k3]

This made a huge improvement for me, the process was consistently using a full core. Thank you!

But now that this isn't a bottleneck, I find that my unifi console is unresponsive and goes offline, so maybe there needs to be some backoff of ratelimiting of the API?

[DobbyAHouseElf]

This made a huge improvement for me, the process was consistently using a full core. Thank you!

But now that this isn't a bottleneck, I find that my unifi console is unresponsive and goes offline, so maybe there needs to be some backoff of ratelimiting of the API?

Are there any items in your download queue when the console goes offline or is it just the missing events checker running at that time?
I used to have a lot of lag and crashes when i had the heatmap feature enabled but i didn't use it so turned it off. Since then, i have had no crashes.
My RCLONE_RETENTION is set to 120d and MISSING_RANGE is 20d so it might be different if you have more events that are being searched.
I am also currently running this pull request so i am generally only looking at the last 5-10 mins of missing events but i can switch to main if that will help investigate.

[ep1cman]

In regards to that other PR, apologies for not figuring that all out, been busy the past few weeks

[marvin-k3]

Sorry to leave a complaint and then disappear.

I now think this change is unrelated to what I've been experiencing. I went back to the 0.14.0 version and I'm still experiencing issues around the missing event detection. So presumably something on my side. I did semi recently introduce 2 new 4k cameras to my existing 2K*6.

I'll continue to investigate and play around. I'll also try that other PR for reduce the span at which missing event detection runs.

Heatmaps is interesting! I've disabled them because I don't need them, what do you think the connection might be? Or is just that they are resource intensive in their own.

(And sorry if this is cluttering the discussion, happy to move it to somewhere else)

[DobbyAHouseElf]

The information for heatmaps says it is resource intensive and i don't think it is worth keeping the feature on unless you need it. Turning it off did resolve my crashing issues but i also have filled the camera capacity.

If you would like to use the other pull request, i pushed another commit which fixes an issue with missed events when the downloader fails and makes the failures happen less often. I didn't originally push it because that pull request won't actually be merged. It does work but the final solution will be quite different.

[marvin-k3]

Thanks!

I've disabled heatmaps and have been`` running with pr221 for 12 hours and everything is snappy and unifi-protect-backup is using little cpu.

- RCLONE_RETENTION=10y
- EXPERIMENTAL_DOWNLOADER=true
- PURGE_INTERVAL=10y
- MISSING_RANGE=7d

Not sure I still need the experimental downloader.

[ep1cman]

At some point could you try enabling the heat maps again and see how it behaves while running the PR. I'd like to know if it's UPB that's causing issues

[marvin-k3]

Good idea, I've reenabled it and have been running a few different scenarios over the last few days.

I'll report back with what caused problems / what didn't.

[marvin-k3]

Ok, I've been having trouble reproducing the problem, but here's the state change so far. I thought I'd share so you can suggest things to try / things to include in my table.

"local" is when I built locally from github with pr222 included. pr221 is when I built from the #222 branch.

Everything since 2025-08-20 08:53:00 has been smooth sailing. Maybe the heatmaps are now very small?

For some reason I had automatic archiving from the unifi side to a smaba server turned on for two cameras. I don't need it, but I tried turning it off at the same time I turned off heatmaps.

	Change	Container	missing_range	use_experimental_downloader	Heatmap	Archiving
Initial State					TRUE	TRUE
2025-08-20 04:40:54	Docker	:latest	not in log	TRUE
2025-08-20 04:41:00	Protect Restarted
2025-08-20 05:32:00	Protect Restarted
2025-08-20 06:01:00	Protect Restarted
2025-08-20 07:22:00	Protect Restarted
2025-08-20 07:51:00	Protect Restarted
2025-08-20 08:53:00	Disabled Heatmap				FALSE	FALSE
2025-08-20 21:53:14	Docker	pr221	relativedelta(days=+7)	TRUE
2025-08-22 05:52:00	Re-enabled Heatmap				TRUE	TRUE
2025-08-22 09:02:10	Docker	pr221	relativedelta(days=+7)	TRUE
2025-08-22 11:07:16	Docker	pr221	relativedelta(days=+7)	TRUE
2025-08-22 12:22:31	Docker	:latest	not in log	TRUE
2025-08-22 13:10:56	Docker	local	relativedelta(days=+7)	TRUE
2025-08-25 08:59:09	Docker	local	relativedelta(years=+10)	TRUE
2025-08-25 12:07:37	Docker	local	relativedelta(years=+10)	FALSE
2025-08-25 13:52:40	Docker	:latest	not in log	FALSE

[marvin-k3]

Sorry! I think this has nothing to do with unifi-protect-backup but with another application I've been developing that reads from the unifi protect RTSP streams. I forgot!

After looking at other logs around the time things weren't going well, I see a that there were a lot of cycles of my personal application connecting/reconnecting as I was developing. I haven't worked on it since the 20th and that's why things have been working well!

I'll probably setup go2rtc or something to produce less load on unifi protect.