It would be great if you could save a video clip with the false detections and include at least 30 seconds before the false positive. When I start working on reducing the false positives, it will be helpful to have a set of videos to run through for testing.
Sure. All my detections kick off a 15s recording, but I think I only get 5s before detection. I’ll try to change that in HA.
It’s interesting. Seems like there should be far fewer false positives with this implementation because only starts detection when it sees motion and doesn’t have detection on the other 99% of time to get false positives. Also tailoring the detection area accurately to the object (which it does a great job at) should greatly increase accuracy (at least for me who just had 2 big areas defined on each camera). I was getting quite a few false positives in the old version of just parts of my lawn or wall or tables, etc, which I think I won’t see any more. That was about 80% of my problems.
So far I’ve had no false positives on the new version, but I haven’t been running it very long. I can see much higher accuracy when I test just going out and walking around at least, though it does seem to take a second or two so for the motion detection to find me.
Animals will always be an issue, but I’ve filtered most of them out just by size (even though I also have a big range of distances in my camera). I wonder if adding specific categories for cat and dog and bird into your config would help here? It might have a higher detection value for cat than human and then not detect it as human…?
Simple question, I’m on an old version of frigate (~0.2.0) but I’m not sure which, how do I check, in case I need to roll back?
At the command line, type in
sudo docker ps
Should give you the image name you are running.
Hi @blakeblackshear, I’m back and trying to upgrade from 0.2.0-beta to 5.1-rc1. Having a few issues. You might remember me from this classic hikvision problem thread, maybe the issue is similar this time. I’m upgrading from the frigate:0.2.0-beta that I’ve been running for quite a while since the ffmpeg 5 fixed those previous issues.
Unfortunately 0.5.1-rc1 only lasted 8 hours before freezing. The live feed is just showing old images from 12 hours ago, one of them looks like this:
Other looks like this:
Other looks like this:
The log is doing this sort of thing over and over:
Process for back has been reading from ffmpeg for over 10 seconds long. Killing ffmpeg...
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process exited unexpectedly with 255
Letting back rest for 0 seconds before restarting...
Terminating the existing ffmpeg process...
Waiting for ffmpeg to exit gracefully...
Creating ffmpeg process...
ffmpeg -hide_banner -loglevel panic -avoid_negative_ts make_zero -fflags nobuffer -flags low_delay -strict experimental -fflags +genpts+discardcorrupt -vsync drop -rtsp_transport tcp -stimeout 5000000 -use_wallclock_as_timestamps 1 -i rtsp://uname:pw@ip:554/Sms=4.unicast -f rawvideo -pix_fmt rgb24 pipe:
Process for back has been reading from ffmpeg for over 10 seconds long. Killing ffmpeg...
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process exited unexpectedly with 255
Letting back rest for 0 seconds before restarting...
Terminating the existing ffmpeg process...
Waiting for ffmpeg to exit gracefully...
Creating ffmpeg process...
ffmpeg -hide_banner -loglevel panic -avoid_negative_ts make_zero -fflags nobuffer -flags low_delay -strict experimental -fflags +genpts+discardcorrupt -vsync drop -rtsp_transport tcp -stimeout 5000000 -use_wallclock_as_timestamps 1 -i rtsp://uname:pw@ip:554/Sms=4.unicast -f rawvideo -pix_fmt rgb24 pipe:
Process for back has been reading from ffmpeg for over 10 seconds long. Killing ffmpeg...
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process exited unexpectedly with 255
Letting back rest for 0 seconds before restarting...
Terminating the existing ffmpeg process...
Waiting for ffmpeg to exit gracefully...
Creating ffmpeg process...
ffmpeg -hide_banner -loglevel panic -avoid_negative_ts make_zero -fflags nobuffer -flags low_delay -strict experimental -fflags +genpts+discardcorrupt -vsync drop -rtsp_transport tcp -stimeout 5000000 -use_wallclock_as_timestamps 1 -i rtsp://uname:pw@ip:554/Sms=4.unicast -f rawvideo -pix_fmt rgb24 pipe:
Process for back has been reading from ffmpeg for over 10 seconds long. Killing ffmpeg...
back: ffmpeg_process didnt return any bytes
back: ffmpeg_process exited unexpectedly with 255
Letting back rest for 0 seconds before restarting...
Terminating the existing ffmpeg process...
Waiting for ffmpeg to exit gracefully...
Creating ffmpeg process...
ffmpeg -hide_banner -loglevel panic -avoid_negative_ts make_zero -fflags nobuffer -flags low_delay -strict experimental -fflags +genpts+discardcorrupt -vsync drop -rtsp_transport tcp -stimeout 5000000 -use_wallclock_as_timestamps 1 -i rtsp://uname:pw@ip:554/Sms=4.unicast -f rawvideo -pix_fmt rgb24 pipe:
Here’s my config file:
web_port: 4000
mqtt:
host: 192.168.1.60
topic_prefix: frigate
user: uname
password: '{FRIGATE_MQTT_PASSWORD}'
objects:
track:
- person
- car
- truck
filters:
person:
threshold: 0.77
min_area: 4000
cameras:
right:
mask: 1080Right.bmp
fps: 5
height: 1920
width: 1080
ffmpeg:
input:
rtsp://uname:{FRIGATE_RTSP_PASSWORD_RIGHT}@192.168.1.50554/Sms=1.unicast
snapshots:
show_timestamp: False
objects:
track:
- person
filters:
person:
min_area: 9000
left:
fps: 5
mask: 1080Left.bmp
height: 1920
width: 1080
ffmpeg:
input:
rtsp://uname:{FRIGATE_RTSP_PASSWORD_LEFT}@192.168.1.50:554/Sms=3.unicast
snapshots:
show_timestamp: False
objects:
track:
- person
filters:
person:
min_area: 14000
front:
fps: 5
mask: 1080Front.bmp
height: 1080
width: 1920
ffmpeg:
input:
rtsp://uname:{FRIGATE_RTSP_PASSWORD_FRONT}@192.168.1.50:554/Sms=2.unicast
snapshots:
show_timestamp: False
objects:
track:
- person
filters:
person:
min_area: 4000
back:
fps: 5
mask: 1080Back.bmp
height: 1080
width: 1920
ffmpeg:
input:
rtsp://uname:{FRIGATE_RTSP_PASSWORD_BACK}@192.168.1.50:554/Sms=4.unicast
snapshots:
show_timestamp: False
objects:
track:
- person
filters:
person:
min_area: 9000
Maybe I need some special ffmpg parameters? It’s only using 3% CPU, down from 44% when it was working correctly, so doesn’t seem to be a race condition.
Yeah, I’ve tried that but it just gives me frigate:latest.
Assuming you cloned the project from git and have not changed branch since, then git status might give a clue
What exactly does this error mean?
What space is this referring to?
/arrow/cpp/src/plasma/eviction_policy.cc:134: There is not enough space to create this object, so evicting 36 objects to free up 80898048 bytes. The number of bytes in use (before this eviction) is 399914240.
/arrow/cpp/src/plasma/eviction_policy.cc:134: There is not enough space to create this object, so evicting 36 objects to free up 86197248 bytes. The number of bytes in use (before this eviction) is 397147136.
/arrow/cpp/src/plasma/eviction_policy.cc:134: There is not enough space to create this object, so evicting 35 objects to free up 84623360 bytes. The number of bytes in use (before this eviction) is 399262720.
/arrow/cpp/src/plasma/eviction_policy.cc:134: There is not enough space to create this object, so evicting 36 objects to free up 80898048 bytes. The number of bytes in use (before this eviction) is 399914240.
/arrow/cpp/src/plasma/eviction_policy.cc:134: There is not enough space to create this object, so evicting 34 objects to free up 84352512 bytes. The number of bytes in use (before this eviction) is 398069504.
/arrow/cpp/src/plasma/eviction_policy.cc:134: There is not enough space to create this object, so evicting 36 objects to free up 80898048 bytes. The number of bytes in use (before this eviction) is 399914240.
/arrow/cpp/src/plasma/eviction_policy.cc:134: There is not enough space to create this object, so evicting 36 objects to free up 80246528 bytes. The number of bytes in use (before this eviction) is 399262720.
/arrow/cpp/src/plasma/eviction_policy.cc:134: There is not enough space to create this object, so evicting 33 objects to free up 83430144 bytes. The number of bytes in use (before this eviction) is 398991872.
/arrow/cpp/src/plasma/eviction_policy.cc:134: There is not enough space to create this object, so evicting 35 objects to free up 85274880 bytes. The number of bytes in use (before this eviction) is 399914240.
/arrow/cpp/src/plasma/eviction_policy.cc:134: There is not enough space to create this object, so evicting 36 objects to free up 80898048 bytes. The number of bytes in use (before this eviction) is 396459776.
That is the plasma store running out of space in its memory cache. Frames are stored in that cache so they can be accessed by multiple processes.
So I fixed one problem, I had the framerate wrong, and switched from my synology streams back to the hikvision streams that didn’t work under v0.2, now they seem to work similarly to my synology but without some artifacts, but they crap out after a day. Here’s what I get in the logs, any ideas? Interestingly all the camera images are frozen at the exact same moment from yesterday.
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 13 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 12 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 11 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 10 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 9 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 8 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 7 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 6 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 5 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 4 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 3 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 2 more times
/arrow/cpp/src/plasma/io.cc:168: Connection to IPC socket failed for pathname /tmp/plasma, retrying 1 more times
TrackedObjectProcessor: unable to connect plasma client
Higher up in the logs, it looks like the snippet I sent in my post from a couple days ago
Here are my last camera images all at the same moment. Let me know if there’s something I should try before giving up and going back to 0.2-beta
Did you add the new shm-size parameter to your config?
Yes, I remember typing it in as 768m for my 4 1080p streams. Since the first time I ran it, I just cloned that config over to a permanent config in synology, so I hope all the options came with it.
Is there any way I can double check?
Not sure how you would check on the synology.
I have been unable to get the container to run as I am getting the following error.
No such file or directory: '/config/config.yml
I have created a config directory volume and placed the config.yml file in that directory.
Could this be a permission problem?
here is my docker run command…
docker run --rm \
--privileged \
--shm-size=512m \
-v /dev/bus/usb:/dev/bus/usb \
-v ~/docker/frigate:/config:ro \
-v /etc/localtime:/etc/localtime:ro \
-p 5000:5000 \
-e FRIGATE_RTSP_PASSWORD='password' \
blakeblackshear/frigate:stable
I think your config file might be ending up at /config/config/config.yml. Maybe try -v ~/docker/frigate/config:/config:ro
unfortunatly same issue.
After a bit more research, it looks like Synology is shitty and doesn’t allow setting docker run arguments in their config. Any chance of setting this in an environment variable?
I have a Synology and this is my docker command
$ cat ~/frigate.sh
sudo docker run \
--name='Frigate-0.5.1-rc2' \
--privileged \
--shm-size=512m \
-v /dev/bus/usb:/dev/bus/usb \
-v /volume1/data/frigate/config:/config:ro \
-v /etc/localtime:/etc/localtime:ro \
-p 5555:5000 \
-d blakeblackshear/frigate:0.5.1-rc2