Capture Problem: 1.22.2 vs 1.21.3 with Axis 2100 Cams
Capture Problem: 1.22.2 vs 1.21.3 with Axis 2100 Cams
Hi Folks!
At first, thanks to the community and the people who build this fine piece of software.
So far, i'm running ZM 1.21.3 (from Live-CD) with Axis 2100 cams and it works very well.
Last Week, i set up a new system with 1.22.2 (from Live-CD) and i got some problems:
The stream will "hang" sometime, IP-Adresses going red. Sometime they going back to green and it works for a short period. This concerns all 4 cams, but not unconditional at same time.
This problem i solved in 1.21.3 by using HTTP 1.0 and switching ZM_NETCAM_REGEXPS to ON.
Because both systems, at the moment, running concurrent, it must be false settings because the "old" system works fine.
Can anybody help me to remove my blindfold ?
Greetings,
Axel
Ps: Another lot: I tried to use a new Axis 207 cam and similar problems as described above (onle for this cam on the "old" system) exists on BOTH systems. Did anyone use this cam with zoneminder.
At first, thanks to the community and the people who build this fine piece of software.
So far, i'm running ZM 1.21.3 (from Live-CD) with Axis 2100 cams and it works very well.
Last Week, i set up a new system with 1.22.2 (from Live-CD) and i got some problems:
The stream will "hang" sometime, IP-Adresses going red. Sometime they going back to green and it works for a short period. This concerns all 4 cams, but not unconditional at same time.
This problem i solved in 1.21.3 by using HTTP 1.0 and switching ZM_NETCAM_REGEXPS to ON.
Because both systems, at the moment, running concurrent, it must be false settings because the "old" system works fine.
Can anybody help me to remove my blindfold ?
Greetings,
Axel
Ps: Another lot: I tried to use a new Axis 207 cam and similar problems as described above (onle for this cam on the "old" system) exists on BOTH systems. Did anyone use this cam with zoneminder.
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
there are issue swith the 207 firmware if you search you will find a couple of topics on it, i think this cam hangs occasionally, re the 1.22/1.21 issue im unsure, I have moved my stuff over to 1.22.2 with no major issues
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Hi folks,
I have also got some Axis 2100 cameras (and a bunch of other stuff too). I have got exactly the same problem, e.g. there are occasional gaps in the image sequences from the Axis 2100s, and the IP-no:s turn red. The other cameras (and camera servers) do not behave like this. I also tried to switch on the PCRE-support, but the only result was that the CPU-utilization went up about 50%. A week ago, I made a firmware upgrade on the Axis 2100 cameras, but it did not solve this problem (the cameras are significantly more reliable in other respects after this upgrade, however).
I am going to try out some ideas I have during this night, and see if it makes any difference. In case of success, I'll return here with the results.
Best regards,
Peter
P.S. Axel, I have a number of Axis 210 cameras also, they work OK. D.S.
I have also got some Axis 2100 cameras (and a bunch of other stuff too). I have got exactly the same problem, e.g. there are occasional gaps in the image sequences from the Axis 2100s, and the IP-no:s turn red. The other cameras (and camera servers) do not behave like this. I also tried to switch on the PCRE-support, but the only result was that the CPU-utilization went up about 50%. A week ago, I made a firmware upgrade on the Axis 2100 cameras, but it did not solve this problem (the cameras are significantly more reliable in other respects after this upgrade, however).
I am going to try out some ideas I have during this night, and see if it makes any difference. In case of success, I'll return here with the results.
Best regards,
Peter
P.S. Axel, I have a number of Axis 210 cameras also, they work OK. D.S.
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
I have had a problem with a 206m and jpeg grabs. DOing this if you log in through the web i/f of the cam it tells you the max number of connections have been reasched. But mjpeg dooesnt suffrer this so i have been using this. Hope this is a work around for you
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Hi,
I tried out some stuff during the night on the Axis 2100 cameras, seemingly it looked good from the start, but when I look at it now, the changes I made make no difference.
When I study the problem it works like this:
I start the top utility and follow the active processes.
The Axis 2100 cameras grab more and more processor time (still working), and suddenly the zmc-daemon for the most "hungry" camera stop. Then there is a gap in the sequence, before a new daemon process starts up. The gap is 15 - 20 sec (I have set the restart at 15 sec). Those gaps occur quite frequently, sometimes with a shorter interval than 1 minute. Sometimes they occur less frequently, mostly at night.
One of the cameras seems to give less trouble than the others. I have limited the bandwidth to 2 Mbit/s on all the Axis 2100s. I do not dare to set the bandwidth to unlimited, as there are a couple of monitoring apps in the network that will suck every available Mbit from the cameras, if given the opportunity, making the network almost useless. The Axis 210 cameras I have, do not limit the bandwidth, but the max frame rate to any connected viewer, which makes more sense.
In any given moment there are at least 2 connections to one camera but may in extreme cases be as many as 6. With a frame rate of 2 fps in medium quality, and some network overhead, the required bandwidth should not be more than 500 kbit/s, even in the worst case. This is well below the max allowed of 2 Mbit/s. However, still it seems to be a load problem, with respect to the nightly behavior.
Any ideas welcome.
With best regards,
Peter
I tried out some stuff during the night on the Axis 2100 cameras, seemingly it looked good from the start, but when I look at it now, the changes I made make no difference.
When I study the problem it works like this:
I start the top utility and follow the active processes.
The Axis 2100 cameras grab more and more processor time (still working), and suddenly the zmc-daemon for the most "hungry" camera stop. Then there is a gap in the sequence, before a new daemon process starts up. The gap is 15 - 20 sec (I have set the restart at 15 sec). Those gaps occur quite frequently, sometimes with a shorter interval than 1 minute. Sometimes they occur less frequently, mostly at night.
One of the cameras seems to give less trouble than the others. I have limited the bandwidth to 2 Mbit/s on all the Axis 2100s. I do not dare to set the bandwidth to unlimited, as there are a couple of monitoring apps in the network that will suck every available Mbit from the cameras, if given the opportunity, making the network almost useless. The Axis 210 cameras I have, do not limit the bandwidth, but the max frame rate to any connected viewer, which makes more sense.
In any given moment there are at least 2 connections to one camera but may in extreme cases be as many as 6. With a frame rate of 2 fps in medium quality, and some network overhead, the required bandwidth should not be more than 500 kbit/s, even in the worst case. This is well below the max allowed of 2 Mbit/s. However, still it seems to be a load problem, with respect to the nightly behavior.
Any ideas welcome.
With best regards,
Peter
@ jameswilson
Thanks for your response.
I contact the Axis-Support, but they answered the problem is unknown and newer software would be not available.
@ miles
Unfortunately i'm not able to check the problem in depth, because i not understand all the modules in Linux.
If you want to brief me, i be happy to attend.
Greetings from Rhine,
Axel
Thanks for your response.
I contact the Axis-Support, but they answered the problem is unknown and newer software would be not available.
@ miles
Unfortunately i'm not able to check the problem in depth, because i not understand all the modules in Linux.
If you want to brief me, i be happy to attend.
Greetings from Rhine,
Axel
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
axel are you using jpeg or mjpeg?
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Hi Axel,Axel wrote:@ jameswilson
Thanks for your response.
I contact the Axis-Support, but they answered the problem is unknown and newer software would be not available.
@ miles
Unfortunately i'm not able to check the problem in depth, because i not understand all the modules in Linux.
If you want to brief me, i be happy to attend.
Greetings from Rhine,
Axel
The top utility in linux displays the active processes, used memory, swap, who is the owner of each process, and a few other items. It corresponds to the Process-tab in Windows taskmanager. Open a console window in Linux and just give the command top, and you'll see the process list that refreshes each 3 seconds. Take a note of the PID and %CPU columns. You quit top just by pressing q.
With top running, open a new console window and give the command ps ax. This will show a list of all processess. Look up the PID-number from the top listing for a process you think is increasing in hungryness. There you'll see the command line, something like zmc -m 3 where 3 is the number of the camera. It may also be useful to have a look at the /tmp/zmdc.log, /tmp/zmwatch.log, /var/log/syslog and /var/log/messages.
When I look at my /tmp/zmdc.log for the Axis 2100 cameras, there are frequent complains about JPEG data corruption for those three cameras. The three Axis 2100 cameras do not share a common network path except for the last jump, which is a 1 Gbit/s optic link. If something was wrong here, nothing at all would work. I think there is something fishy with the data that the cameras deliver.
I will probably replace the Axis 2100 cameras soon, as they are now fairly old, and will not be supported in the future. As I have no problems with the newer Axis 210 cameras, they seem to be a good replacement.
Regards,
Peter
Vital signs
Sorry for delayed response, i'am on a business trip and back at middle next week.
@jameswilson
I think i use jpeg. Path description on Axis2100: /axis-cgi/jpg/image.cgi?resolution=640x480
(same on 207)
@miles
Thank you for advise. I try it, after return to office.
Greetings from Berlin,
Axel
Sorry for delayed response, i'am on a business trip and back at middle next week.
@jameswilson
I think i use jpeg. Path description on Axis2100: /axis-cgi/jpg/image.cgi?resolution=640x480
(same on 207)
@miles
Thank you for advise. I try it, after return to office.
Greetings from Berlin,
Axel
Hi folks,
I have been digging into the problem with the Axis 2100 cameras a bit more thoroughly. When I follow up the log zdmc.log, I notice that there is not one single dropout during the night. About 05:30 in the morning, the "normal" dropouts start to occur. This concurs exactly with the time when the workers arrive and start the machinery in the plant (compressor, welding robots, hydraulics, etc.). No other cameras are sensitive to this, only the Axis 2100s. The company that sold us the cameras have been here to have a look, and they think that those cameras may be sensitive to noise on the mains supply. They are going to try filters on the voltage supply line to the cameras. In another 2 weeks I will know if it made any difference or not.
Still, I think the zmc daemon should not stop communicating when it receives bad data. I'll try to have a look at the code when there are a few minutes free.
I'll keep you informed.
Best regards,
Peter
I have been digging into the problem with the Axis 2100 cameras a bit more thoroughly. When I follow up the log zdmc.log, I notice that there is not one single dropout during the night. About 05:30 in the morning, the "normal" dropouts start to occur. This concurs exactly with the time when the workers arrive and start the machinery in the plant (compressor, welding robots, hydraulics, etc.). No other cameras are sensitive to this, only the Axis 2100s. The company that sold us the cameras have been here to have a look, and they think that those cameras may be sensitive to noise on the mains supply. They are going to try filters on the voltage supply line to the cameras. In another 2 weeks I will know if it made any difference or not.
Still, I think the zmc daemon should not stop communicating when it receives bad data. I'll try to have a look at the code when there are a few minutes free.
I'll keep you informed.
Best regards,
Peter
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
Axel, I would also try using mpeg and see if that helps, as my 206m still does this but a bit more random than yours. Interferece can causes nastiness, but id look at plugging them into a ups just for testing, or a decent psu
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
- zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
ZM will not stop talking to the cams if it can't grab an image. If the capture daemons fails then it will be restarted. If this happens continually then this restart is delayed slightly and will eventually max out at 15 minutes (this can be changed). This is to stop one dodgy cam bringing the whole system to a halt by having ZM spend all it's time restarting process which is pretty cpu intensive.
So Zm will connect back to your cam, but if it is out of service for a while it might take a while before the connection settles down.
So Zm will connect back to your cam, but if it is out of service for a while it might take a while before the connection settles down.
Phil
Hello Boy's.
I'm back and try some of your kindly hints.
@miles
I try out the top tool and confirm your experience. The processes "zmc" grab more and more cpu time, until the task ends. Then a new task will be started.
In ZMWATCH.LOG the capture deaemon starts nearly every 10 seconds a new task. In ZMDC.LOG the processes wills "exit abnormaly, exit status 255" and sometimes on my Axis 207 "exit status 11".
The error message in SYSLOG tell me "Invalid response Status 404: not found"
@jameswilson
I try using MPEG with my 207, but the problem is the same. Maybe its really the cam software? Its 4.22 and the german support asserted, there is no newer or beta available. Did you get a newer one?
@miles & jameswilson
I send you via pm the link to my system(s). Maybe you want to see the situation live.
I think, current supply can not be the problem, because the 1.21.3 system runs without problems (with 2100). And its really a problem to try out, concerning fix wired cabling under roof of the hall.
Now i try to set up the 1.22.2 to default and run only with the 207. Maybe it works. Are there any "special" settings for 207?
Greetings,
Axel
I'm back and try some of your kindly hints.
@miles
I try out the top tool and confirm your experience. The processes "zmc" grab more and more cpu time, until the task ends. Then a new task will be started.
In ZMWATCH.LOG the capture deaemon starts nearly every 10 seconds a new task. In ZMDC.LOG the processes wills "exit abnormaly, exit status 255" and sometimes on my Axis 207 "exit status 11".
The error message in SYSLOG tell me "Invalid response Status 404: not found"
@jameswilson
I try using MPEG with my 207, but the problem is the same. Maybe its really the cam software? Its 4.22 and the german support asserted, there is no newer or beta available. Did you get a newer one?
@miles & jameswilson
I send you via pm the link to my system(s). Maybe you want to see the situation live.
I think, current supply can not be the problem, because the 1.21.3 system runs without problems (with 2100). And its really a problem to try out, concerning fix wired cabling under roof of the hall.
Now i try to set up the 1.22.2 to default and run only with the 207. Maybe it works. Are there any "special" settings for 207?
Greetings,
Axel
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
i tell you what would be better open your cam on a different port and i will load it into my zm server and see what happens. It is usually the cam. Just to confirm the point. When you now longer recieve images in zm, a restart of the cam fixes this, or a restart of the zm server. Also when you have no images what happens when you try to log in to the cam with a browser?
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk