Greetings Sighthound Users,
Today we release the first Release Candidate version for Sighthound Video. It improves upon the previous Beta 3 release, and introduces the following changes:
Updating our support integration in the desktop version
Adding webhooks action
Providing configurable control over clip fragmentation
Let me go over these changes in detail.
The dialog to submit a support request from within the program has changed a bit:
First, it now provides the ability to update a previously opened ticket, rather than always create a new one. Second, it lists all the files that will be submitted along with the ticket, so you will know what kind of information is being sent. Finally, we have moved to a much-improved support platform called HappyFox. The URL to the new (or updated) ticket will be provided upon successful submission. The username will be the email associated with your Sighthound account; please use password recovery to set up your HappyFox password when logging in for the first time.
Webhooks allow integration with external services, such as Slack. The initial integration is basic, and allows executing a webhook with either a Plain Text or JSON payload. The payload can contain variables, such as the name of the rule or the camera triggering the action, or time of the event.
Many 3rd party services provide webhooks API, please consult the documentation for individual services you consider for integration. One example is Slack: https://api.slack.com/incoming-webhooks
We hope to continue expanding 3rd party integration abilities in future versions of Sighthound Video, and welcome any feedback and wish list items.
A frequent question being asked about the search UI is why a clip with a moving object ends, only to restart a second or two later as a different clip. This is especially prominent if the object moves behind an obstacle, or leaves the scene momentarily. Without going into too much detail, this is a consequence of the original design. When an object disappears, even momentarily, and then reappears, it will then be tracked as a different object -- and the UI preference, until now, had been to split the two into separate clips.
In this version, we give control over this behavior to the user. A new configuration setting controlling clip fragmentation had been introduced:
In the default configuration, with “Join clips …” unchecked, the previous behavior is preserved. However, when enabled, we will join the clips where distinct objects are in close temporal proximity to each other.
A couple of things to note. First, when this setting is modified, it will only affect the clips going forward -- past clips will not be joined (or separated, depending on how the setting is being changed). Second, increasing the time limit for joining may increase your disk usage ever so slightly: the video in-between clips, which would previously be expunged when the time specified in “Temporarily keep all video for up to:” setting had elapsed, will now be retained.
Personally, I find the new setting to be most useful when set to 2-4 seconds -- but your mileage may vary, based on usage pattern, camera placement or personal preference.
Please reach out with your feedback and experiences.