Difficulty with sync_recordings and DB errors

[ediguidedog]

I'm having a bit of a clean up on my test box running V14.0 and I've deleted a few days worth of recordings (20GB or so) from the Media/recordings/folder.
I've also added sync_recordings: True into the config file and restarted.

The storage page is still showing the space as occupied and the logs show the following two entries

Deleting 11143 recording DB entries with missing files
Deleting 0.771089% of recordings DB entries, could be due to configuration error. Aborting...

Apart from that it's all working and new events are being created and I can manually delete them from the GUI.
IS this a known issue?

Update: I tried the same on another copy I have that was built from scratch (as opposed from being migrated from v12) and it works fine. The new working version was created with exactly the same dockercompose.yaml file and config.yml taken from the failing one. Leading me to believe both files are OK. Destroying and recreating the failing docker container makes no difference and it still gives the same errors on startup. It's really not that important and I'm happy to trash the whole thing and recreate as it seems to be an oddity with my DB but just wondered if its something you want to investigate.

Update2:
I think it's something to do with the number of deletions required. When I earlier said it worked on the other system that was when I deleted a few hundred files. I went back and deleted a similar number to my test box (10K plus) and I got the same error there

[NickM-27]

Right, exactly as the error says there are too many recordings so it is not safe for Frigate to delete them. Honestly why not just delete everything including the DB to start over?

[ediguidedog]

Thanks but I'm not sure the error does convey that. What it tells me is it tried to delete 11K recordings, then fell over after 0.71% and failed likely due to a configuration error.

I'm not questioning the rational behind the failure to delete just that an error message informing that this is intended behaviour would be better option. Or should the 0.771089% actually be 77.89% of all recordings and its trying to tell me deleting such a large percentage of my recordings is such an odd request that it's not going to do it? Either way I think it could be less ambiguous .

[NickM-27]

Deleting 0.771089% of recordings DB entries, could be due to configuration error. Aborting...

Yes it should be 77%, at the end it says aborting which means nothing was done.

[ediguidedog]

Thanks again. Of course I could trash and rebuild but I was just trying to free up a few GB on my test box so just deleted a few days worth

It is ambiguous though so how about changing

Deleting 0.771089% of recordings DB entries, could be due to configuration error. Aborting...
to
Deleting 77.1089% of recordings DB entries? This percentage could be due to a configuration error so aborting...

The problem is is by the time you get the message the damage is done and there is likely no way back so will these db records naturally clean themselves as the retain values are reached? If not then probably worth suggesting only way out is a db delete and restart

[NickM-27]

yes, the retention will still delete the DB entries.

[ediguidedog]

Brill thanks again for the fast responses