Pelco Developer Network (PDN)

Ds error

Pelco Ds service recorded region error

Hi, I am using Pelco SDK to reach recorded videos from Pelco DS.

When Iam trying to get recorded videos, in the function of 'seek' I got -DS has not sent packets within 5 seconds of seeking- as an error.
Network video recorder's, camera's and host pc's all have the same utc, time zone.

Is there any solution for this?

Thank you.

Hello there, thank you for your post. I'm sorry to hear about the issue that you're having.

Typically that message from the older Pelco SDK was generic in nature to indicate that video packets were not properly arriving in order for them to be rendered. The most common reason that we'd see those messages were related to network issues; either delays (latency) or incomplete video data, perhaps.

From the perspective of the DS and the Pelco SDK, I can tell you that no further development is planned from Pelco -- the members of the teams that developed Pelco SDK are no longer with the company (except for 1 or 2 of them that have moved to other projects), so it's no longer supported and definitely no longer being developed. I used to answer questions related to using it, which is really the only reason why I remember what that message typically often meant.

I would suggest troubleshooting from a network perspective and try to use Wireshark data, and information from the Digital Sentry (maybe logs there can be helpful), to try and identify the root cause. Attempt to determine if any video packets are arriving to the client end from the DS. If they are arriving, perhaps attempt to determine if they are full video packets or not. Part of the problem with the older Pelco SDK is that streaming was entirely encapsulated within, so there could sometimes be little to go off of related to the video pipeline. The MPF.log was really the best and only source of data -- and since you've found that message in there I suspect you've already seen that log.

I'm sorry that I couldn't provide more help and insight, but perhaps this information will help to get you looking in the right direction.

Thanks for answer.

We are looking into deeper with wireshark and logs .

Sounds like a plan.

About logs

I try to look logs but it seems same error in logs. I tried from local computer and it gives same logs. Furthermore following logs are gotten from local computer.
Any help will be masterpiece for us.

Edit; I added 2 txt file, when I try to edit my comment I can see them but in preview or after I saved comment, they are not available.
So this is ling for logs;

[Admin edit: here are the attachment links: MPF.log_.txt and PelcoSDK.log_.txt. Please refer to this post on Post Attachments - it is strange how they work]

Hello, sorry to hear that you're still having trouble and having a hard time pinpointing what the root cause is. I've edited your previous post to make the attachments accessible and linked the post that describes how to do that (it is NOT intuitive, unfortunately).

I did look at the attachments. Unfortunately PelcoSDK.log doesn't really give us much ... but MPF.log does. I do see the same 5 second error, which typically means that the MPF video pipeline that the old Pelco SDK used isn't receiving any or enough video packets and data to render and display the video. One part of the log that does contain some fairly valuable information is this section:

Object "SourceEnduraMO" now accepting parameters.
Parameter Value
rtp_source_port 60010
rtp_channel_number 114
presentation_time_max_latency 250
rtp_max_packet_queue_size 4194304
Object "SourceEnduraMO" finished accepting parameters.

In that, it indicates that the source address is the same as the destination address ... and that looks abnormal to me. It has been a -very- long time since I've done any support for Pelco SDK (in fact, we don't support it any longer - but I would like to help you get this working...), but this doesn't seem to right to me. Typically what I'd expect to see is the source address is a camera or recorder, and the destination IP address is a client PC that is different. I can't recall ever seeing where these are the same IP address. That may be something worth investigating.

The port of 60010 on the DS tells me that this attempt is to try and obtain live streaming video from a camera on the DS. Playback was typically using port 60002, if memory serves ... which I do see in the log as well in this section:

 Object "DSPlaybackMO" now accepting parameters.
     Parameter                                     Value
      rtp_source_port                              60002                        
      rtp_channel_number                           114                          
      rtp_source_camera_udn                        uuid:4d4dd67a-f56f-43ff-8ca4-aea81b523d49
 Object "DSPlaybackMO" finished accepting parameters.

Shortly after this specific bit of text in the MPF.log, I see the SOAP requests to VideoOutput to query for the video to get a session Id and request streaming. In that request, I did find the start and end times:


Also in this section, I see the transport URL ... this is the IP address and port that the video should be getting sent -to-:

Using transportURL: rtp://

Now, port 60008 is typically in use by the DS services, so that seems unusual to me as well. When we combine this with the fact that the source and destination are the same IP addresses, I'm beginning to think that this code is running on the same PC / hardware that the DS install is running on. That's pretty unusual ... I've never heard of that kind of setup. Typically, in my experience, installs in the past had a Pelco DS box (or hardware) running to create the VMS system, and a client PC elsewhere on the network, which had the client software that ran the Pelco SDK attempting to stream the video. Usually we'd see a source IP as the DS (or Endura would be a camera for live or the recorder for playback), and the destination IP would be the client's IP address.

Following the VideoOutput Connect and Query SOAP requests, then I see the expected StreamControl requests. First I see Seek; to 30 seconds after the start time and before the end time, (startTime> (please keep that in mind too).

Thank you for answer.

Of course real setup is not working on the same PC with DS installed, but for eliminate network and switch problems we use demo on the PC which DS install is running.

I'm not sure that I completely understand what you've said there.

Another thing to consider is: Is Live video working at all?

If yes, it may be narrowed down to some kind of playback issue (is recorded video available at the time being requested? is there some sort of time value problem?) ... things specific to playback.

If no, it might be a port blockage problem, or another kind of setup problem with the system or network.

I wish that I could offer more help to you ... but we don't have support for Pelco SDK, and DS is going end of life as well. You may need to reach out to Pelco's support channel for further additional assistance.