[Support]: Too many unprocessed recording segments in cache for CameraName #15683
Replies: 3 comments 1 reply
-
|
Would be great to see the contents of /tmp/cache in the container while this is happening. |
Beta Was this translation helpful? Give feedback.
-
Thanks for your reply. I restarted the container shortly after making this post, so it is temporarily working ok at the moment. Below are the contents of /tmp/cache/ from just now, so we can establish a baseline. I will post the same output when the error occurs in the next few days.
I also thought to get the folder size:
...and also the number of files in /tmp/cache/:
...nothing really out of the ordinary at the moment. I will report back when the error occurs again. Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
I also see this error on my setup (with 0.15-beta4), seems to be a new thing after upgrading from beta3, but not sure as I had briefly bumped back to stable to check some other instability issues. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, frustratingly, the error hasn't occurred since I restarted the container back on 26th December. I will provide the entire log since the last container start-up below, but here are the relevant lines:
Is this anything to worry about? In any case, I will continue to monitor for the original issue and will post a comment if it happens again. Thanks. Here's the entire log for the last few days:
|
Beta Was this translation helpful? Give feedback.
-
Describe the problem you are having
Camera video feeds show a black screen with white text: "No frames have been received, check error logs".
Logs just show the following line, repeated: "Too many unprocessed recording segments in cache for [Camera Name]"
Version
0.15.0-beta1 and also 0.15.0-beta4
What browser(s) are you using?
Google Chrome v 131.0.6778.205 (Official Build) (x86_64)
Frigate config file
Relevant Frigate log output
Relevant go2rtc log output
2024-12-25 08:02:04.597047348 [INFO] Preparing new go2rtc config... 2024-12-25 08:02:04.906897544 [INFO] Not injecting WebRTC candidates into go2rtc config as it has been set manually 2024-12-25 08:02:04.934669061 [INFO] Starting go2rtc... 2024-12-25 08:02:05.024673277 08:02:05.024 INF go2rtc platform=linux/amd64 revision=b2399f3 version=1.9.2 2024-12-25 08:02:05.024675959 08:02:05.024 INF config path=/dev/shm/go2rtc.yaml 2024-12-25 08:02:05.024997007 08:02:05.024 INF [api] listen addr=:1984 2024-12-25 08:02:05.025181313 08:02:05.025 INF [rtsp] listen addr=:8554 2024-12-25 08:02:05.025387426 08:02:05.025 INF [webrtc] listen addr=:8555 2024-12-25 08:02:14.598826054 [INFO] Starting go2rtc healthcheck service...FFprobe output from your camera
docker exec -it frigate sh ffprobe rtsps://192.168.1.1:7441/HZ6BuVp4F3iWXAwl sh: 1: ffprobe: not foundFrigate stats
I have no idea how to get this.Install method
Docker Compose
docker-compose file or Docker CLI command
Object Detector
Coral
Network connection
Wired
Camera make and model
Ubiquiti, various models
Screenshots of the Frigate UI's System metrics pages
Any other information that may be helpful
I first noticed this when I upgraded from Frigate v0.13 to v0.15.0-beta1, but it has persisted into v0.15-beta4.
(I decided I would skip v0.14 altogether)
The issue usually starts at least 24 hours after starting the Docker container. I can restart the container and everything will be fine... then after a day or so, this error comes back.
Frigate is installed as a Docker container, running on an Apple Mac Mini with Debian installed.
A Google Coral Edge TPU USB is plugged into the computer and Frigate is using that for detections.
"Hardware info" button on the system metrics page:
Beta Was this translation helpful? Give feedback.
All reactions