-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request - Configurable Retention By Size #9275
Comments
How would you expect it to work on the camera level? Imagine a scenario where you have:
camera 2 is fully utilized and camera 1 does has not had any events in a while so it has no storage used, does camera 2 get cleaned up even though the total pool would be 30GB? Furthermore, I think having a global option further confuses things because some users may think that the global option is a total for all cameras while that typically means each value applies to the camera. Personally, I think this would be a lot simpler to implement as a global option only where all cameras share the pool and the cameras with the most activity will naturally take more space. |
A global option with a shared pool for all cameras seems more useful and understandable |
The global option would be just fine, IMO. The route Blue Iris uses, is pretty simple to manage. You have "locations", and those locations have a size / retention / action specified. You can point different cameras/events/etc, at whichever location makes the most sense. You can also use this, to keep newer / more important events on faster storage, and use slower storage for archiving. Its not a perfect solution, but, works quite well. Also- on another note- You closed #994 with-
Any details on this? I literally just fixed my Frigate instance (running a newer 0.13 beta), because it was completely dead due to its data storage location being full on disk space. Since- it was unable to write to the location due to it being full, it instead, just went into a crash loop. |
Makes sense, I think time based retention will still be the primary metric but that may change over time.
without logs there is no way to know what specifically happened, the storage cleanup doesn't trigger until 5 minutes after frigate has started and every 5 minutes thereafter. We have many users using this setup (filling storage and only having frigate clear when storage is full) and many of these users have confirmed this feature in 0.13 as well |
a user also provided this image, which is pretty cool to see |
Nearly exactly what is in #994. However, since we cannot properly collaborate- my other ticket is completely locked, and completely inaccessible to me.
The request is simple. The ability to specify a retention by total space used.
Example-
And, making such a setting specifiable on individual cameras/events/etc.
The reason?
Because when you are only recording EVENTS, and the events occurs randomly at unknown intervals, it makes it extremely difficult to predict the amount of disk space required.
If you are recording everything, sure, you can estimate the amount of required storage, for a given number of days. However, when yo u are only interested in recording events, this is not exactly the case.
The text was updated successfully, but these errors were encountered: