For example, I’ve recorded an event at 2020-11-23 10:00.000am, how long do I need to wait to get this recording info by calling
http://www.onvif.org/ver10/search/wsdl/FindRecordings
and
http://www.onvif.org/ver10/search/wsdl/GetRecordingSearchResults
Thank you,
Hi Cheng,
Could you elaborate a little bit more about what you exactly experience ?
Don’t you get any recordings at all ?
Or you just don’t receive the last sequence ? And in particular if the last recording (sequence) is still in recording at the end.
And could you provide a trace of the FindRecordings command ?
You know you have to provide specific parameters in it, right ?
Needed parameters for FindRecordings are discussed in this thread.
Hi Petar, sorry for rousing this thread. I know i need provide parameters. Actually what i asking is the VMS recording system delay issues. How long is the delay ? as in how long the recording system need recording the video into database?
Hi Cheng,
Unfortunately I’m not sure I understand your question quite well.
Please rephrase or elaborate on your question.
Let me try to rephrase this, let’s say that I want to make a Milestone VMS API call to retrieve the recording between 10:00am to 10:05am for archival purpose.
My question is how soon may I make this API call? Because I had prior experience with other VMS where they require some time (e.g. at least 2 minutes after 10:05am) to finish writing the video segment recording to disk before the video segment would be available.
Hi Cheng,
In general, this information should be available within a seconds, after the sequence was created.
And I have in mind between 2 and 5 seconds.
However, there could be an exception in this rule/behavior when you are asking for the last recording sequence and the recording operation continues.
In that case you have to be sure that parameters that are provided in a filter exceed the “current time” with at least few seconds.
I’ll repeat the structure of the filter value:
XPath expression,timestamp,maxTimeBefore,maxCountBefore,maxTimeAfter,maxCountAfter”
Another source of problems could be Local time to UTC time conversion. Please bear in mind that the timestamp in the filter is in UTC time.
Common practice, when the client wants to get the last recording, is to be specified timestamp as “now + 1 year” for example, very big value for maxTimeBefore (obviously more than a year) and 1 for maxCountBefore. MaxTimeAfter and maxCount after could be set to zeros (0).
With this technique could be work-rounded both of previously described sources of problems.
Great! Thank you for your help.