No HTTPRequest action on LostConnection event?


#1

Hi,

I am testing NCS events/action and I noticed that NCS seems not trigger any action on LostConnection event that look same problem reported here for which I see no final answer, first I thought the Action may not be written in Event log so I sniffed network but saw no outgoing HTTP request to the camera.

http://community.netcamstudio.com/t/event-type-sourceconnectionlost-in-rule-manager-is-not-working/1274


#2

Hi,
This matter is to start with taken care of and fixed here Watchdog for lost camera communication
-Henrik


#3

I already saw this thread but my camera is still listening HTTP requests (I can do it manually thru a web browser) and I know the problem is that RTSP server is down (so no more listening to any RTSP request and no “out of socket” problem) and as I said NCS is not sending any HTTP request and I sniffed network activity to be sure.

By the way if NCS trigger an action shouldn’t it write it into Event log ?

But if the answer is “restart NCS” then this is a bug.


#4

I have figured out where it comes from. Is there is a valid last frame (a frozen frame) then the event will not be triggered.

Will fix that for 1.6.2


#5

cool but it is a bit weird to understand because NCS show the Lost Connection in Event Log so it is aware it lost connection but it do no trigger the Action ? so there is some function between Event and Action that do something else before triggering the Action and may not do it if last frame is valid ?


#6

The rule manager is not linked to this “internal” event. This one happens all the time and NCS will only trigger the rule if there is no image arriving for more than 30 seconds. If it manages to recover by itself in less than 30 seconds then won’t trigger the rule.

Also the rule will trigger only once until an image is again received and again then lost for more than 30 seconds.


#7

OK now I understand :slight_smile:


#8

Should be fixed here:


#9

great … testing it right now…


#10

guess it works :wink:

edit : I tried to “shake” it a bit by manually killing the RTSP process of the camera… so far so good, both cameras has been restarted thru the HTTP request (by the way for Xiaomi Xiaofang it is http://ip_of_the_camera/cgi-bin/scripts?cmd=start&script=20-rtsp-server

edit2 : I just noticed the Event log icon change when new event appear nice thought :slight_smile:


#11

After some more testing it seems that the Action is not always triggered, as you can see it is detected as DeviceLost but I see no HTTP Action called.



#12

Again:

The rule will be triggerd only when no image received during 30 seconds (should be visible in ui by habing the connecting screen again).

At this stage it will trigger the rule.

After that the rule will not be triggered anymore until the source is reconnected and lost again


#13

Yes I understand they are not linked I just put those screenshots because they are easy traces to show.

I tried to look at full log file and noticed a few things that may help to understand or figure out why it did not work.

First camera lost event is 00:54:36 then HTTP call triggered at 00:56:51 so this is 2m15s after first DeviceLost event that is much more than 30 seconds (don’t want to be finical I don’t really care if it trigger 30s or 1min later, but may be this is important for you to know it did not trigger after 30s as you said).

Before the HTTP call the events showed a loop of two lines (I did a copy/paste into excel to move the time column to the left because having a log with the timestamp not being the first column is a bit unusual).

Then came the Rule trigger

Note that the called rule produced en error as I changed IP of the camera from .20 to .69 and forgot to change the HTTP call parameter so this error is “normal” and it’s on me but I didn’t noticed it immédiately.

Then the event log changed a bit adding “WakeUp” events in the loop

Once I noticed I made a mistake in the HTTP parameter I fixed it but however the HTTP call never played again so I restarted the RTSP server inside camera manually.

So question is, is it normal the HTTP call triggered only once ? is it because it returned an Error that it stopped trying again later or should it have retried later anyway (whenever it is not the case here befeore it was a “real” error due to bad parameter, it could be temporary error so it should retry anyway every xx seconds) ?


#14

Hello,

The event will occur 30 seconds later at the condition that images are requested (so that the camera is awake) by any module such as
web client, motion detection, recording or ncs itself by just displaying the camera’s stream.

If nobody requests images, netcam studio consider the source as just sleeping and will try to wake it up once somebody needs an image.

From there is should start counting and if 30 seconds later an image is used and none was received then it will fire the event.

The wakeup event also is linked to this and it means a module wants an image from a camera that is either sleeping or disconnected (as netcam studio disconnects cameras when they are not in use) and tries to reconnect it. it’s not doing this check on cameras which are sleeping and i suppose it’s why in your case it took 2 minutes. Just redo the test but constantly leave the stream in single view in Netcam Studio itself, do not let the camera go to sleep, it goes very fast in sleep like after 10 seconds without activity I think.

And yes it’s also normal that even is fired only once because the state will be reset only once the camera has been reconnected and provided an image, as long as it’s not the case the source connection lost will not be fired anymore since the connection cannot be lost without being first established (and in most case I suppose that people being notified about this do not need 10 emails or push saying the exact same but on the other end if it has been fixed and is lost again then it will notify).

hope it clarifies a bit but to me everything seems normal on your system as well.


#15

Well in my case motion detection was active and I was also in multi-view seeing the switch between blue/red failied/retry screen.

But I think I get the point so SourceConnectionLost is only triggered once and will never trigger again until some “ConnectIsBack” and they it will re-arm the SourceConnectionLost that can trigger again if a connection is lost again.

But here you have a weak point and in my case it is obvious.

Let’s consider video source connection is lost, so after some time the SourceConnectionLost is triggered and here we have two scenarios for the Action attached to this Event :

  • Case #1 HTTP Call is done with only purpose to call some URL that will warn/notice about the connection loss (write it into a database, activate some SMS gateway or whatever).
  • Case #2 HTTP Call is done to try to make RTSP connection work again (my case trying to call some RTSP service restart WebAPI of the camera)

Now if we consider Case #2 if for any reason this HTTP call fail (HTTP server not ready or HTTP call succeeded but the action done “behind” was not enough to restart RTSP server that is still down) then NCS it will never retry this HTTP call again (unless RTSP stream is good again that will make SourceConnection OK again so SourceConnectionLost is re-armed for a new trigger).

So I think you should handle this event differently or add a new event that will retry the Action each time NCS tries to reconnect the Video source and fail.

By the way also adding a SourceConnectionIsBack Event could be very usefull and also being able to add multiple actions to one event too :slight_smile:

Too bad I am not fluent with C#, I would really like helping you improve NCS.

regards.


#16

Of course if initial idea/goal was Case #2 it would be a timeout setting or something which allows multiples trig however it’s not.

The main idea was notification so warning the user by sms or push that something is wrong with a source and that he needs to do something and that’s why it works the way it does.