We are sending a request using the ImageServer protocol with using the alarms methodname xml:
We don’t get an response error, but continuously receive 0 bytes, even though we know there are alarms in the given timespan and this only happens intermittently. What can be causing this issue?
Additionally, what does 0 bytes represent? A timeout or no found alarms?
Alarms on the Image Server protocol is an old deprecated interface that gave recorded sequences NOT alarms. Documentation reference.
The Alarm List sample shows how to get alarms using Alarm Command service.
The RESTful Alarms API - Python sample shows how to use REST / API Gateway to get alarms.
Thank you Bo for the response. Yes, I meant that we are trying to get recordings, not alarms. The issue is that 0 bytes are present in the response. We are using python’s socket library with the ImageServer protocol xml requests and are able to get recordings from other accounts. We are wondering what the 0 bytes in the response means. Can you help us understand that?
Please switch to using the RecorderCommandService SequencesGet a.o. I know that Milestone stopped using ImageServer Alarms when the RecorderCommandService was created.
Thank you Bo for the suggestion. We were wondering why specifically here, with the current command, we are getting 0 bytes; this system has 100 cameras on a single recording server. We monitor much larger recording servers and much larger installations where we do not see this issue of 0 bytes from this command elsewhere. This specific server seems to be slower than others, so we were wondering if that could be contributing to the issue. Usually we see Milestone give a ‘400 Database Error’ or another error response string if there is an issue and here there is no response string, which we found to be puzzling. Migrating our integration at this point across all our installations is going to be challenging, we are hoping to resolve whatever issue there may be with this command on this system.
I’m wondering if the camera is configured for continuous recording. I vaguely recall that sequence handling could behave oddly when there’s no gap in the recording (might be misremembering, but “record always” — or potentially “record never” — could be a contributing factor).
Also, I’d be curious whether you see the same behavior using the newer approach. If you’re up for a quick sanity check, running the Sequence Viewer plugin sample unmodified would be an easy way to confirm whether it’s environmental vs. code-specific.
Hi Bo,
We tried implementing the new approach using the SOAP API’s RecorderCommandService SequencesGet command, but are seeing the same behavior. Do you know what else potentially could be causing this issue?
First, a key question:
When viewing the camera in Smart Client playback, does the timeline populate as expected (red recording bars)?
If the Smart Client — as the reference client — does not show sequences in the timeline, then we would not expect the APIs to be able to either.
-
I think I’m missing some feedback on my previous post.
Could you confirm whether the Sequence Viewer plugin sample, used unmodified, shows the same behavior?
And finally, what are the recording rules for the camera? Is it default record on motion, or something else?
The camera recording is continuous. We cannot use the sequence viewer, because we dont have direct access to the system. We do however see the continuous recordings in the recording area in the VMS.
Hi Bo,
Just to confirm, is there any tests we can do to diagnose the issue further if we don’t have full access to the system beyond API access?
Is there anything you would suggest could be the cause of these empty responses with the RecorderCommandService SequencesGet command?
Thank you