Empty input file on 1.19.0

[tech_fixer]

Hi Phil,
On a fresh install of ZM 1.19.0 I cant get an Axis network camera to work. After a lot of troubleshooting I'm down to this:
Running "zmc -m test -H 97.6.10.85 -P 80 -p /axis-cgi/jpg/image.cgi?resolution=320x240" returns "Empty input file"

I get the image perfectly on a browser.

Any ideas?

Regards,
Jose Rodriguez

[zoneminder]

Hi Jose,

As I posted on another thread, this area has been completely rewritten to use regular expressions because I couldn't even figure out how it worked. Can you do the same as I suggested elsewhere and do a

<i>wget -S http://97.6.10.85/axis-cgi/jpg/image.cg ... 320x240</i>

and post or mail me the output (not necessarily all of it). Alternatively if you have a path for the video output instead, try using that.

Phil,

[tech_fixer]

I have tried all alternatives to the path that I know... all bring good images in a browser, but zmc just wont go.

A network trace suggests that zmc actually fetches the image to the remote camera, but I still get "Empty input file".

Anyway, here's the output for wget:

wget -S http://97.6.10.85/axis-cgi/jpg/image.cg ... on=320x240

--16:54:47-- http://97.6.10.85/axis-cgi/jpg/image.cg ... on=320x240
=> `image.cgi?resolution=320x240.2'
Connecting to 97.6.10.85:80... connected.
HTTP request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Connection: Close
3 Server: Camd
4 Content-Type: image/jpeg

[ <=> ] 7,633 248.47K/s

16:54:48 (248.47 KB/s) - `image.cgi?resolution=320x240.2' saved [7633]

Jose.

[tech_fixer]

The path for MJPEG video does not work either. Here's the path:
/axis-cgi/mjpg/video.cgi?camera=&resolution=640x480

The whole command is:
zmc -m test -H 97.6.10.85 -P 80 -p /axis-cgi/mjpg/video.cgi?camera=&resolution=640x480

Doesnt work straight from ZM console either.

Jose.

[zoneminder]

Sorry, I should have said that it's the contents of the saved file I'm interested in rather than the output of wget itself. So the file named 'image.cgi.........'

The zmc command won't work by itself unless there is a monitor defined with those characteristics. Actually that form is deprecated now anyway as -m <monitor id> is preferred.

Phil,

[tech_fixer]

Here's the first two lines...

????^@(h ^@^@^@^@^@@~L`~@?@Y?9~J~H~~D^@^@^@^A^@^@^@J^D/d^A^R^O*7^_^P??^@C^@^R^L^M^P^M^K^R^P^N^P^T^S^R^U^[,^]^[^X^X^[6') ,@9DC?9>=GPfWGKaM=>YyZaimrsrEU}~F|o~Efprn??^@C^A^S^T^T^[^W^[4^]^]4nI>Innnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn??^

I think you'll need the image file to compare, as a reference. I'll email it to you to phillip.coombes@zoneminder.com.

Jose.

[zoneminder]

Ack! I meant -s not -S. Can you do the capture again with a -s (little) which should save the headers in the retrieved file and not just output them. Can you do this with both stills and video URLs.

Phil,

[tech_fixer]

Here's the output for the image:

HTTP/1.0 200 OK
Connection: Close
Server: Camd
Content-Type: image/jpeg

????^@(h ^@^@^@^@^@@~L`~@?@Y߳~J~J~~D^@^@^@^A^@^@^@U^D/d^A^R^O*7^_^P??^@C^@^R^L^M^P^M^K^R^P^N^P^T^S^R^U^[,^]^[^X^X^[6'') ,@9DC?9>=GPfWGKaM=>YyZaimrsrEU}~F|o~Efprn??^@C^A^S^T^T^[^W^[4^]^]4nI>Innnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn??^@^


Here's the output for the video:

HTTP/1.0 200 OK
Connection: Close
Server: Camd
Content-Type: multipart/x-mixed-replace; boundary=--myboundary

--myboundary^M
Content-Type: image/jpeg^M
^M
ÿØÿþ^@(h ^@^@^@^@^@@<8c>`<80>¹@Yßú<8a><8b>~<84>^@^@^@^A^@^@^@U^D/d^A^R^O*7^_^PÿÛ^@C^@^R^L^M^P^M^K^R^P^N^P^T^S^R^U^[,^]^[^X^X^[6') ,@9DC?9>=GPfWGKaM=>YyZaimrsrEU}<86>|o<85>fprnÿÛ^@C^A^S^T^T^[^W^[4^]^]4nI>Innnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnÿ

The ^M are linefeeds, right?

Jose.

[zoneminder]

I think technical the ^M are carriage returns. However it looks as expected except that it has not included a content-length header in either case. My Axis camera, and even my crappy D-link one does as well. I suspect the code does not make a good assumption when this header is missing but I'll check.

Phil

[zoneminder]

Hi Jose,

I've put a test fix up <a href="http://www.zoneminder.com/downloads/zm- ... z">here</a> which I think addresses this problem. If you get a chance could you try it out. I've done some testing here but as all my sources send content length I've had to spoof it a bit.

This isn't an 'official' 1.19.1 yet in case I have to do more tweaks but there are one or two other changes in it which I may as well list.

o Fixed (hopefully) remote streams with no content-length header
o Fixed borken regex for single image gets from remote streams
o Fixed empty timestamps in frame list view
o Added check in configure to look for pcre.h in /usr/include and /usr/include/pcre
o Modified configure and makefiles to want to know the installed location of ffmpeg rather than the build location, you must have done 'make installlibs' in ffmpeg to install the libraries and header files.

Let me know how you get on.

Cheers,

Phil,

[greatwhitedan]

Well that worked for me. This fix made it work just great. I still can not get over .9 FPS, but that is becouse of this cheap camera, and it only streams in Java and ActiveX from the web interface so I don't think there is anything to attach zmc to on that. Well thanks again, and you are a very good developer.

Blessings,
Daniel Wier

[zoneminder]

Daniel,

I suspect that if there is a Java and ActiveX interface then there will be a motion jpeg interface also. Try just using video.cgi instead of IMAGE.JPG.

Phil,

[tech_fixer]

Well, on my case zmc just croaks and dies.

'zmc -m 1' died at 04/03/19 10:08:02, signal 10

If I run it manually it gives a nice segfault:
"Segmentation fault"

Maybe my install of RH9 is just screwed up...

I'll have to try later on a fresh install.

Jose.

[zoneminder]

Can you run it through gdb and see where it pegs out? Alternatively if you want to open up the camera to me I can try and figure it out from here. Drop me an email if you want to do that and I'll give you my IP.

Phil,

[tech_fixer]

I ran the zmc program using gdb (GNU Debugger) using "-m 1" as parameters and here's the output:
Program received signal SIGSEGV, Segmentation fault.
0x08054ee3 in RemoteCamera::ReadData(Buffer&) (this=0xc8a5c58, buffer=@0xc8a61a4) at zm_remote_camera.cpp:181
181 FD_SET(sd, &rfds);

By the way, my ZM_FRAME_SOCKET_SIZE setting is set to 0. Could that be affecting the capture daemon?

Jose.