Describe the bug
Akri discovers cameras by doing a multicast for a configurable amount of seconds. Then, it filters all the responses by scopes and then calls GetSystemDateAndTime on the remaining cameras. This call should only be made once per camera; however, it appears that cameras are being discovered multiple times in the multicast and then being pinged for aliveness multiple times:
2021-08-25T13:29:25Z TRACE akri_onvif::discovery_impl::util] simple_onvif_discover - uris after filtering by scopes ["http://10.111.222.251/onvif/device_service", "http://10.234.123.456:80/wsd/mex", "http://10.234.123.456:80/wsd/mex"]
The vector of multicast responses should be deduped before proceeding with the next steps.
382 might just be mitigating a symptom of a larger issue of how we handle multicast responses. This issue should be re-opened if other similar bugs occur.
Describe the bug Akri discovers cameras by doing a multicast for a configurable amount of seconds. Then, it filters all the responses by scopes and then calls
GetSystemDateAndTime
on the remaining cameras. This call should only be made once per camera; however, it appears that cameras are being discovered multiple times in the multicast and then being pinged for aliveness multiple times:2021-08-25T13:29:25Z TRACE akri_onvif::discovery_impl::util] simple_onvif_discover - uris after filtering by scopes ["http://10.111.222.251/onvif/device_service", "http://10.234.123.456:80/wsd/mex", "http://10.234.123.456:80/wsd/mex"]
The vector of multicast responses should be deduped before proceeding with the next steps.Flow Installation command:
ONVIF Discovery Handler log snippet:
Proposed fix Remove duplicates from
filtered_uris
before passing them intoget_responsive_uris
here