Motion Detection: Number of snapshots per email
Re: Motion Detection: Number of snapshots per email
When is this getting fixed????
Re: Motion Detection: Number of snapshots per email
FWIW... some feedback with my experiments...
IP4M-1028
IP3M-H2X
When I first got the cameras setup I consistently received 3 snapshots per email from both cameras while all storage was to FTP (local QNAP). Then like all geeks I started changing settings and soon I was only getting 1 snap/email on the IP4M. I added a SD card to the IP3M and set snapshots to 5, quality=6... and I got 5/email. Only 1/email on the IP4M on FTP. I never had a problem with 3 or 5 snaps being stored... just emailed.
After a couple hours of experiments changing ONE thing at a time I believe there are 1 or more a race conditions that are impacted by 4 different latencies
1) number of snapshots per event
2) quality of jpg endcode
3) storage medium
4) SMPT Interval
Network->SMTP
The Interval setting is a mystery. Anything but 0 and you get 1-2 snaps/email. Hard requirement to set this to ZERO.
Camera->Video->Snapshot->Event
The IP3M w/SD I can get 5 snaps/email at quality=6... lower res (faster encode) and SD (faster storage). On the IP4M I can get 3 snaps/email only at quality=4. If I wanted 5, then I may get 3-4 across 2 emails. At quality=3 I can get 5 snaps across 2 emails (3 in first, 2 in last).
Event->Video Detection->Motion Detection
As inferred above, the lower res, faster storage (SD) IP3M consistently provides 5 snaps/email at quality=6. The IP4M can manage 3 snaps/email at quality=4. Both can save 5 snaps to storage but since the IP4M is using FTP it can't send them. At quality=4 you lose snaps in the email but not on storage. So the IP3M does 5 snaps and the IP4M only attempts 3.
With ZERO understanding of the code it appears the camera is trying to do too many things at once (encode video, encode snaps, stream store video, save snaps, create email, login/send emails, etc). If the snaps are encoded and stored in the time it takes to login and create an email then the send has all the snaps. If not and interval=0 and you are still in the event then another email will be sent with whatever snaps are available. I think this is why it appears random for some. I can guess the race is partly because you want a snap to go out ASAP and yet there are dependencies that are unforgiving.
One post discovered the latency of SMTP login was also impactful (https://amcrest.com/forum/technical-dis ... t5944.html)
I am tired of experiments...
but will likely take this up again to split snapshots to SD and video to FTP to see if I get different results. The IP4M is eave mounted and its cold out... so it may be awhile.
Hope this helps, quality and storage seem to be the biggest contributors (for me).
IP4M-1028
IP3M-H2X
When I first got the cameras setup I consistently received 3 snapshots per email from both cameras while all storage was to FTP (local QNAP). Then like all geeks I started changing settings and soon I was only getting 1 snap/email on the IP4M. I added a SD card to the IP3M and set snapshots to 5, quality=6... and I got 5/email. Only 1/email on the IP4M on FTP. I never had a problem with 3 or 5 snaps being stored... just emailed.
After a couple hours of experiments changing ONE thing at a time I believe there are 1 or more a race conditions that are impacted by 4 different latencies
1) number of snapshots per event
2) quality of jpg endcode
3) storage medium
4) SMPT Interval
Network->SMTP
The Interval setting is a mystery. Anything but 0 and you get 1-2 snaps/email. Hard requirement to set this to ZERO.
Camera->Video->Snapshot->Event
The IP3M w/SD I can get 5 snaps/email at quality=6... lower res (faster encode) and SD (faster storage). On the IP4M I can get 3 snaps/email only at quality=4. If I wanted 5, then I may get 3-4 across 2 emails. At quality=3 I can get 5 snaps across 2 emails (3 in first, 2 in last).
Event->Video Detection->Motion Detection
As inferred above, the lower res, faster storage (SD) IP3M consistently provides 5 snaps/email at quality=6. The IP4M can manage 3 snaps/email at quality=4. Both can save 5 snaps to storage but since the IP4M is using FTP it can't send them. At quality=4 you lose snaps in the email but not on storage. So the IP3M does 5 snaps and the IP4M only attempts 3.
With ZERO understanding of the code it appears the camera is trying to do too many things at once (encode video, encode snaps, stream store video, save snaps, create email, login/send emails, etc). If the snaps are encoded and stored in the time it takes to login and create an email then the send has all the snaps. If not and interval=0 and you are still in the event then another email will be sent with whatever snaps are available. I think this is why it appears random for some. I can guess the race is partly because you want a snap to go out ASAP and yet there are dependencies that are unforgiving.
One post discovered the latency of SMTP login was also impactful (https://amcrest.com/forum/technical-dis ... t5944.html)
I am tired of experiments...
but will likely take this up again to split snapshots to SD and video to FTP to see if I get different results. The IP4M is eave mounted and its cold out... so it may be awhile.Hope this helps, quality and storage seem to be the biggest contributors (for me).