Network Packet Loss

tlutrick
edited April 2015 in SecuritySpy
Been reading the messages and playing with settings, and I'm still getting cameras dropping off and going disabled. This always seems to happen when I'm traveling which makes the problem a REAL problem for me. I have a brand new 3.7Ghz Quad-Core Mac Pro with 12Gb of Memory, GigE switch, Cat-6 wiring, and redundant 4Tb Firewire drives and I'm still getting the following messages in the Log:

03-22-2015 0323-16: Error communicating with the network device "Front Porch" 3.1.3,10,835 Excessive packet loss from network device, the network may be too slow or defective, or this computer may be overloaded. Check the network and/or reduce this camera's frame rate.

03-22-2015 0325-10: Error communicating with the network device "Front Porch" 3.1.3,89900,54 Connection reset by peer (ECONNRESET)

03-22-2015 0328-24: Error communicating with the network device "Back Porch" 3.1.3,89900,54 Connection reset by peer (ECONNRESET)

03-22-2015 0332-48: Error communicating with the network device "Back Porch" 3.1.3,10,835 Excessive packet loss from network device, the network may be too slow or defective, or this computer may be overloaded. Check the network and/or reduce this camera's frame rate.

03-22-2015 0334-05: Error communicating with the network device "Back Porch" 3.1.3,70900,800 The operation timed out

I've checked the firmware of the cameras and this wasn't occuring as quickly on the Mac Mini, but it was one of the factors that led me to upgrade to the Mac Pro, but now the problem has gotten worse.

I have not upgraded to Yosemite, but was going to try it, as I don't know if the Pro would perform better with the upgrade.

What else can I check?

Trey

Comments

  • Hi Trey,

    Firstly, I notice that you are using a rather old version of SecuritySpy. Please download and install the latest version of SecuritySpy, as it does have some improvements related to network efficiency.

    Next, check to see if the Mac is in fact overloaded or not. What does Activity Monitor report as the CPU usage of SecuritySpy? How many cores does your Mac Pro have?

    One thing to try would be to reduce the frame rate that the cameras are sending video. What frame rates are you currently using?

    If the packet loss message doesn't happen very often then it's safe to ignore, as it will simply lead to a few corrupt frames once in a while. How often are you seeing this message?

    The Yosemite upgrade may help, so go ahead and install it and see if it has any bearing on the problem.

    Let us know how you get on.
  • Thanks Ben, didn't know about new version and just upgraded. Mac Pro has 4 cores and activity CPU usage is about 23-25%. I upgraded to Yosemite and the Pro locked up today. I am about to go out of town for the weekend for business, so I've reset everything and will watch it over the weekend remotely and report back. If still having problems, then I'll reduce frame rate next. Stay tuned and thanks.
  • Update as of April 24. Updated to 3.4.7, updated to Yosemite 10.10.3, updated firmware to version 5.2.0 based on IP-Talk forum for the Hikvision DC-2CD2032-I cameras...so far the cameras are staying up, though still getting some errors in the log. If anything changes, I'll post it up, but others can at least search this post out.
  • Update June 13...Had to reduce the fps to 25fps, as I was still getting camera dropouts. This is a little frustrating considering that I built a gigabit network to support this level of traffic. So far I'm still getting log messages about losing cameras, and I'm not getting all the footage, but the cameras are not going disabled. CPU usage indicates 69%, but overall user activity is less than 21%.

    I really need to fix this as I noticed some missing footage and that concerns me.

    Thanks Ben
  • Ben
    Ben
    edited June 2015
    Hi Trey,

    When you say the cameras are "going disabled", do you mean disconnecting so that you get blue screens, or are they switching to Passive mode? When this happens, do they come back online automatically?

    So that we can investigate further, please email us the SecuritySpy log file (please attach the file to an email rather than copying-and-pasting, as it can be rather long).

    Also, so that we can check over your settings, please open SecuritySpy and press the space bar three times in a row - a file called "SecuritySpy Debug Info" will appear on your desktop - please email this to us.
  • fwiw, I have a few hikvision cameras and one d-link

    The hikvision cameras always fill up my log with "excessive packet loss" messages, however I have examined the footage many times, and I can not find anything wrong with the recorded footage. I'm not even seeing dropped frames.

    The d-link never gives an error.

    I posted this problem a while ago, and have since come accross other forum threads (like this one now) about the excessive packet loss, it is always about a hikvision camera.

    If your recorded footage looks fine, it probably is and I wouldn't worry about it too much.
  • thanks Petecam. I've been traveling and so far since I went into the camera's ip config and changed them to 25fps, they have not been dropping off and going disabled within SecuritySpy and I can't honestly say that I can tell the difference in the quality of the footage. So that's good. I still have a huge log file being created related to the camera's lost packet. I sent the log files to Ben and hope he can come up with something.
  • It's strange, we've seen the packet loss message with certain cameras (e.g. Hikvision, ACTi) but never with others (e.g. Axis, Canon). The RTP media packets coming into SecuritySpy are all numbered, and therefore SecuritySpy can detect when packets are missing and will report this error. This typically means that a chunk of data has been lost (perhaps part of a video frame) and that there will therefore be a small amount of video corruption. But it could also mean perhaps that the camera is not numbering the packets correctly, and in fact there is no video loss. If you aren't seeing any corruption in the captured movies then I think it's safe to simply ignore these warnings.