ZoneMinder Forums

ralph179 wrote:So this was a new camera to my system and after adding it I was getting the red image configured with ffmepg. Iwas reading the forum and seen configurations using rtp/rtsp as the source type so I tried that but was unsuccessful. I re-configured using ffmepg and it is now working,nothing different in the setup. A little concerned it will fail again but has been OK for a day.

Ralph

I have tried and failed to get rtp/rtsp option to work. Also cannot figure out how to view monitors using anything except mJPG.

And it's not for lack of trying.

Hi,

I have gone through the same struggle.
In my case, it was the switch, not able to carry that much traffic.
I replaced it, now smearing in RTSP mode as well red images in HTTP mode are gone.

Heiko

Glad you got it working.
In my case, it's a gigabit switch, and it often happens with nothing much going on on the network, even when we are all asleep. And for me, it ONLY happens on the 2 ffmpeg channels. I have 6 other channels that are not affected.

New troubleshooting information:

I have determined that the problem is NOT network congestion, and it is NOT due to packet loss. ZM recovers from packet loss, I verified this up to 10 seconds.

The problem is when the stream is reset by the camera. This is 100% repeatable and can be done in one second for testing purposes.

Just go to the camera using it's native software and restart the stream. ZM will instantly go red and stay that way permanently.

In my case I am using Grandstream cameras which have the GSurf Pro configuration software. I can go into stream settings on GSurf, change any trivial item and click save. This causes the camera's stream to restart and zm loses it. This is how I am simulating the error for troubleshooting. I suspect other camera manufacturers will behave similarly.

Hi ,I have the same problem - camera goes red and error is the same at the first post .I have 2 old cameras - Linksys WVC54GC - this camera goes red ,and Planet ICA-107 ,this never goes red .To this moment I haven't find a solution . Maximum FPS and Alarm Maximum FPS is blank and Source Type is Ffmpeg on both cameras .

I have the same problem
before in version 1.25.0 i had no problem with my ABUS TV1702 camera using RTSP this is not working anymore in 1.26.4 so i switched to ffmpeg this worked for me but with the same problem camera goes red if the stream is broken.
after the stream is there again the screen stays red i have to go to the config saving it without any change then the screen is back.

I found the root of the problem.

zm_monitor.cpp (2675) there is a block So, if the stream fails, this block turns it back to success (0) and the problem continues.
I changed it to this
Now, if the stream fails, Monitor::Capture() returns -1. The zmc dumps, the monitor restarts, and all is working!
Someone please clarify the intent of this block? My cat has been confused lately.

Basildane wrote: // Unable to capture image for temporary reason

Well I guess the keyword in the comment is "temporary". It's common programming practice to sweep a "temporary" error under the carpet and pretend things worked, for the greater good.

Your solution may work, but feels heavy handed. But it's good that you're homing in on the dodgy area!

I would question whether the real culprit is that a fatal/permanent problem is being treated as "temporary". You don't really want the slightest glitch causing a complete teardown of the capture process?

This is not my code, I'm coming in cold on this. That's why I've been asking for help to get it to work. It will take a long time for me to be comfortable with the code. Is this your function? I'm just grasping at straws here.

Like I said in another post, I'm willing to put in the time to make it work, but I'm stretched pretty thin here.

Basildane wrote:This is not my code, I'm coming in cold on this. That's why I've been asking for help to get it to work. It will take a long time for me to be comfortable with the code. Is this your function? I'm just grasping at straws here.

I understand that this is not your code, and nor is it mine Although I have been known to place exploding fixes like that in place to make a problem either go away or show up properly, thereby leading to enlightenment of the true location of the problem!

The stream dies. We restart the stream. I fail to see the problem with this strategy.

Basildane wrote:The stream dies. We restart the stream. I fail to see the problem with this strategy.

That way leads to "Zoneminder stopped working. I bought a new computer/reinstalled my entire operating system. Zoneminder now works."

What I was driving at is this -- it looks like the original intention was that a SHORT glitch, something temporary,should be handled by "ignore it, give a red frame, claim it worked and hope it comes back". Which seems perfectly rational. It is a recoverable error, recover from it.

What seems to be happening is an actual, proper fatal error is being treated as temporary, swept under the carpet by that highlighted code, hence your valid complaint of "it's gone red and got stuck". This is bad.

Your fix (which I agree works for very large values of "work") may well cause unintended, excessive, side effects. Because now any ACTUAL temporary glitches will also cause a teardown of the capture process, if I've understood you right... which has a bigger cost in terms of lost frames of video etc.

If it's working for you, great, but I do expect the problem (the real bug) to be somewhere else.

Edit: When it's working, if you do "ps uax | grep ffmpeg" -- do you see ffmpeg process(es) running on your machine? What about when it goes "red" (obviously, you'd need to answer that without your fix above, otherwise you will hide the problem). Is ffmpeg still running, or has it exited and died? Just a thought, maybe ZM hasn't noticed that ffmpeg has vanished, which wouldn't be in my top 10 list of "temporary errors" to try and hide.

Or, does ZM just use the ffmpeg libraries, not the ffmpeg binary, so you won't see it running anyway -- I've not tried using FFMPEG as a source in 1.25 ...

Yeah, this is all correct. My post is not intended to be a "fix", it is still a cry for help. And still unanswered.
Good news is that this morning I woke up to a working system for the first time in a month.

The reason ZM does not quit right away if capture failed is because its the way it deals with small, temporary failures, such as signal loss.
A proper fix would be to correct the zm ffmpeg code: improve the error checking and add retry code.
Patches are always welcome.

So curiously, now that some time has passed has anyone come across a solution to this?

Added a new IP cam recently, identical physically to another I have but it has updated firmware and has this problem stream goes red after a minute or so, still awaiting a response from the vendor as to get my hands on a downgrade firmware (4 weeks and counting)...

The problem can be recreated like described here, I stop the stream or modify it at camera interface, ZM goes red and doesn't come back until I do something on ZM's console: change a setting, run state, etc and it comes back...

I've matched both my cameras configs perfectly so it's not a config thing, but leaning toward something in the cameras firmware causing it to drop the stream very briefly. I can watch it the entire time on it's webpage and a separate ZM window, when ZM goes red nothing at all goes wrong with the cameras view, not a flicker it looks perfect.

Onvif / RTSP monitor app I have on a windows machine I used for testing also showed up no anomalies, this one's got me beat!

Any suggestions?