In the FAQ for Frigate+, it says "The base model is trained from scratch from a sampling of images across all Frigate+ user submissions." Is there anyway to opt out of this if you don't feel comfortable having your CCTV footage being used for training? Is there much risk?
#Frigate+ submissions
spark nimbus
green yoke
To be clear I don't work on Frigate+, only Frigate itself. But can you elaborate on your concern? What is the difference to you between images being used to train your own model and images being used to train the shared base model?
spark nimbus
I'm not very well versed in this kind of object detection AI at all, so my concern is that there would be some privacy risk from having my images in the training data of a shared model
green yoke
As far as I understand it is impossible for images used for training to be derived from an object detection model
spark nimbus
As far as I understand it is impossible for images used for training to be deriv...
well that is reassuring. However, I do have another problem, and I'm not sure what the root cause is
It is that after half an hour to an hour of watching a birdseye view stream on my tv through VLC, it cuts out, with all cameras crashing
I'm fairly sure this is also observable after watching the frigate dashboard after a while
go2rtc has EOF errors, and in the logs, there are various DTS and timestamp errors, ending with the ffmpeg crash
green yoke
would need to see a full copy of logs when this happens for starters
spark nimbus
spark nimbus
you can ignore the camera1 stuff, that is a faulty camera which is a separate issue
in other crashes I've seen the dts and timestamp stuff, and that seems to happen alongside the crashes, but I guess not this time
or it might be earlier but the frigate logs cut it out
spark nimbus
there was nothing in the go2rtc logs this time when it happened
normally there are EOF errors though
I increased the ffmpeg timeout and it has been running stable for a couple hours
we'll see overnight
though this has happened and it just craps out sometime overnight
spark nimbus
cameras crashed again:
lots of non-motonous dts errors around the crash time
nothing in go2rtc logs again
hmmm, cameras unable to read frames from the capture process
then ffmpeg crashes and restarts
is camera1 causing cascading crashes?
green yoke
lots of non-motonous dts errors around the crash time
that is nothing to worry about
go2rtc is returning 404, so the fact that there is nothing in go2rtc logs is very weird
spark nimbus
most of the 404s are from camera1, which is a known faulty camera, though afaik, it shouldn't be affecting the other cameras
green yoke
the logs you are showing only show camera1 though
so what do you mean by "cameras crashed again"
oh discord wasn't showing the whole log
it's entirely possible that camera1 is causing issues for other cameras
spark nimbus
looks like I'm heading to reolink rma 😮💨
camera1 isn't online at night, and the all camera crashes also occur at night
I wonder why the crashing of camera1's ffmpeg is taking down the other camera's ffmpegs but not all the time, only semi-randomly
spark nimbus
Cameras haven’t crashed for the last 6 hours during the day
Camera1 works during the day but craps out during the night
Also occasionally sends corrrupted packets during the day though
spark nimbus
it's entirely possible that camera1 is causing issues for other cameras
I've disabled camera1, and the setup just crashed again
this log is much easier to read
green yoke
all of the connectoins time out at the same time
almost makes it seem like a network issue
spark nimbus
spark nimbus
almost makes it seem like a network issue
I don't why it would be timing out, is my problem
the camera setup was working fine with v13
no timeouts
however, that was with another computer
but the config was the same
perhaps I just bump the ffmpeg timeout again
also all devices in this network are connected with ethernet, which makes it even weirder
https://github.com/blakeblackshear/frigate/discussions/14903 here, it says that http-flv with reolink isn't so good
maybe that is the issue
haven't had any issues with the 4k streams and they are rtsp
also looks like I'm not the only person with memory leak issues
memory cap on docker really helps though
green yoke
in most cases http-flv is better, even recently we had users on the 0.15 beta having issues with reolink and switching to http-flv fixed all of them. But it seems very much a YMMV situation and so definitely could be worth trying rtsp
spark nimbus
I'll try increasing the timeout first, and then switching over to rtsp, as rtsp doesn't have the ext stream, and the reolink substream is only like 640x360