Skip to content

Camera loses connection and reconnecting every minute

edited March 2014 in SecuritySpy
Hi!
I did try to go through the forum, but did not find anything.
OK. I've got me a camera off eBay
http://www.ebay.com/itm/281249302996?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649
I think it has Sony chip. Works fine except one thing - it loses connection with SecuritySpy every 40-60 seconds for s second and immediately reconnects.
At the time of signal loss all MD is suspended. It only supports ONVIF device type.
I use H.264/5fps/1080P/VBR/12 iFrame Interval/Baseline in camera settings.
SS I use RTSP and no decompression on both video and audio.
MD capture I use the same 5fps.
Did try many different camera settings - the same result.
In windows setup software I see constantly nice image from the camera. Could it be that some settings are not exactly match what camera sends and SS receives?
I would appreciate any ideas on how to make image steady.
Regards,
Mark

«1

Comments

  • I have the same issue. I use four cameras, two older JPG-type ELRO C800 IP (connected to the WLAN via a repeater) and two new Wansview H.264. All cameras show the same symptom - they connect, stay connected for some time, then report a time-out, try to re-connect and then the cycle starts again. Therefore I also do not think it is camera-specific. Any help would be highly appreciated.
    Regards,
    Thomas
  • Some cameras have a timeout value of around 1 minute, and will disconnect the feed unless the client sends regular "heartbeat" messages to the camera. SecuritySpy does send these heartbeat messages, but it's possible that something may be going wrong with this mechanism.

    Can you tell me if the disconnects happen consistently and regularly (i.e. always exactly 40-60 seconds after connecting)? If so then this points to a potential problem with these heartbeat messages. If however the disconnections are more sporadic and unpredictable, then this indicates a network problem instead.
  • Hi Ben!
    Well, just timed the cameras - it's exactly 2 minutes (sorry for the earlier figures).
    I also setting-up the 4 camera system for my neighbor with SS and testing his system right now. All 4 cameras (the same ones I have) doing this in sequence. They all PoE and I hook them-up with 30 seconds interval - they go off one after another as a clockwork.
    Network topology is: PoE switch that hooks-up 4 cameras, Mac Mini and one wire connecting to the rest of the house. Cameras throwing 750kbps traffic each, so 100Mbps should be quite capable of handling it.
    I am under assumption that all 5 cameras can not be bad. They do that even when I am connected to them from the windows computer where image is always steady.
    Regards,
    Mark
  • Hi Mark,

    If it's a very regular disconnect exactly every two minutes with an immediate reconnect, then this does sound like a problem with the heartbeat messages. I'm pretty sure SecuritySpy is sending them correctly, otherwise we would have heard this problem from lots of users, and this is the first we've heard of this with any camera.

    There are two types of heartbeat message depending on the method of transport protocol used for the media streams (TCP or UDP). By default SecuritySpy will use TCP whereas other software may use UDP. It's possible that the camera doesn't correctly implement the heartbeat messages when using TCP transport: this may account for the difference between SecuritySpy and the other software you are referring to.

    So, I have added an option to the ONVIF profile in SecuritySpy that allows you to choose between TCP and UDP transport for the media streams. This option is in the Format menu in the Video Device Settings window. I have emailed you directly with a link to a beta version of SecuritySpy with this feature that you can test. So try setting this to "RTSP UDP" and let me know if this resolves the problem.

    Thanks.
  • Ben,
    Beta version you've sent works like a magic! No more disconnects on all 5 cameras for 7 minutes and counting.
    Works as you have predicted. I changed to RTSP UDP and cameras sending rock-solid pictures.
    Unbelievable! Thank you for addressing the issue and fast response!
    Regards,
    Mark
    PS. By the time I am finished with this post - 15 minutes all parameters are normal.
  • Just tried setting one of the cameras to RTSP TCP transport and sure enough glitches started every two minutes for this camera only.
  • Hi Mark - great to hear it's resolved with the UDP setting! This addition to SecuritySpy will be included in the next update which will be released soon (but for now it's fine to continue to use the beta version, it's fully functional).
  • Thanks Ben once again!
    Here is a small addition to the problem, I do not know weather it is related to the original issue or not.
    Camera, I'd say once in 10 minutes or so gets some sort of greenish mask over the image for 5 to 20 seconds and then image is back to normal in SS.
    You can distinguish the picture through it but barely. It pops-up on all cameras I am checking right now. At first I thought it might be due to a low light at night but it did not change with a Sunrise.
    I fired-up a windows software in parallel with SS. While SS screen shows greenish mask - it's all normal in windows software.
    Do you think it may be related to the UDP transport or some sort of string that is missing?
    If you can provide some help in checking string for WireShark I can check the packets that go to windows machine and my Mac.
    Regards,
    Mark
  • Just got a RTSP string from the camera seller:
    user=admin&password=&channel=1&stream=0.sdp?
    add your password to the string.
    It works with manual camera setup.
  • Ben,
    Checked packets with WireShark coming/going on Win software and SecuritySpy.
    Windows uses dhanalakshmi protocol over TCP.
    That could be the problem when UDP used be SecuritySpy.
    Is there any chance something could be done? I can post WireShark logs.
    Regards,
    Mark
  • Hi Ben,

    I have the same issue, about every 1min 20secs or so it disconnects for a couple of seconds, my camera seems to only run on RTSP-over-HTTP, I've downloaded 3.3 and tried it on RTSP UDP but I just get a connection error, is there no hope for the HTTP only cameras?

    Cheers
  • Hi Mark,

    Unfortunately UDP is an inherently unreliable protocol, as it does not guarantee delivery of the data packets. It's designed for live video streaming, where dropping packets is preferable to delaying the video stream. If there is any temporary network problem or bandwidth restriction (e.g. another device is using a lot of network bandwidth), then some UDP packets could be dropped, which results in the green images you are seeing.

    You say that the Windows machine uses TCP transfer. If you aren't getting the 2-minute disconnections, then the Windows software must be implementing the heartbeat messages in a particular way to be understood by the camera. Do you have contact information for someone at the manufacturer who could answer technical questions about this? If so can you please send me these contact details and I will contact them directly.

    By the way, WireShark may report the name of a particular protocol (e.g. dhanalakshmi) that is typically used on a particular port, but in this case it's simply that the RTP connection uses this port. WireShark is just trying (and failing) to be helpful; the connection has nothing to do with the dhanalakshmi protocol itself.
  • Harmony: can you please tell us what make/model camera you are using?

    Do you get the disconnection every 1:20 exactly and consistently?
  • Ben,
    I learned some details about the camera. It uses IPG-53H20PL-A board with sony sensor if it helps.
    Also I send email to the factory in China asking for SDK. Hopefully they'll answer.
    Contacting ebay seller for email or phone contact so far did not bring any results.
    Websites I have found with information on boards:
    http://www.dvr-ipcameras.com/china-h_264_encoding_1_3m_cmos_ip_camera_module_with_720p_g_711-1852689.html
    http://www.pcbboard-assembly.com/china-2mp_cmos_custom_pcb_boards_ip_camera_module_electronics_contract_manufacturing-1803223.html
    I took one camera apart and made-out a model on the board. I'll take some pictures of the boards Tomorrow.
    Cheers,
    Mark
  • Ben,
    Got an answer on ebay - they say post your question VIA ebay message system (so nice of them).
    Is there a question I can relay to them?
    Mark
  • Hi Mark,

    The question is basically: when using interleaved TCP transport, where the media streams are sent over the same TCP connection as the RTSP conversation, what does the camera require from the client for "keep alive" / "heartbeat" messages, to prevent the server from closing the connection?

    SecuritySpy sends "RR" packets every 40 seconds or so, which is the standard method, however the camera doesn't seem to respond to them.
  • Done, posted. As soon as I get an answer - I'll let you know.
    Regards,
    Mark
  • Hi Ben!
    I am not sure weather my seller going to respond or not. I think similar issue was reported in VLC community:
    https://trac.videolan.org/vlc/ticket/1881
    I have learned that my camera built on 53H20L platform and DSS on Hi3516 chip (by taking the camera apart).
    It is my understanding that ( and I could be wrong) DSS in not using RR packets. Instead it utilizes KA packets over a media port (34567).
    I am sure you probably have worked on cameras with similar network supports.
    There is a bunch of cameras coming-out on the market with this particular hardware (Chinese factories are in production test run right now for 200,000,000 units to test the waters).
    Regards,
    Mark

  • Ben,
    Just found this:
    https://trac.videolan.org/vlc/ticket/1881
    Do you think it is related to my issue?
    I have no answer from the seller.

    Cheers,
    Mark
  • Hi Mark, thanks for the links and apologies for the delay in replying - the forum spam filter marked your last two messages as spam and I didn't initially notice. Unfortunately forums get loads of spam and the filters have to be quite sensitive. A sad fact of modern internet life :(

    As you can see from the discussions there is quite a bit of confusion around what is the "correct" mechanism for sending keep-alive messages, and this can vary between manufacturers. SecuritySpy uses RR packets because from our research this is what most cameras support. Conversely, using RTSP requests for this purpose (e.g. GET_PARAMETER) over an interleaved TCP connection while the media streams are being transmitted would give undefined results. In this situation it is conceivable that it would interrupt/break the streams of some cameras. RTSP requests require replies from the server and this is impossible while the server is sending the media streams over the same connection!

    Anyway, I have emailed you a link to a modified version of SecuritySpy that uses GET_PARAMETER as the keep-alive mechanism, even over an interleaved TCP connection. Please let me know if this works for your camera.
  • Hi Ben!
    Thank you for update on software. I downloaded it and it has been a rock-solid image on all cameras using ONVIF, RTSP TCP (video and audio) settings.
    Thank you very-very much. This thing have been bugging my brain since I bought the cameras. Was thinking of returning them.
    Just a note: Your software is really cool! I used your AppleScripts pre-sets and changing sensitivity of the cameras based on the day light VIA Perl daemon. Really easy to automate.
    Thank you once again. You are the man!
    Best regards,
    Mark
  • Ben,
    I little update. Everything works fine, except - once or twice in an hour I am getting a green mask on two out of 5 cameras.
    This convince me that it should be associated with cameras firmware, otherwise it would've happened on all cameras.
    Cheers,
    Mark
  • Hi Mark,

    Great to hear it's working better with the modification. TCP is a more reliable transport than UDP so I'm not surprised it's a more consistent stream now that the "keep alive" messages are being interpreted correctly. Unfortunately this modification won't make its way into the release version of SecuritySpy because we can't guarantee what this change will do to the thousands of cameras that are currently working under the current scheme, but if you want to upgrade your version of SecuritySpy in the future simply email me and I'll generate you a custom version with this modification - it's easy to do.

    With the green screens, is it two particular cameras? In that case I think you may be correct about a firmware issue. In low bandwidth situations we have seen that some cameras transmit partial frames, resulting in these green anomalies. You could try reducing these camera's frame rate and/or checking/upgrading the network connection between the camera and the computer.

    All the best!
  • Hi Ben!
    Like I have mentioned earlier - I use dedicated switches between Mac Mini/Mac Pro and cameras (100Mbps switch) and use 5fps framerate with "good quality" settings (as opposed to "better" or "best"), H.264 compression 1080P which results in 765Kb/s bit rate each while maintaining very good image quality.
    I have no network issues (as far as I can see) as nothing else hooked-up to the switch. So any issues are likely a camera hardware/software issues.
    My datastream is small enough to write all 4 cameras VIA USB3 onto a HDD. USB connection offers on average 60Mb/sec write speed with bursts of 90.
    Testing cameras overnight (yes, I am a programmer too) I can say each camera went into the green mask mode no more than 5 times each, which is much better than every 5 minutes before. In my book it is quite acceptable.

    I would be nice if SecuritySpy had capability for custom settings (i.e. VIA API or if it can read custom settings file) so hackers can hack a hackable portion of the software without trespassing on your Copyright. Just a thought.
    Regards,
    Mark

  • Hi Mark, sorry you did mention your network hardware before. In that case it won't be your network at fault.

    Unfortunately this kind of stuff is hard-coded into SecuritySpy itself, there isn't much demand to make all these small options configurable by some sort of settings file.

    Hopefully the green screen issue isn't too much of an annoyance, and hopefully the manufacturer will at some point release some firmware which will fix it!

    All the best!
  • Hi Ben,

    I have the same problem of lost connection with the RTSP stream with a Cybernova wip604mw.

    It happens every 30 seconds exactly. SecuritySpy looses connection, blue screen then reconnect automatically. The VGA MJPEG stream is not affected.
    I've tried with onvif profile, maygion, wansview, manual profile with the RTSP url stream... always the same deconnections.

    If I open the RTSP stream with VLC, it works perfectly, no lost connection.
    Same under the webcam web interface.

    as I read above that "SecuritySpy sends "RR" packets every 40 seconds or so", could it be related ?
    Does VLC work because of its GET_PARAMETER keep alive method ?

    Thanks,

    Didier.
  • Skull,
    I learned the "hard way" that not everything depends on SecuritySpy. In my case it was an old HDD that gave me a crips. Download a free "Blackmagic Disk Speed Test" and check you HDD access speeds. Just google it and it'll pop-up.
    I replaced the disk with brand new one and SecuritySpy went to normal. Old HDD had 70Mb/sec write speed, new 199Mb/sec.
    All of the above could be true if your network topography designed properly and you have no bottle-necks in it.
    Cheers,
    Mark
  • Didier - if the camera is disconnecting exactly every 30 seconds then it certainly sounds like it is purposely closing the connection due to lack of a "keep-alive" message from SecuritySpy. We have never seen a camera that does this more frequently than 1 minute, so this is highly unusual. SecuritySpy sends these keep-alive messages every 40 seconds, which is apparently not frequent enough for your camera. I have sent you a link to download a test version of SecuritySpy that sends the messages every 20 seconds instead - please let me know if this fixes the problem.

    FYI, there are two different options for RTSP when using the Manual profile and the ONVIF profile: TCP and UDP (because some cameras work better with TCP and others with UDP transport). In TCP mode, SecuritySpy sends RR packets as the keep-alive message; in UDP mode, SecuritySpy sends GET_PARAMETER messages. This is the standard way to do it.

    Mark - thanks for the tip of using Blackmagic Disk Speed Test, this is a great idea for anyone who suspects potential hard drive problems to check the speed of their drive.
  • Hi Ben,

    That was it! The version you sent me keeps the RTSP stream alive, no lost connection.
    I've using the Maygion profile as it gives PTZ compatibility also. The Onvif profile works the same way but is way slower to initiate the connection (was like this before).

    Maybe you could add this keep alive time parameter in the option settings for a future release, would be useful I guess for users to set it up as they need.

    For Mark, thanks for thinking of HDD speed problem.
    I'm using a dual SSD Raid0, so that was not the issue.

    Thanks again.

    Didier.
  • Didier - great to hear that. For maximum compatibility we'll keep the keep-alive frequency at 20 seconds from here on. I don't really want to add it as an option, as most people wouldn't need to change it so it will just clutter the user interface, and it really shouldn't be the case that there are any other cameras out there that require a more frequent keep-alive message than this!
Sign In or Register to comment.