Storage Webpage should list quantity of footage stored in days

[tearfulnumpty]

Describe what you are trying to accomplish and why in non technical terms
I want to be able to view how many days of recordings I currently have in the UI page here: https://frigate.endpoint/system#storage

Currently, the UI shows the amount of data stored in terms of bytes, eg: Raw data sizes (GiB); Percentage of Total Used; and Bandwidth averages of data per hour. It also shows a total recording data size. This is all fantastic, but:

Describe the solution you'd like
The solution I'd like is for this same webpage to also show the value of the oldest storage in days. This is particularly useful for continuous recording environments, so I can see at a glimpse, "I have 17 days of recording storage." This is helpful for fine tuning config retention values.

Describe alternatives you've considered
Alternatives would be to manually inspect the dates in the filesystem structure.

Additional context
Low priority I guess, but it seems like it'd be very nice to have.

[NickM-27]

How do you quantify what a day of storage is? What if you have 30 days of event retention and 30 days ago you have a 1 minute clip for the whole day, does that mean you have 30 days of recordings?

I can see if you strictly have continuous recording how it would be useful but in general that is a very rare use case for frigate

[tearfulnumpty]

I don't think it really matters how you define a day of storage. That level of precision is way beyond the point of this view. I'd simply do it by looking in the past 24 hours = 1 day, 48 hours = 2 days, etc without considering performance or difficulty. If you have 24 hours and zero minutes of recordings, that'd be one day.

I think any other method would also be fine if it was substantially easier to setup or more performant, as that level of precision is not required. A simple date check and taking the difference between current and oldest would also be fine. It'll be within roughly a day of accuracy and that is plenty accurate.

If precision is really a concern, then add the hours and minutes with it. Or, just add a stipulation in the web page that it is approximate via ~ or even explicit words. If nothing else, the simple date of oldest recording per camera could be added and the user can calculate it themself (but I think that'd be leaving a simple feature on the table personally).

---

Continuous recording is a valid use case regardless of if people use it or not. I've had a robber identified and arrested purely because of continuous recording from information that wasn't present in the events themselves. It is kind of hard to imagine the dismissal of 24/7 recording as a best practice for serious security, even if Frigate does a great job of event detection.

It's a useful feature regardless of the validity of continuous recording.

In the case of event-only recording, it's still a useful piece of information to have, for the same reasons as in continuous recording. You get a sanity check of where your config throws your storage, and you have a great at-a-glance view of your system. "I configured this to store events for 10 days. Does the actual retention reflect that, or not? Can I expand my config retention value, or should I get more storage?" It makes that analysis at a glance really simple and goes with the explicit purpose of the rest of the page.

[NickM-27]

I think you are kind of missing my point.

If you have 24 hours and zero minutes of recordings, that'd be one day.

Sure, but for a user that only has event based recordings, if they had an hour worth of recordings each day for 24 days then given the logic you have defined the UI would say that the user has 1 day of recording, but that could very well be confusing to the user and also I'm not sure how useful that would be.

It is kind of hard to imagine the dismissal of 24/7 recording as a best practice for serious security, even if Frigate does a great job of event detection.

Sure, I use it too, but regardless whether it is used or if event based storage is used as well changes the meaning of "X days of recordings"

I configured this to store events for 10 days. Does the actual retention reflect that, or not?

concepts are being mixed here. In your first example you talk about showing days as a cumulative amount of total recording time. But in this example 10 days of event based recording does not record continuously so the UI would not show 10 days of recordings saved, which would make the user think the config was not working even though it was.

[tearfulnumpty]

Sure, but for a user that only has event based recordings, if they had an hour worth of recordings each day for 24 days then given the logic you have defined the UI would say that the user has 1 day of recording, but that could very well be confusing to the user and also I'm not sure how useful that would be.

No, not at all. By the logic I defined, that would be 24 days of footage.

Sure, I use it too, but regardless whether it is used or if event based storage is used as well changes the meaning of "X days of recordings"

I don't think so. You have the same exact problem with the current event retention field, right? It doesn't calculate it in terms of literal days of footage, as in computing: 12 hours Monday + 12 hours Tuesday + 12 hours Wednesday + 12 hours Thursday = 2 days, right? That would span 4 days time. I can't imagine that's how it currently works, the relevant factor for the retention config value relates to how many real world days the user wants to keep the footage around for, surely.

concepts are being mixed here. In your first example you talk about showing days as a cumulative amount of total recording time. But in this example 10 days of event based recording does not record continuously so the UI would not show 10 days of recordings saved, which would make the user think the config was not working even though it was.

Well no, in my first example I don't intend for Frigate to tally each database entry up to get a total amount of time. I would mean for it to lookup the oldest record it has, and compute a difference from now to then, whatever that method looks like.

In the events based recording, I would expect it to work just like the config works, and show the retention of oldest videos. Unless I'm mistaken about how the config event retention value works, but I cannot possibly imagine it working any different from how I've described.

In any case, posting the date of the oldest video in the database would remove all ambiguity.