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
Frigate 0.13 RC: No frames have been received, check error logs #9406
Comments
Have you recompiled the trt models to use the new version? Like the release notes said models generated previously are not supported. |
No, I'm not using TRT Models here, it's just the homonymous name of folder where I placed TRT & TFLITE models. |
The main change in 0.13 is that models are generated automatically for trt on first startup. What are the frigate logs after running for 5 minutes? |
No nothing changed with ffmpeg. Also if I understand what you're saying that is not correct, there is no such functionality to refresh the images on the main camera dashboard. Can you send a full screenshot of the entire system page please |
@NickM-27 Yes, you're right, I misinterpreted it a bit: after I refresh the page in 0.12 I see changes in camera images, while in 0.13 I see either a static (previous) image or the message about "No frames.." on a black screen. |
100 milliseconds of inference time is crazy high, so that is most likely the problem. I'd suggest using the built in model and see if that fixes the issue |
Same inference time in 0.12, and no problems at all, not a single frame skipped. Built-in model, albeit gives lesser inference time, quality-wise is much more inferior to EfficientDet. There's something wrong/different in 0.13 for sure. |
The skipped frames counter was broken in 0.12, so no skipped frames doesn't mean it wasn't actually skipping frames |
100ms is really slow, it means you can only run 10 inferences per second, which is not nearly enough for 5 fps across 6 cameras |
In any case, we've not had any other reports of this issue so it will likely be something fairly specific |
@NickM-27 OK, I can try reconfiguring Frigate for TensorRT despite its model's inferiority in terms of accuracy, but I don't think the inference time has something to do with constantly disappearing streams in 0.13. When "No frames.." appears, the system doesn't work, logically. And in 0.12 it works.
|
the inference time has a direct affect on this issue, because when frigate is sitting waiting for the object detection inference to complete it is unable to process other frames and that means the frame times fall behind causing frigate to return the no frames received image. we still see loads of skipped frames which means something is still very wrong here. I wouldn't expect that to occur with 47 ms inference speed but it seems something is quite wrong here. I think the best thing for testing is to use the built in coral model and that should give an inference time of 10 ms and see if it still occurs at that point |
another thing you could try is just turning off detect in the dashboard for all cameras and see if the issue improves |
@NickM-27 Yeah, I managed to get 27-33 ms inference time with TRT Yolov7-640 model. However I regret that the EfficientDet model takes so much time for inference. That model is much more false-proof than the standard one. |
Because the models aren't trained on security camera images they definitely vary highly from camera to camera in terms of false positives. |
@NickM-27 One more question - I have a PTZ camera with parameters like this:
In Frigate 0.12 there was a clear recording from motion start till motion end (PTZ moves quickly, I assume the motion detection was leveraged immediately and recording started as well). |
there are some things to clear up here:
|
I have Reolink RLC-523WA actually two separate HA setups. With Frigate 0.12.1 both setups are working, but upgrading Frigate to 0.13.2 those are not working. By restoring back to Frigate 0.12.1 without any Config changes, the setups are working. |
Very similar here. I get the 'No frames have been received, check error logs' very often on all cameras simultaneously. This wasn't happening on previous versions. |
I have this nowadays working. It seems that it takes time to stabilize after upgrade from 0.12.1 to 0.13.2. It was taking even about 24 Hours. |
I also have this same issue with a variety of Amcrest cameras after upgrading to 0.13.2. Nearly all of my cameras are giving the "no frames have been received" message, with a few intermittently successful frames being shown after multiple reloads of the camera page. Everything worked flawlessly with 0.12.1, so I've had to downgrade back to that version to have a functional NVR system. |
So, after some fiddling, I found that I was able to get 0.13.2 working with a combination of using the ffmpeg:rtsp:// source in go2rtc along with the secondary lower VGA resolution camera streams at 640x480, then scaled up to 854x480 for detection to fix the aspect ratio. Previously with 0.12.1 I had been using the native camera resolution video scaled down to 1280x720 for detection without problem. I'm still somewhat disappointed in this workaround, as JSMPEG quality suffers quite dramatically, but at least my home assistant integration is working again with the latest version. |
Also getting this after moving to v0.13. Though I am guessing it is due to performance and high inference. |
I'm getting this too after upgrading to v0.13. I'm having reolink camera with the recommended setup (using HTTP stream with lower resolution). I haven't found a solution yet. Part of the config (worked really well with v0.12)
Logs
|
Update: Downgrading go2rtc to 1.6.2 seems to fix the issue. I tested 1.7.0 and got the same issue. |
@tobernguyen the config you have there is not the reolink recommended config, the difference being the recommended config uses ffmpeg:http |
I couldn't solve the problem, I had to downgrade to 12. I would have to try changing the go2rtc version. Someone who confirmed if that would be the problem? |
@NickM-27 Thanks for pointing that out. I will consider trying that with the latest go2rtc. That said, I have used this configuration in v0.12 and have zero issues. Since downgrading go2rtc to 1.6.2, I have never seen the "No frames have been received, check error logs" anymore and the recordings are no longer broken midway. @ithesk At least in my setup, I can confirm go2rtc was the culprit ^ |
@tobernguyen yes, the later go2rtc has issues with http flv hence the recommendation to use ffmpeg with it |
I just tested using |
I changed it to |
how to download the version of go2rtc? |
@jaaneo try following the tips on this thread #6502 (comment). Hopefully it steers you in the right path as all installations are slightly different. |
Hi, I also just wanted to add that I am having issues with the OP's topic. Tried to change go2rtc version from 1.8.4 to 1.8.5 no change, to 1.6.0 no change. to 1.9.0 no change. I can see how the streamy are being picked up by the GPU but immediately disapear from nvidia-smi. Only one out of six camera (all of my six cams are of the same model [Annke c800; HVEC only]) is working without any issues. Storage or GPU Memory (tried 4GB to 24GB on a Tesla P40) cannot be an issue... since streams are aborting after only (max) 5 seconds. If needed I can attache some logs. Best, |
just go here and download what you need: https://github.com/AlexxIT/go2rtc/releases |
@Goeste I tried all those versions you did as well and none of them worked for me. Go2rtc version 1.5.0 however has been perfect, super stable no issues across all my POE and WiFi based cameras. Give 1.5.0 a go and good luck 🤞 |
@sebdoan TY for that ;) guess what.. i rebootet all cams that were not working and now even with 1.9.0 everything works again... let's see for how long if it will fail again, i'll switch to 1.5.0 |
Ok, with 1.9.0. it failed again. I replade go2rtc with version 1.5.0 still failing... only one webcam is detecting objects, non of the other 5 is doing so... |
I also see it's only failing when using the mainstream instead of the substream for detection (except for one camera....) weird... |
OK, issue found. all webcams were set to 6FPS where as the one that is working was on 12,5FPS. So... I set all others to 12,5 FPS and automagically streams reappear... no hanging since with go2rtc 1.9.1 :) My webcams are all Annke c800 (h265 streams) |
Describe the problem you are having
No frames have been received, check error logs appears periodically in Frigate's Web Interface
Restart of Frigate may temporarily help with some cameras, but soon the problem reappears.
After a while camera image may show up again normally.
There were no problems like this with the previously used Frigate 0.12.1 Release.
I tried to use the embedded go2rtc 1.8.4, then after no lock included a go2rtc 1.8.5 in docker volume, but nothing's changed.
Docker-compose.yml:
Version
0.13 RC1
Frigate config file
Relevant log output
Frigate stats
Operating system
Debian
Install method
Docker Compose
Coral version
USB
Any other information that may be helpful
Go2RTC logs contain no errors:
The text was updated successfully, but these errors were encountered: