Page 1 of 1

zmc consumes 100% CPU if video stream cannot be opened

Posted: Tue Nov 25, 2014 12:31 am
by dma_k
Hi everyone,

I my setup I have few cameras, one of which has connectivity problems. When I start Zoneminder 1.28.0 (but I think the problem does not depend on version), it starts to consume 100% CPU trying to read from this camera. From logs:

Code: Select all

ERR	Unable to open input rtsp://10.0.0.1:8080/ due to: Operation now in progress	zm_ffmpeg_camera.cpp	264
Disabling detection does not help.

Code: Select all

# /usr/bin/zmpkg.pl start
# zmu -m 3 -D
# top -d 10
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
15968 www-data  20   0  214676  79572  67804 R  99.8  2.6   0:19.04 /usr/bin/zmc -m 1
15952 www-data  20   0  171312  36744  25896 S   7.6  1.2   0:01.71 /usr/bin/zmc -m 2
1. How to really disable camera capturing?
2. Where to look at for the solution? For example, if I provide invalid host name, the result is the same (100% CPU load). I think there should be a sleep between frequent capturing attempts.

Thanks!

Re: zmc consumes 100% CPU if video stream cannot be opened

Posted: Sun Dec 07, 2014 3:20 pm
by dma_k
And I have also noticed, that if camera hostname is not given correctly, zmc also starts eating CPU. Does it make sense to add sleep() in zm_ffmpeg_camera.cpp:264? Thanks for any hint in advance.

Re: zmc consumes 100% CPU if video stream cannot be opened

Posted: Sun Dec 07, 2014 9:01 pm
by dma_k
I am facing difficulties about how to debug zmc. Is it possible to create binaries that only have symbol information, the way it is done in squid3-dbg?

I have something to say concerning the function

Code: Select all

int FfmpegCamera::PrimeCapture()
{
    Info( "Priming capture from %s", mPath.c_str() );

    if (OpenFfmpeg() != 0){
        ReopenFfmpeg();
    }
    return 0;
}
Basically it always succeeds and then Monitor::Capture() is called in endless loop, each loop calling camera->Capture(*(next_buffer.image)) which will return -1.

ReopenFfmpeg() tries to re-establish connection in separate thread, and I think it should not launch a separate thread. It should block monitor until connection is established, as otherwise it's not possible to tell the monitor to terminate.