Service stops responding after a while after updating to 1.5.1

Hi Steve,

Yes, I run the 64 bit version.

ok there are 2 things I just need you to explain so that I can try to reproduce / simulate similar scenarios.

1 account / user is connecting very regularly to ncs, what is this for ? do you have another ncs consuming or retrieving images from it ?

I also see some errors: HTTP MJPEG Thread Buffer is undersized…

Do you have a camera connecting in MJPEG mode that provides very high resolution ? (and returns images > 2MB) ?

Can you please here send a capture of one of these? Your 5th camera (internal sourceid 4)

Can you also please post 3 screenshots of the performance monitor view (from web client) for the last 3 days ?

Thanks

Hi Steve,

1 account / user is connecting very regularly to ncs, what is this for ? do you have another ncs consuming or retrieving images from it ?

Client 10.101.1.2 is the probe of our monitoring system. It checks if the web interface still works (to detect NCS outages)

Do you have a camera connecting in MJPEG mode that provides very high resolution ? (and returns images > 2MB) ?

Following cams are connecting in MJPEG mode:






Do you want me to check for those the sizes? (How? :)). The rest is using RTSP

Can you please here send a capture of one of these? Your 5th camera (internal sourceid 4)

Here the settings for cam 5:

Can you also please post 3 screenshots of the performance monitor view (from web client) for the last 3 days ?

10/5:

9/5:

8/5:

Just happened to me for the first time. As it doesn’t crash I don’t have the exact location / source of the problem but it’s giving some clues already. I will keep it running in this state for now so that I can investigate.

1 Like

Hasn’t happened to me since the upgrade to 1.5.2.

However, I did disabled some cameras that where having timeout issues, then got quicker internet at that location.

Don’t know if that info helps or not, but I figured I’d pass it on.

Seems related to ffmpeg when recording (since the new upgrade to ffmpeg 3.3) but apparently occuring very rarely.

Ok, I made some progress here. I have managed to reproduce similar situation twice here. First time I couldn’t investigate because it was the production build and it cannot be debugged.

Actually I figured out what what happening here but I’m not sure that it’s the same in your case. The software is actually not really frozen or crashed but just saturated of http connections and refusing to accept new ones.

In my case it’s because another system (another NCS) was retrieving live stream / the mpeg 4 stream while cpu was already intensive. Had some timeouts and the host was in loop requesting new connections until it reached the critical status where ncs would not accept opening new ones.

So I suppose it’s not your case and you don’t have an external system retrieving the MPEG4 streams from netcam studio. While debugging the process was paused and this allowed all connection to expires (and nothing to create new ones during this time), after resuming the app it was again working as before.

If you have the problem again, please take a screenshot of all connection made to Netcam Studio (using TCPView) so that we can check which connection may be the cause on your end.

Hi Steve,

thanks for the info & investigation!
If it crashes again, I’ll launch TCP view and provide a screenshot.

Ok, i found it.

Not related to any of my suspicion (well http flooding can occur but not the root cause here as it’s not stuck forever) :slight_smile:

There is a risk of dead lock between the event logging and the performance counters thread. Looking forward to fix ASAP.

2 Likes

here’s you go:

I’m confident that this version will solve that one for good.

It was related to the Performance monitor (so something new introduced in 1.4.x) and I was really luck to figure out because such deadlock issues can be really complicated to diagnose and understand.

Thanks Steve,
Will upgrade ASAP.

Thanks Steve!
I upgraded the server. Let’s see how it goes.

I also upgraded 1 standalone client from 1.5.1 to 1.5.3. However, I can’t start it anymore now, it just keeps crashing:

I tried removing the config file to get it recreated, but then I get a ‘configuration failed to initialize’’ (so placed it back)

1 Like

Two things. 151 was a little bit special. After exit check that no NCS process is running. Start 154 client again. I tested and I think it needs it server to work.

Strange, same problem was already in 1.5.2 and i’ve fixed the missing dependencies but apparently my installer project didn’t properly save (32bit is ok, 64bit is missing libs).

I have reuploaded 64-bit package so it should be ok now even when installing only the client.

Hi,

this is a separate pc, with only the client. I double checked, but no NCS processes are running. I just tried to completely uninstall and install again, but doesn’t help.
Is there anywhere config store, except Program files & Programdata?

I got this issue in the 32bit version.

No, @Steve need to reupload the 32-bit package also. He did it only for 64-bit. But he is quick today :slight_smile:

Well so try to install both Client + Server and tell us if it works because 32-bit package seems ok.

And what about this 1.5.4 ? Looking okay on your side ?

I’ll probably replace the official version on the website if you didn’t encounter problems of freezing anymore.

Hi,

sorry for not reporting back earlier. 1.5.4 on server (in service mode) runs now smooth for 6 days without any crash. So looks good! Thanks again for your efforts!

I have to upgrade my other client PC to see if I have the same issues there.