Pelco Developer Network (PDN)

Seek timeout

Hi, I'm using Pelco SDK 4.2.1 vs DigitalSentry Server 7.16.69, both latest available.
I've set up 2 IP cameras on continuous recording, playback is fine server side using DS ControlPoint.
With Pelco SDK, I'm not able to stream playback, while live streaming is fine.
SDK-side, I've got this error:

2017-09-12T13:21:49 [INFO] 17092/8332 StreamPrivate.cpp, 402: Seek: 2017-09-12T14:51:45.932541 7/2
Exception thrown: 'System.Runtime.InteropServices.SEHException' in Pelco.SDK.dll
2017-09-12T13:22:51 [ERROR] 17092/8332 StreamPrivate.cpp, 103: DS has failed to seek to the correct time for over 1 minute. Aborting seek.
Exception thrown: 'Pelco.SDK.Exception' in Pelco.SDK.dll

Thank you for assistance,
Fabio

Hello there, thanks for your post.

I'm sorry to hear that you are having trouble with this scenario. To help try and determine the root cause, I have several suggestions that you will want to explore so that you can discover the reason.

This error message you are seeing *typically* is because the video rendering part of Pelco SDK, MPF, has not successfully received video packets. Because you can successfully see Live video being displayed, I will assume that you have the proper DLL version (release/debug), the proper environment PATH set, and the proper build version in your visual studio project. I include this information only for anyone else who sees the post who may benefit.

My first suggestions are to use the Pelco SDK Logging Executable, in the Logging folder, to generate logs. If you run that EXE and check all of the options, you should see two logs be generated; PelcoSDK.log and MPF.log. PelcoSDK.log will show general messages that have to do with operation of the Pelco SDK, and MPF.log will show (in a quite verbose fashion) messages relating to streaming specifically. I would review the MPF.log after the error occurs and locate the same message, or a similar one, about packets not being received or a failure to seek.

Ensure that the correct time is being used for the Seek request. You may need to double check converting to UTC (possibly) and ensure that the time is correct on your DS. Basically ensure that all time information is correct on all ends.

Another suggestion that I would have is to use Wireshark to monitor the network traffic between the DS and the Client where your application is running. Compare successful Live video requests and traffic, where you should see UDP video packets arriving on the client end, to the unsuccessful playback requests. Are there error messages in the SOAP requests that Pelco SDK is making to the DS Pelco API services running on the Digital Sentry? Additionally, is there any UDP traffic being sent from the DS to the Client PC at all?

All of this information should assist you to determine if the root cause is a DS issue, a network or setup issue, or an issue on the client end using the SDK tools.

Using DS Control Point is a good test, however it is important to know that DS Control Point does not make use of the DS Pelco APi service on DS, which is what the Pelco SDK is making requests to.

Additionally, I feel that I must point out that Pelco SDK has not had a new release since Jan of 2016, so therefore we have not had any testing of it since then with more current versions of Digital Sentry.

Hi Chris and thanks for your assistance.
Start by saying that sdk client and ds server are on same clock, and firewall is down on both sides.

Your first suggestion is about SDK logging, I've made several attempts asking for one hour back and 12 hours back.
One hour back results in the "DS has failed to seek to the correct time for over 1 minute. Aborting seek." message.
Twelve hours back results in the "DS has not sent packets within 5 seconds of seeking." message.
In both cases log files contain "DS Seek call appears to have failed. We're at xxx instead of yyy" message.
Here you can find generated log files: https://we.tl/2aeOXgaqGg

Can you help me checking that files?

p.s. Your last words let me worry: there is no certain compatibility between sdk and digitalsentry?

Interesting, thank you very much fhr the logs. You've discovered the problem with these logs.

Specifically in the logs that you sent my way, the error message "DS has failed to seek to the correct time for over 1 minute." points to an issue with the time values. It's possible that the client and the DS aren't on the same times, causing a problem with the time values that are being sent for the Seek request. Because the error messages are off by approximately an hour, it leads me to believe it could be an issue with Daylight savings time conversion, which I have seen in playback issues before.

When you see "DS has not sent packets within 5 seconds of seeking" - this is *typically* (though not always) related to a network issue where not enough UDP packets are received on the Client end trying to get the video from the DS side to render and display the video frames. Often it is a network issue that can be investigated using Wireshark to see if any UDP packets, or perhaps only very few, are arriving to the Client end from the DS.

Regarding your PS message, I did reply to that just below; we don't have a solution for working with Digital Sentry other than the ones indicated, and those releases haven't been updated in some time now.

Regarding SDK->Server compatibility.
We are dealing with this integration because one of our customer claims to have DSSRV2-040 recorders.
At the moment we have no details about versions or firmware installed on.
Is there something I can provide you to let you suggest the correct and "certified" SDK that will work on that machines?

Thank you again,

Sadly, there really is not.

We have not had any new solutions released to work with Digital Sentry since development on Pelco SDK stopped. To write a coded and developed integrated solution with Digital Sentry you will need to use Pelco SDK or the much older releases of DX ConneX SDK. In both cases neither of these have been under active development for a long time.

VideoXpert, and the VX SDK, is the VMS system that we are currently and actively working on development with and for.