Random disconnect failures (Foscam FI8905W)

[aufrex]

I have experienced random disconnect failures with my cameras ever since I installed them and started using Sighthound. Restarting the camera doesn't work, restarting the network adapter doesn't work, troubleshooting with your system doesn't work, restarting the computer doesn't work. Often camera comes back on its own, however, latest failure has persisted. Not a camera or network problem, because camera is on and can be displayed on other computers on my network. May be a coincidence, however, I have noticed that Firefox crashes are often occurring around the same time as camera connection failures. Only one of two cameras fail to connect. Second camera views okay. Also found multiple instances of Sighthound running in the background, even after Sighthound is closed.

[aufrex]

Disconnect problems persisted, and other programs on other machines on same network, had no problem monitoring both cameras, consistently. Therefore, I installed Sighthound on the other computer, in case it was the network connection to the first computer that was the culprit. Well, after running on the second machine for a day or so, it has lost contact, consistently, about ten (10) times, and loses it every time I click on one of the monitors. Other monitoring program on this machine shows both cameras without a break - no disconnect, no issues at all. Therefore, I must conclude that it is the Sighthound program itself which is mucking things up. Maybe a clean re-install of the program will help. Any suggestions?

[Semper Vaporo]

I have two different brands of IP cameras (neither is a Foscam) and both exhibit a loss of connection at times. A TrendNET brand cam does exhibit a regular loss of data at 355 seconds (5 minutes 55 seconds) as well as what seems to be at totally random times that occur sometimes a lot and sometimes not. The dLink camera also exhibits a random loss of connection, but I have not determined any regularity to it.

To SEE this loss of data, run Windows "Task Manager" and select the "Networking" tab. You will see graphs showing data transmission for each of your network connections to the computer (wired, WiFi, etc.). Scroll the window until you can see the one that is in use (you might see 3 or 4 graphs but only one or two will be actually in use) This graph will have a sort of squiggly line that will vary somewhat based on the complexity of the scene(s). But you will notice some dips in the line associated with a loss of data transmission. Each application on the computer that is accessing the camera (SightHound is one, and you could also have a browser showing an image from the camera) will be a part of the total amplitude of the graph. Shut one program off and the amplitude will drop by 1/2. Connect another program and it will go up by a certain amount (the actual amplitude will depend on the resolution and data compression requested by all the programs accessing the camera).

When I have only the TrendNET camera on-line the squiggly line is very uniform except for the 355 second dropouts and sometimes a much more often series of dropouts. And if 2 programs are accessing the camera at the same time, the 355 second dropout will occur to both at the same time... the more random dropouts will not occur to both at the same time

With only the dLink camera on-line the graph line squiggles a whole lot more (based on the brightness of the scene as well as the complexity). It also exhibits dropouts, but they are usually much shorter in duration.

It appears that SightHound is more sensitive to these dropouts than other programs that access the cameras. If I am monitoring the camera (especially the TrendNET camera) with a browser at the same time, the browser's display will show a short freeze in the image, but SightHound MIGHT decide that the camera has died and go through the "Disconnected"/"Connecting" sequence, or it might not. SightHound does not seem to have as much of a problem with the dLink brand camera, even though the dLink seems to have many more drop-outs at times.

"MY" assumption (as a user of SightHound) is that there is some asynchronous nature to the software sending the request for the next scene and the camera being in a state to accept the request and if the timing is such that the camera is not ready (for whatever reason) then no frame is sent and SightHound starts some sort of timer and if/when that timer runs out, it declares that the camera is off-line and has to go into the reconnect sequence, whereas other programs either don't have a timer and just keep requesting a new frame while showing the last one over and over again (image freezes), or have a longer time-out before it declares a problem.

It is possible that the Time-Out is within SightHound's control and possible that it is a function of something in the system such that SightHound would need to handle the time-out differently than presently done. I can understand that SightHound would be more sensitive to such drop-outs whereas a browser would not care... the Browser assumes you are the only reason it is accessing the image and you will determine what to do if the scene stops updating, but SightHound is running without a human looking at the scene and so much decide what to do and maybe it is a bit too sensitive to these random short term drop-outs.

I wish I had some "fix" for you, but I think all we users can do is request that the SightHound team look into this a bit more. I wonder if there might be some setting that we users could access to change the time-out parameter on a camera by camera basis so we could extend the time and possibly reduce the number of "Disconnects" without screwing up the motion detection operations.

[aufrex]

Semper Vaporo:

Thanks for the input, and I think you are absolutely right about the manner in which Sighthound handles drop-outs - it assumes that any, temporary drop-out is a permanent disconnect. Other monitoring programs when run side-by-side with Sighthound, don't cut-out when there is a data interruption - they keep up the most-recent image, and wait for the data to catch up or re-connect. Sighthound, however, appears to operate on the assumption that all data cut-outs or slow-downs, no matter how brief, are camera or network disconnects, and immediately moves to reset mode.

Sighthound should come up with some sort of firmware or software update to address this problem. However, I won't hold my breath.

[mennamorato]

same issue with my 2 Dahua IPC-HFW4300S IP cameras. they will be working fine then all of a sudden i look and both are disconnected. what i found is if i "Turn off cameras" from SH then turn them back on they reconnect.

So.. SH folks.. seems like many people see this problem. When is it getting fixed?


or anybody else? got any better suggestions? (and don't bother with SecuritySpy, while more stable than SH it has many other issues) maybe time to go for to all cloud-based solutions and skip the local sw installation?

Mark

[ryan]

We don't handle any temporary drops as a permanent disconnect, we strive to reconnect immediately, and perpetually attempt to reconnect albeit at a longer pause to save resources if the connection attempts are perpetually failing (falling back to attempting to reconnect 1/minute in the longest case). There should not be any difference between this constant attempt to reconnect and turning the camera off and on in the user interface. If you are experiencing trouble with your cameras please submit a bug report from "Help->Report a Problem..." and perhaps the logs will indicate what could be occurring.

Best,
- ryan

[diego.castronuovo]

Foscam WIFI disconnect solution is very simple.
Change WIFI security authentication to WEP, don't use WPA or WPA2 !
WEP is not the best but it solves the problem.

Regards
Diego

[alecm]

Hi,

would this (using WEP rather than WPA) fix the issue I have where I have POE cameras running off a switch that is connected to my Wi-Fi extender, and only way I can connect is to have a laptop wired directly to the POE switch....then another laptop in the house on the home Wi-Fi will connect, and hold the connection as long as no network drops but when they happen, if wired laptop has been removed, no connection possible until wired connection is re-established?

cheers