I’ve been trying to find out a way of answering this question using the StatusViewer sample.
So far I tried to compare the Recording stopped event data structure sent when the user stops the manual recording and when the system automatically stops it.
I could not pin point any differences between the two data instances.
I’m using an Xprotect 2017 R1, is there a way to identify the entity that actually triggering the recording stopped event?
I believe the user’s actions will be in the Audit Log.
Note that this might not be enabled. To enable it go into Tools - Options, and pick the Server Logs tab, highlight the Audit log and configure.
So, basically according to my understanding, to find out if the server ended a recording, my code has to browse the Audit log and make sure there’s no entry related to the end of the recording for a specified camera at a specific time.
Am I Right?
Browsing the audit log seems to introduce some latency and to my opinion could trigger potential inaccurate detection when the audit log gets slow under heavy load.
Is that the only available solution?
Is there any plan to include the reason an event was raised in the current SDK API used in the StatusViewer Sample?
To start recording could be done in multiple rules, could be hundreds of rules, each rule that start recording automatically has some form of end recording also. Note that if the server is recording by a rule then a user cannot stop it. As long as one rule has started recording and never stopped it recording will go on. So the situation you want to detect is only relevant if the user was the one that initiated the recording in the first place.
Also explained in this knowledge base article - https://force.milestonesys.com/support/articles/en_US/How_To/About-start-and-stop-recording-in-MIP-SDK-c-library
I would like to retract my first answer. Use the StatusViewer method and look for the Manual Recording Started and Manual Recording Stopped events. Note how Manual Recording Stopped does not necessary mean Recording Stopped.
Note if you want to see which user stopped recording this is not part of the event, here a log server lookup might still be relevant.
I apologize, but I’m not sure I fully understand your previous statement and how it is relevant to identify the reason the stop recording event is triggered.
Maybe I should try to expose our use case:
Assuming a human user manually started a recording, do action “A” if any human user manually ended the same recording, do action “B” if the server automatically ended the recording because the maximum manual recording time was reached.
For the purpose of testing our use case, we use a very simple Xprotect setup with a camera set to always streaming, on which recording is enabled, no motion recording is enabled and maximum manual recording time is set to 1 minute.
That’s it! There are no other rules driving the recording and potentially interfering.
We trigger the test, by simply activating manual recording using a single smart client showing our single camera.
Using the StatusViewer sample we can observe the very same events sequence (identical data content as well), no matter if the user stopped the recording or if the server stopped the recording (because max recording time was reached) : “Manual Recording stopped”, “Recording Stopped” in this very same order.
The smartclient recording indicator confirms the recording was stopped.
Which user actually stops the recording is not relevant to us, we just need to be able to differentiate a recording stop from a user and a recording stop triggered by the system alone (again because max recording time was reached).
Looking through the server logs for a missing occurence of a stop recording event to detect the actual stop recording action was triggered by the system seems a bit far fetched and not really reliable.
My question, is there a way to detect the system stopped a manual recording because the maximum manual recording time was reached ?
I did the experiment myself, and you get both “Manual Recording Stopped” and “Recording Stopped”. From the experiment I must conclude that the servers when using the “Stop manual recording after” setting to make the stop uses the exact same signal; “Manual Recording Stopped”.
There is no way for you to destinguish between a manual recording session stopping because of the time restriction or because of the user actively stopping it in the UI.
I see no alternative information you can use from the events.
It was unclear to me until I did the experiment, so I am sorry that I did not do the experiment first chance..
Continued the experiment.
If I start recording in the Smart Client using the recording button and stop recording using the recording button, I see both starting and stopping log entries in the Audit Log in the Management Client.
If I start recording in the Smart ClientC using the recording button and stop is governed by the timing, I see starting (but no stopping log entry) in the Audit Log in the Management Client.
I found it valuable to do the experiment, even if I agree that using the Audit Log, with the involved latency etc., might not be a good solution.
That’s too bad the server does not provide a reliable way of knowing what or who triggered an event such as the start/stop recording events…
I guess we will have to find a workaround without the help of the SDK.