Closed spacebares closed 1 year ago
In general frigate is only meant to run with line powered 24/7 streaming cameras, not momentarily streaming cameras. Frigate will use the supplied rtsp for live feed and detection / recording at that is the only option.
That is acceptable, i just cant figure out how to keep the logs clean. Is there no way to disable error log message for specific camera?
Maybe try setting frigate.camera
to critical https://docs.frigate.video/configuration/advanced#logger
logger:
logs:
ffmpeg.door.detect: critical
watchdog.door: critical
frigate.video: critical #😔
@spacebares Did this help with your issue? Is it working properly for you now ?
@spacebares Did this help with your issue? Is it working properly for you now ?
My log is no-longer spammed with the error message with the changes i made above. The error does still exist, as it is spawning ffmpeg processes non stop.
When the eufy camera is triggered threw its motion sensor, and starts its feed, frigate picks it up just fine.
Cool. Does it impact cpu very badly or would you say it’s acceptable. It’s not ideal but at the same time I’d be nice to have the 2c eufys on frigate.
From: spacebares @.> Sent: 15 March 2023 13:44 To: blakeblackshear/frigate @.> Cc: atv2016 @.>; Comment @.> Subject: Re: [blakeblackshear/frigate] [Camera Support]: Eufy battery cameras (Issue #4382)
@spacebareshttps://github.com/spacebares Did this help with your issue? Is it working properly for you now ?
My log is no-longer spammed with the error message with the changes i made above. The error does still exist, as it is spawning ffmpeg processes non stop. [image]https://user-images.githubusercontent.com/57186372/225326858-a55a7384-ec61-4d17-9ca9-f5552879a63a.png
When the eufy camera is triggered threw its motion sensor, and starts its feed, frigate picks it up just fine.
— Reply to this email directly, view it on GitHubhttps://github.com/blakeblackshear/frigate/issues/4382#issuecomment-1470035815, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEBCFUYAQTKE6GPZZ54Z5R3W4HBSDANCNFSM6AAAAAAR6QIXRE. You are receiving this because you commented.Message ID: @.***>
Checking with htop -d 2
, it looks like just a small ~1% cpu blip from the process when it spawns sometimes not even using any cpu but around 0.2% memory. This is with an i5-6600 and 8gb ram.
My cpu usage during snow storm can be quite heavy but htop uses around 20% when its refreshing this fast. This is with 8 cameras (2 eufy that are asleep)
And here is the top of the list, the new processes kinda just sit there doing nothing until they are killed by frigate.
As ugly as it all is, i guess it works ?
Thanks, much appreciated. I guess for you it works with your ffmpeg config. I got it working (I guess when it was live) but now I just get a “no frames received” and I see this “frigate.record WARNING : Discarding a corrupt recording segment: /tmp/cache/kitchen_backdoor-20230315180851.mp4” message all the time in the logs (so I know it is recording)
I’ll change my output_args: preset-record-generic-audio-copy to your argument line and see if that works better. Are you using any input_args for the eufy cam as well ?
Also, Did you manage to find the magic url that wakes the eufy up? Would be nice to click on the image in frigate and see the feed. It's interesting that the webrtc card in homeassistant does wake up the eufy, so i guess it is possible.
I could not find that magic url. As for presets, i had since moved to a version of frigate that uses ffmpeg presets. I don't remember what i was using. However the presets i am using has the following mentioned in the code (they might be formatted differently):
hwaccel args (preset-vaapi):
"allow_profile_mismatch",
"-hwaccel",
"vaapi",
"-hwaccel_device",
"/dev/dri/renderD128",
"-hwaccel_output_format",
"vaapi"
input_args (preset-rtsp-generic):
"-avoid_negative_ts",
"make_zero",
"-fflags",
"+genpts+discardcorrupt",
"-rtsp_transport",
"tcp",
TIMEOUT_PARAM,
"5000000",
"-use_wallclock_as_timestamps",
"1",
record args (preset-record-generic-audio-aac):
"-f",
"segment",
"-segment_time",
"10",
"-segment_format",
"mp4",
"-reset_timestamps",
"1",
"-strftime",
"1",
"-c:v",
"copy",
"-c:a",
"aac",
Does input_args still go in the same indentation as output_args? I ask because i have a input_args also defined under inputs: it seems.
garage:
ffmpeg:
output_args:
record: -f preset-record-generic-audio-aac
inputs:
- path: rtsp://127.0.0.1:8554/garage
input_args: preset-rtsp-generic
this is correct, except remove the -f
from record:
I guess my question is, do i put input_args under inputs: or under it's own input_args like output_args (directly under ffmpeg).
Sorry if i wasn't clear.
And yes i removed the -f, i noticed i kept it in there and frigate wasn't behaving nicely anymore.
it goes insideinputs:
just like you have it.
Thank you! The eufy2c works fine now.
And i realise we're going way off-topic here, but if you indulge me, but i noticed you are using the hwaccel vaapi preset. I was looking here https://docs.frigate.video/configuration/hardware_acceleration/#intel-based-cpus-10th-generation-via-quicksync-1 where it says that after 10th generation, you can use this:
Intel-based CPUs (>=10th Generation) via Quicksync#
ffmpeg: hwaccel_args: -c:v h264_qsv
Where i can find these presets you showed earlier? I'd like to know the preset of the above one. Mine does work with the vaapi, although it doesn't show how much memory is consumed, hopefully it should be a sizeable boost to frigate working better.
Thanks again.
Nevermind, found it!
@spacebares works pretty well with the eufys now. wanted to ask you, do you ever get:
WARNING : Discarding a corrupt recording segment: /tmp/cache/kitchen_backdoor-20230317082956.mp
In your logs with these edit cameras?
i get them for all heh
reolink
2023-03-14 10:23:03.965714461 [2023-03-14 10:23:03] ffmpeg.garage.record ERROR : [segment @ 0x5595dcce41c0] Failure occurred when ending segment '/tmp/cache/garage-20230314102252.mp4'
2023-03-14 10:23:03.965719294 [2023-03-14 10:23:03] ffmpeg.garage.record ERROR : Error writing trailer of /tmp/cache/garage-%Y%m%d%H%M%S.mp4: No space left on device
2023-03-14 10:23:03.965721315 [2023-03-14 10:23:03] watchdog.garage INFO : Terminating the existing ffmpeg process...
2023-03-14 10:23:03.965723035 [2023-03-14 10:23:03] watchdog.garage INFO : Waiting for ffmpeg to exit gracefully...
2023-03-14 10:23:04.094056690 [2023-03-14 10:23:04] frigate.record WARNING : Failed to probe corrupt segment /tmp/cache/drivewayc-20230314102256.mp4: 0 - b'[mov,mp4,m4a,3gp,3g2,mj2 @ 0x559831a476c0] moov atom not found\n/tmp/cache/drivewayc-20230314102256.mp4: Invalid data found when processing input\n'
2023-03-14 10:23:04.094223383 [2023-03-14 10:23:04] frigate.record WARNING : Discarding a corrupt recording segment: /tmp/cache/drivewayc-20230314102256.mp4
2023-03-14 10:23:04.123146570 [2023-03-14 10:23:04] frigate.record WARNING : Failed to probe corrupt segment /tmp/cache/front-20230314102253.mp4: 0 - b'[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55fcd52b16c0] moov atom not found\n/tmp/cache/front-20230314102253.mp4: Invalid data found when processing input\n'
2023-03-14 10:23:04.123699539 [2023-03-14 10:23:04] frigate.record WARNING : Discarding a corrupt recording segment: /tmp/cache/front-20230314102253.mp4
2023-03-14 10:23:04.145688978 [2023-03-14 10:23:04] frigate.record WARNING : Failed to probe corrupt segment /tmp/cache/frontside-20230314102253.mp4: 0 - b'[mov,mp4,m4a,3gp,3g2,mj2 @ 0x557ec045a6c0] moov atom not found\n/tmp/cache/frontside-20230314102253.mp4: Invalid data found when processing input\n'
2023-03-14 10:23:04.145692873 [2023-03-14 10:23:04] frigate.record WARNING : Discarding a corrupt recording segment: /tmp/cache/frontside-20230314102253.mp4
2023-03-14 10:23:04.168532088 [2023-03-14 10:23:04] frigate.record WARNING : Failed to probe corrupt segment /tmp/cache/garage-20230314102252.mp4: 0 - b'[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55f1eba206c0] moov atom not found\n/tmp/cache/garage-20230314102252.mp4: Invalid data found when processing input\n'
2023-03-14 10:23:04.168591271 [2023-03-14 10:23:04] frigate.record WARNING : Discarding a corrupt recording segment: /tmp/cache/garage-20230314102252.mp4
2023-03-14 10:23:04.191583584 [2023-03-14 10:23:04] frigate.record WARNING : Failed to probe corrupt segment /tmp/cache/garagedoor-20230314102253.mp4: 0 - b'[mov,mp4,m4a,3gp,3g2,mj2 @ 0x5640ef8876c0] moov atom not found\n/tmp/cache/garagedoor-20230314102253.mp4: Invalid data found when processing input\n'
2023-03-14 10:23:04.191713157 [2023-03-14 10:23:04] frigate.record WARNING : Discarding a corrupt recording segment: /tmp/cache/garagedoor-20230314102253.mp4
2023-03-14 10:23:04.215175430 [2023-03-14 10:23:04] frigate.record WARNING : Failed to probe corrupt segment /tmp/cache/side-20230314102254.mp4: 0 - b'[mov,mp4,m4a,3gp,3g2,mj2 @ 0x557b4f0dc6c0] moov atom not found\n/tmp/cache/side-20230314102254.mp4: Invalid data found when processing input\n'
2023-03-14 10:23:04.215236807 [2023-03-14 10:23:04] frigate.record WARNING : Discarding a corrupt recording segment: /tmp/cache/side-20230314102254.mp4
eufy:
2023-03-15 06:18:20.676792111 [2023-03-15 06:18:20] frigate.record WARNING : Failed to probe corrupt segment /tmp/cache/backdoor-20230315061817.mp4: 0 - b'[mov,mp4,m4a,3gp,3g2,mj2 @ 0x55effe1ed6c0] moov atom not found\n/tmp/cache/backdoor-20230315061817.mp4: Invalid data found when processing input\n'
2023-03-15 06:18:20.677201885 [2023-03-15 06:18:20] frigate.record WARNING : Discarding a corrupt recording segment: /tmp/cache/backdoor-20230315061817.mp4
2023-03-15 08:17:56.190590880 [2023-03-15 08:17:56] frigate.record WARNING : Failed to probe corrupt segment /tmp/cache/frontdoor-20230315081750.mp4: 0 - b'[mov,mp4,m4a,3gp,3g2,mj2 @ 0x564d9114c6c0] moov atom not found\n/tmp/cache/frontdoor-20230315081750.mp4: Invalid data found when processing input\n'
2023-03-15 08:17:56.190681749 [2023-03-15 08:17:56] frigate.record WARNING : Discarding a corrupt recording segment: /tmp/cache/frontdoor-20230315081750.mp4
There appears to be no events for those times. I took a look at my 24/7 NVR and there is nothing happening at that time. Eufy app shows no motion or person events. For frigate since 3/11/23 those are the only "discarding" events in my log, but i have seen them from time to time before that date. I suspect when it happens, and maybe during an event if chance would have, it would be possible to miss at least 10 seconds of a recording.
Reolink trouble is no surprise, but for the eufy cams maybe wifi signal trouble? Maybe its the camera turning itself off abruptly? Or maybe even their rtsp streams suck just like reolink, I am unsure. I suppose if you ever have a eufy cam event in frigate that is vastly different from the one in the eufy app then it is cause for concern, but that is yet the case for me.
It seems this is happening (in my view at least) that Frigate keeps on saying in progress for the object for a long time, longer after the camera stopped recording. Because of this I see multiple detections from the Eufy in the same recording as well (even though the camera was not recording anymore, and the times are wildly off (3h recordings, and it orders them in the wrong way (i guess because it has different eufy recordings in the same recording).
Maybe the eufy is not sending a stream stop properly or something, i dunno.
I'm going to log a bug/fix/feature request for this as it seems this is something that maybe could be addressed in Frigate itself, or maybe with just a configuration fix. Alternatively i'm exploring the option in the Eufy app to set the recording to 20seconds max or so.
But i think this is at least why we are seeing the "discarding corrupt segments" in the log files. At first i thought i missed recordings, but they all seem to be bunched up in a single (seemingly 3h) long recording.
It seems this is happening (in my view at least) that Frigate keeps on saying in progress for the object for a long time, longer after the camera stopped recording. Because of this I see multiple detections from the Eufy in the same recording as well (even though the camera was not recording anymore, and the times are wildly off (3h recordings, and it orders them in the wrong way (i guess because it has different eufy recordings in the same recording).
Kind of difficult to follow this but wanted to make it clear Frigate does not communicate anything back to Eufy so whatever behavior the eufy app has, has nothing to do with Frigate
I'm going to log a bug/fix/feature request for this as it seems this is something that maybe could be addressed in Frigate itself, or maybe with just a configuration fix.
As it is said above, Frigate is not looking to support battery / momentarily streaming cameras. This behavior makes sense because frigate sees the object and then the frame dies so it continues to go off of the last known frame while it tries to reconnect to the camera.
You most likely want to set
detect:
stationary:
max_frames: 300
for any battery cameras so the event does not continue.
But i think this is at least why we are seeing the "discarding corrupt segments" in the log files. At first i thought i missed recordings, but they all seem to be bunched up in a single (seemingly 3h) long recording.
That's not how Frigate recordings work, they always are 10 second segments only. If a recording is being discarded then that time won't be kept.
Up to a maximum of 10 or so seconds could be missing from the events in frigate vs the Eufy App.
I am testing https://github.com/blakeblackshear/frigate/commit/29e6f2b203bf72d7a6cf10d34b7664cf5438f6ae with delay set to 1 second for the camera, so far much better events but still could miss 1-2 seconds.
A better solution would be for the camera to tell frigate that "im awake" instead of polling. Such a thing would require alot of work just to gain 1-2 seconds of footage.
This stop-gap fix makes a ton more zombie ffmpeg processes, that spawn and get destroyed 10x more frequently now. I don't see an issue yet but this is indeed ugly. Frigate was not designed with camera streams that just start/die whenever they want.
Perhaps there is a way to get something like rtsp_restream_server to always output a blank image with a dead stream, and have it show something to frigate immediately when camera source returns?
Describe the problem you are having
The eufyCam 2 Pro only seems to support "Events" RTSP and not continuous. So the stream is dead until the hardware motion sensor wakes the camera up to start consuming battery. The camera wakes up and frigate starts picking up video and working properly however... The logs are spammed with errors! How do i suppress these specific "dead stream" errors for the eufy cameras?
Also is there anyway to get frigate to use the "live feed url" for live feeds? Currently its just blank image when you go to view the camera on frigate, as expected.. There has got to be a different URL for viewing eufy cam's live, because viewing this url does not trigger the RTSP url given by the APP. And it seems to wake the camera up so you can view it live. Ive seen this behavior in the eufy app and the eufy http web portal.
Version
0.12.0-9b5c6be (nov 08)
Frigate config file
Relevant log output
Frigate stats
Operating system
Debian
Install method
Docker Compose
Coral version
USB
Network connection
Mixed
Camera make and model
EufyCam 2 pro
Any other information that may be helpful
its got the solar panel attachment.