this just happened overnight

[BobLaske]

Without changing any settings, the night before, the output was fine. This morning, the image looks like this.

2019-03-16_085954.png (536.45 KiB) Viewed 9886 times

I rebooted the server and still the same output.
The camera is a very basic IP camera, reached by going to http://192.168.12.241:8080/?action=stream on a browser. Using any browser, the image (video frames) is fine. All is working. But, through ZM, I get the above.

My settings are;
General
Source Type: Remote
Function: Monitor
MFPS are empty as per someone's suggestion on github.
Alarm FPS same as above.

Source
Protocol: HTTP
Method: Simple
Host name: acadmin:1234@192.168.1.241
Port: 8080
Path: /?action=stream

Then the rest other than specifying resolution are default. What could have changed overnight that would cause this? I would have thought this kind of look was phase shift in old TV's only .

[mikb]

Although you've changed nothing, you've not said what resolution the camera is supposed to be returning, vs the resolution you've set in Zoneminder

It looks like the camera is delivering fewer pixels per line than you are telling ZM to interpret.

Measuring off your PNG in GIMP, I make it about 320 pixels across per repeat (or 640, depending on whether I've slipped a line), but your image is 800 pixels wide.

Your camera is sending 320/640?? and Zoneminder is set for 800x?? or something like that. Otherwise, it looks like a perfectly good colour picture.

Check all settings, and if you still don't see it, post the settings

It should look more like this ... ?

a.png (346.81 KiB) Viewed 9882 times

[BobLaske]

Hi,

I like how you broke things down and how you 'fixed' the image .
How did you do that?

I failed the post the resolution since I had tried a number of variations.
At the time of the image, the camera was set to 1600x900 and so was ZM.

However, now that I'm playing with it again, here is what I've discovered.

When using what might be considered odd resolutions such as 1600x900 (odd to ZM I guess), I get the kind of image I showed.
Changing the resolution in the GUI before changing them on the camera also crashes ZM completely. I've tried restarting it from
the CLI only to find that I have to fully reboot. No idea what's causing this.

Now I have it set to 1280x960 which is working but there is a black bottom to the image now. I then changed it to 1920x1080 and it works just fine without a black section at the bottom. I'd like a smaller image since I don't need 1920x1080 in this case.

This is how things look now.

2019-03-18_104827.png (1023.48 KiB) Viewed 9851 times

So, the problem seems to be related to certain resolutions.
No idea why ZM is crashing however.

[mikb]

I like how you broke things down and how you 'fixed' the image .
How did you do that?

GIMP, De-interlace filter (although the picture isn't interlaced, it gets rid of every other line which clears up most of the mess). Then re-scale to 16:9 aspect (as everything looks thin at 4:3 -- unlike ZM I am prepared to guess at your resolution and camera settings .

When using what might be considered odd resolutions such as 1600x900 (odd to ZM I guess), I get the kind of image I showed.
Changing the resolution in the GUI before changing them on the camera also crashes ZM completely. I've tried restarting it from
the CLI only to find that I have to fully reboot. No idea what's causing this.

From a programming point of view, ZM shouldn't crash when you do that (I'm sure you know that, as do the ZM devs).

From a practical point of view, changing the resolution unexpectedly is kinda rough -- probably best to stop the camera at ZM, change both ends, start the camera. It's likely you've got a memory corruption due to data being delivered from the camera not being the expected size and shape, exceeding a storage allocation somewhere, and that's why you get a crash.

[BobLaske]

It's a fresh install and only using 20GB of a 1TB drive so I think what you're talking about is related to something else.

>It's likely you've got a memory corruption due to data being delivered from the camera not being the expected size and shape,
>exceeding a storage allocation somewhere, and that's why you get a crash.

Maybe this is related to a 'shared memory' error I see now and then, especially if I try connecting two USB camera's.

[mikb]

It doesn't matter whether it's a fresh install or not, or how much hard drive/shared memory you have -- although running out of those is bad too!

What I'm saying is that if you change the resolution at the camera, or Zoneminder, while it is running, and they disagree on the size of the picture for even a moment, then that could well cause a crash. In a perfect world it wouldn't. But you are changing the size of the incoming data stream (or the container it's being stored into) and that can cause overflows in memory, which corrupts stuff, and crashes the process.

Don't do that

Do experiment with different "round numbered resolutions" though (try and make the X resolution a whole multiple of 16 if messing about with it, I've had trouble with FFMPEG not liking "odd" horizontal resolutions, which also messes up Blender's video editor!)

[BobLaske]

I understand.

I'm not a coder but I am the head of a software project and the one thing we do not ever stand for is ANY reason for something to crash.
No matter what you do to it, it should give you an error, complain, call you names, not serve you breakfast for a month but never crash.

>Do experiment with different "round numbered resolutions"

Now I know a term for that . Thanks.

I'll do that and thank you for responding to my question.

[mikb]

the one thing we do not ever stand for is ANY reason for something to crash.

You are correct, and it's a good thing to strive for. In practice, sometimes it doesn't happen.

On a positive note, I'm sure the ZM developers know this principle too, but need more "hands on deck" to find the bugs/risk points and submit fixes.

[iconnor]

I agree ZM should not crash. I will do some testing and see if I can recreate yours.

[BobLaske]

Please, let me know how I can help. I can easily get it to crash simply my playing with settings. In some cases, the only way to get zm back is to fully reboot the server since restarting the service doesn't do it.

[mikb]

the only way to get zm back is to fully reboot the server since restarting the service doesn't do it.

Crashing aside, that bit disturbs me most. It normally takes a hardware-confusion to require a reboot/power cycle to fix.

This is not Windows in the 1990's -- "It appears you have moved the mouse. Reboot? [Yes] [Yes]" or "An application has crashed, now everything is broken". If ZM is stopped, and all its processes stopped, there should be nothing being held open (shared memory, memory use, hard drive files, network sockets ...) so nothing to prevent it restarting. Very odd.

[BobLaske]

@mikb
I've looked at the processes when this happens and don't see anything unusual. zmd seems to be running but the GUI is dead, cannot reach it anymore.
In those cases, I've tried restarting the service but that only worked once, never again. The only way to get things back is to fully reboot the os which means to me that something else is getting involved which perhaps zmd is not controlling directly.

Just guessing of course. Happy to re-create the crashing and take notes if you like.
The hardware is a mini PC running ubuntu server 18.04, downloaded some two weeks ago so very current and fully updated.

Pinetrial-D, version: JHS646, vendor: American Megatrends Inc. date: 07/21/2012
8GB RAM, 1TB Storage. size: 64KiB, capacity: 960KiB
product: Intel(R) Atom(TM) CPU D525 @ 1.80GHz. width: 64 bits

[rockedge]

I thought I was the only one crashing ZM so hard that I need to take apart the machine and piece it back together to reboot.

in my case here on Puppy Linux variants, it is almost always a RAM issue or lack of a swap partition when it is really needed.
/dev/shm pegs at 100% suddenly and since the entire OS with ZM and ZMES is loaded completely in RAM if anything goes south and overruns...BAM!! all locked up and only pulling the plug will get it back at times.

that's life on the fringe I guess. Although BobLask is using 8 gigs of RAM and I am doing these types of crashes on machines with 2-4 gigs of RAM, would make one think it is something else.

[BobLaske]

So, are we supposed to report this or start a new post asking who/how many others are seeing this problem? Obviously, I'm not alone which means others might think it's something they are doing wrong.