[Support]: Frigate does not delete recording DB entries when it should

[andornaut]

Checklist

• I have updated to the latest available Frigate version.
• I have cleared the cache of my browser.
• I have tried a different browser to see if it is related to my browser.
• I have tried reproducing the issue in incognito mode to rule out problems with any third party extensions or plugins I have installed.

Describe the problem you are having

My mask/zones were not properly configured, and so Frigate saved way too many clips and recordings. I deleted excess clips and recordings, and restarted frigate.

Frigate didn't prune the corresponding records from the database.

WARNING : Deleting 0.636960% of recordings DB entries, could be due to configuration error. Aborting...

I understand that Frigate is trying to be defensive here, but I don't think it should. Alternatively, provide the user with some way of triggering the pruning manually.

(minor issue) The warning message should say "64%" not "0.636..%".

Steps to reproduce

1. I pruned the media directories

sudo find clips -type d -mtime +7 -delete
sudo find recordings -type d -mtime +7 -exec rm -rf "{}" \;

2. I restarted frigate docker restart frigate

Version

0.16.0 Release Candidate 4

In which browser(s) are you experiencing the issue with?

Mozilla Firefox 131.0b9

Frigate config file

n/a

docker-compose file or Docker CLI command

n/a

Relevant Frigate log output

2025-08-15 08:31:13.327834970  [2025-08-15 08:31:13] frigate.record.util            INFO    : Deleting 114398 recording DB entries with missing files
2025-08-15 08:31:13.336716389  [2025-08-15 08:31:13] frigate.record.util            WARNING : Deleting 0.636960% of recordings DB entries, could be due to configuration error. Aborting.

Relevant go2rtc log output

n/a

Operating system

Other Linux

Install method

Docker Compose

Network connection

Wired

Camera make and model

n/a

Screenshots of the Frigate UI's System metrics pages

n/a

Any other information that may be helpful

No response

[NickM-27]

I understand that Frigate is trying to be defensive here, but I don't think it should

It absolutely should, there are plenty of cases where a NAS isn't online when it should be, or any other number of situations that would lead to the entire DB being wiped if it did not work this way. There is no harm in these entries staying in the DB and they will be cleaned up naturally, or you can run a SQL command manually if that is preferred.

The warning you see

WARNING : Deleting 0.636960% of recordings DB entries, could be due to configuration error. Aborting...

is specifically for the sync_recordings feature. Frigate still runs its usual cleanup logic

[rolsch]

can you describe this hint: ...or you can run a SQL command manually if that is preferred.

[hawkeye217]

I understand that Frigate is trying to be defensive here, but I don't think it should.

This is not a bug, rather it is intentional behavior to prevent users who have misconfigured Frigate from losing a large number of their recordings. It's not something we want to change.

I will put up a fix for the decimal place issue.

We don't recommend manual pruning. The UI allows manual deletion of tracked objects from the Review and Explore pane. Recordings would then be automatically cleaned up by the recording maintainer.

[andornaut]

There is no harm in these entries staying in the DB [...]
The warning you see is specifically for the sync_recordings feature.

@NickM-27 I thought the sync recording feature's purpose was to delete DB records if the files don't exist on the disk. "Ask AI" on the docs site suggests I had the wrong idea:

The sync_recordings feature is designed as a safety mechanism to fix variations in files, not to completely delete the database3. It's meant to handle situations like missing volume mounts, partial drive failures, or configuration issues where some files are missing but data recovery is possible.

But, then there's this comment:

Its only purpose is to sync the recordings that are on the disk to the recordings database table

And the comment in the reference config:

Optional: Sync recordings with disk on startup and once a day (default: shown below).

I guess this feature doesn't work as I thought it did. Fair enough. What is it for, then? Is the "Ask AI" response correct? I think the comment in the reference doc should be updated accordingly.

[NickM-27]

@NickM-27 I thought the sync recording feature's purpose was to delete DB records if the files don't exist on the disk. "Ask AI" on the docs site suggests I had the wrong idea:

The feature does work both ways, the docs need to be updated a bit to reflect that. But it is only meant to handle slight differences like the case where a small % of files were deleted or perhaps something was missed and a file exists despite the DB entry being done (like if a NAS went offline unexpectedly).

[hawkeye217]

This is improved in #19525

[andornaut]

Ok, thanks! I appreciate the clarification. Feel free to close this discussion.