Closed summitbri closed 6 months ago
Thanks for the kind words!
Hmm that is strange. There is a thread dedicated to cleaning this up, something might have caused it to stop. No indications in the log?
I guess some kind of double check would be in order to prevent this from happening.
Edit: The 1.8 beta has no extra features that would solve this so that probably wont do anything
I wasn't able to find any indications in the log. I just blew away the docker image and reloading, will see if I can reproduce the problem.
Just realised that i have the same issue running the new modulized v2, the segments folder just keeps getting bigger
EDIT: i think my config makes a camera never stop recording, so it's ''normal''.
Hmm odd, do you have more information? Any logs? Also what's your config?
Hmm odd, do you have more information? Any logs? Also what's your config?
My bad, it's related to my config, i have a camera that always record, so segment will never stop filling up. Would it be a good idea to have some MAX_RECORDING_LENGTH or something like that that would force a periodic output to to the recording folder to avoid such situations?
I see that trigger_recorder in object detection is defaulted to true (i expected it to be at false), so my front camera is always recording, there is always detectable objects up front.
EDIT: I added trigger_recorder:false on every label to stop the camera from recording and now the container size is stable!
Hmm odd, do you have more information? Any logs? Also what's your config?
My bad, it's related to my config, i have a camera that always record, so segment will never stop filling up. Would it be a good idea to have some MAX_RECORDING_LENGTH or something like that that would force a periodic output to to the recording folder to avoid such situations?
I see that trigger_recorder in object detection is defaulted to true (i expected it to be at false), so my front camera is always recording, there is always detectable objects up front.
EDIT: I added trigger_recorder:false on every label to stop the camera from recording and now the container size is stable!
Ahh i see. It's a bit of a hard problem to solve I think. You'd still eventually have a full disk of recordings instead.
But yeah a max recording time config option could be added, and maybe retention rules based on how much storage is left is a good idea?
Some warnings in the log could also be a good idea
Yes you're right that i would fill up recordings instead of segments this way. I think it's better because (usually) people will set recordings at some storage location that's expected to grow in size, while the segments folder is in the Docker container and those should not really hold that much data usually, that's what threw me off guard, the Docker warnings that the disk was full.
You could roll recordings like dashcam do, they erase the oldest footage when something new has to be written. So let's say I set a recorder property of MAX_RECORDINGS_FOLDER_SIZE=30GB, i could have a forever recording camera that would never use over 30GB.
So if we had both, a MAX_RECORDING_LENGTH (or size) and MAX_RECORDINGS_FOLDER_SIZE, you could have forever recordings camera without ever filling anything to full (segments or recordings).
But i agree that we are now in NVR territory, not sure if Viseron roadmap include to get deeper into the NVR feature set.
Yes you're right that i would fill up recordings instead of segments this way. I think it's better because (usually) people will set recordings at some storage location that's expected to grow in size, while the segments folder is in the Docker container and those should not really hold that much data usually, that's what threw me off guard, the Docker warnings that the disk was full.
You could roll recordings like dashcam do, they erase the oldest footage when something new has to be written. So let's say I set a recorder property of MAX_RECORDINGS_FOLDER_SIZE=30GB, i could have a forever recording camera that would never use over 30GB.
So if we had both, a MAX_RECORDING_LENGTH (or size) and MAX_RECORDINGS_FOLDER_SIZE, you could have forever recordings camera without ever filling anything to full (segments or recordings).
Makes sense! Will look into this when v2 is released.
But i agree that we are now in NVR territory, not sure if Viseron roadmap include to get deeper into the NVR feature set.
I want Viseron to be as good as it can be, NVR territory or not! If you have any other good feature recommendations i would love to hear them.
Sorry to bump an old thread but had this issue just there now. Viseron been working fine for ages and then all of a sudden, started filling up the /segments folder. I think its likely a config issues whereby theres so much motion that it cant stop the reocording and move it to where recordings are stored but still, would be good to stop it before it crashes the system of no space haha
This should not be an issue anymore actually if you run v3.0.0b5.
You can now retain recordings based on age or space used, and there is also a max_recording_time
configuration option that you can use to stop it from creating one massive recording!
Closing this for now, please feel free to open a new issue if you face similar problems with v3.0+
First wanted to let you know that I've been using Viseron for awhile and love it! Thank you for the time and effort.
Using latest stable release (1.7.2) I did just suddenly find that my disk was full. My machine is running Ubuntu 20.04, I only have about 10G in my /recordings folder, but found that within the docker the segments folder for one of my four cameras hasn't emptied (now at 211 GB of my 256GB drive). The location is /var/lib/docker/overlay2/longassdockercode/diff/segments/garage (matching this camera name). Folders for the other three cameras appear to be empty.
Any advice, or should i move to the 1.8 beta?
Thanks again!