ZoneMinder Forums

well found but i havnt a clue what your on about lol
I think we need phils input oon this one

James

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

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 *)(shm_ptr+sizeof(SharedData)+sizeof(TriggerData)+(\image_buffer_count*sizeof(struct timeval)));

** note using struct timeval, sizeof=8

I don't think it fixes my problem, but it's a problem.
Matt

your doing ok on this mate. Well done what would that issue caise?

James

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 chunk of that segment, so unless your image fills up the buffer completely, you're not going to see the problem. The shared_images pointer is in error only by (4*image_count) bytes. Probably the worst case is that someone who's using high resolution images would crash occasionally.

or high frame rates? i have a high frame rate system anf it keeps buffer overrun ing maybe this is why. If i slow the framerate down it stops

James

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. The only solution to that is more buffers or what you did, lower the framerate.

On further examination the buffer size is determined from Camera->ImageSize(), which depends on the resolution you put in the setup. I guess the symptom would still be the same though.

your getting a bit good at this by the looks

James
ps as ur a programmer proper you wouldnt know anything about writing a native zm local client to pull the images staight out of shared mem would ypu?

This is interesting, and I think mdaughtrey is right about the mismatch in sizes. As, in theory this should cause the top image in the ring buffer to run off the end of shared memory, every time, I don't know why it doesn't just crash every few seconds. I will have to look into this a bit more.

Either way I don't see how this could possibly affect image collection really in a subtle way. It would seem to be death or nothing really.

Phil

Just to followup again. I saw the following above

In my last posted log, the "x/y" indicates the current last written index (x) and the total number of buffers for that source (y). It's odd that the index jumps around and back again, and that every time it jumps, zms gets the wrong image.

Do you have an example? My suspicion would be a problem in the input switching, assuming all your cams are on the same device. There is some commented out debug in zm_local_camera.cpp in the PreCapture and PostCapture functions. Uncommenting that might help a bit.

Phil

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 not crashing right away, the only thing I can think of is that shared memory cannot be paged out. Memory pages are 4K on Intel machines so it may be that your request is getting rounded up to the next 4K boundary and we're stepping on it but not hurting the machine. If you prefill the shared memory with a known value past the size you asked for, that would prove this theory, and also tell you that someone's overstepping their bounds.
In the meantime I'll get some more debug code in there.
James: Sorry, I just don't have the time to investigate zm further than I have to, as you can tell by my getting to this issue only every few days.
Matt

oh well i was hoping. hpe you get it fixed too. James

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

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.

What bafiles me is that ZM does fine with capture devices and that it is having an issue getting the sample jpegs from your harddrive.