[Bug]: Exception in thread recording_maintainer / UnpicklingError / No space left on device #12580
Replies: 2 comments 17 replies
-
|
More information is going to be needed, I have a couple 0.14 instances that have multiple weeks of uptime without issues. in this case it appears that /tmp/cache ran out of space. What is your docker compose? |
Beta Was this translation helpful? Give feedback.
11 replies
-
|
I tried running multiple times in quick succession but am unable to reproduce this issue. Can you elaborate on how you manually triggered this to reproduce |
Beta Was this translation helpful? Give feedback.
-
|
I am using Node-RED. So as result there is something like this here: Log from node red edit: |
Beta Was this translation helpful? Give feedback.
-
|
There have been some recent changes committed to the dev branch that may correct your issue, though we have been unable to reproduce it directly. Can you test the latest dev build and let us know if your original issue has been solved? |
Beta Was this translation helpful? Give feedback.
-
|
Can i use the dev directly from my docker compose ? Btw. my instance is running since yesterday after my workaround to limit the requests on NodeRED side |
Beta Was this translation helpful? Give feedback.
-
|
there are no migrations between beta4 and now. You just use the image that is most recent https://github.com/users/blakeblackshear/packages/container/package/frigate |
Beta Was this translation helpful? Give feedback.
-
|
i can still reproduce an error: |
Beta Was this translation helpful? Give feedback.
6 replies
-
|
I can't reproduce either using 4 concurrent curl calls back to back several times within a couple of seconds. It must be something unique to your setup that's triggering the issue. At least you can mitigate it by limiting the calls to 1/minute. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, maybe one last try ;) I can reproduce the problem with following curl: Maybe one of you can try this comand. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. I can reproduce the issue with that command. This may be a deeper, underlying issue with ZeroMQ, the interprocess communication package we use with Frigate and may not be something we can work around in Frigate directly. We'll dig a bit further. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately I have only been able to reproduce it once, even with 100 api calls, so I don't really have any clear understanding of what it could be other than an underlying race condition or bug in something upstream of frigate itself. For now I think we can keep this open and see if others experience the same |
Beta Was this translation helpful? Give feedback.
-
|
this has been fixed in 0.15 |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Describe the problem you are having
Since I updated to beta 0.14.0-a4eb435 my frigate instance runs in errors after some hours.
The time range can be some minutes or also after a whole night.
I had no issues with this cameras on 0.13.
edit:
Everything is working fine until first error occurs:
Once the error occured, copy of files from /tmp/cache/ is no longer working and increases until no space left.
Steps to reproduce
Nothing special to do.
Just wait some time until exception occurs.
Recording is stopped and is functionality after reboot
Version
0.14.0-a4eb435
Frigate config file
Relevant log output
Operating system
Proxmox
Install method
Docker Compose
Network connection
Wired
Camera make and model
Dahuha
Any other information that may be helpful
edited: reduced the files to the important parts
Beta Was this translation helpful? Give feedback.
All reactions