ZoneMinder Forums

Friends, the mistake is mine. Turns out I had entered the shared memory id as 0x7a6d200e instead of the default 0x7a6d2000. The zmc modules create their shared memory id by ORing their monitor id with the key. Problem is that the result of that ORing is the same for more than one module for example ...

Didn't achieve much other than a headache.
Phil, can you give me a quick overview on how the shared memory is partitioned between multiple zmcs? I'm particularly interested in how you tell each zmc instance what part of the shared memory to use.

Phil: I'll get more into it tonight but if I select one source to monitor, zms appears to be managing two indexes, which makes me think that the delay handling code is off the rails somewhere.
Matt

Phil: That might have been me misreading a log actually. I'd like to log where in the shared memory the buffers are going, expressed as an offset from shared_data, on the zmc side and the zms side. That should tell us pretty quickly if there's some misunderstanding between the two. As for the shmem ...

I don't think this is related to your problem. Your problem sounds like a mismatch between the rate zmc is populating the shared memory and the rate at which other modules are pulling it off; in other words, zmc is using up all available buffers before anyone else gets to use a buffer and free it up ...

Well, the shared_images pointer is too far up in the shared memory segment, so potentially the last buffer in the list of image buffers could run off the end of the shared memory segment, which would crash zmc I think. However I think I saw each image buffer being allocated a fairly generous fixed ...

Phil: found a bug I think: zm_monitor.cpp::Monitor::Setup int shared_data_size = sizeof(SharedData)+sizeof(TriggerData)+(image_buffer_count*sizeof(time_t))\+(image_buffer_count*camera->ImageSize()); ** note using time_t, sizeof=4 then a few lines later unsigned char *shared_images = (unsigned char ...

Yup, we're not in Kansas anymore....luckily I'm a programmer at work and at play, so hopefully we'll find something interesting.

You know what though...earlier logs indicated that zmc was sticking with the program as far as capture goes - the same image size was getting picked up every time. This makes me think that there's some problem with the way the shared memory is being used. In my last posted log, the "x/y" indicates ...

Ok, noted. I'll go back to looking at zmc.

Started looking through the zms debug output, see ***: Sep 22 23:05:00 salem last message repeated 11 times Sep 22 23:05:00 salem zms[667]: INF [16/20: ] Sep 22 23:05:00 salem zms[667]: INF [Image size 19185] Sep 22 23:05:00 salem zms[667]: INF [shared_data 4098e000] Sep 22 23:05:01 salem last ...

It hasn't changed anything - I still see the alternating jpegs on Ethereal. I've run out of time for this evening; I'll enable debug output on zms tomorrow, suggestions appreciated in the meantime.

I'll do another Ethereal capture of it anyway, see if it shows up any clues.

I'll also enable debugging on zms.

Ok, I'll give it a shot tonight.

Phil: a strings-filtered Ethereal capture of the session is at http://salem.dyndns.org/zmlogs/zm.dmp.txt