As noted in this forum message, I was having trouble with zmc timing out in select, and I thought I'd fixed it.
I was worng.
Or at least, I was half wrogn. :-)
After some tuning and tweaking, I got the Panasonic camera to work with 1.21.0 on my office machine; records, modects, everything works nice.
I move the camera back to the client's 1.21.1 machine, and I'm back to where I was. wget can retrieve a JPEG from the camera, and so can Konqueror... but zmc pukes. The strace looks substantially identical to the one on the other thread, and my wits are close to ending; debug on zmc doesn't seem to help me much, unless the higher levels won't debug to syslog, and require the specification of a file.
The kernels are both the same version number SuSE 2.4's; the client's is about 3 patches newer.
Any specific debug/config output potential diagnosticians would like to see?[/url]
mostly SOLVED: zmc select still timing out -- on one of two
mostly SOLVED: zmc select still timing out -- on one of two
Last edited by Baylink on Wed Jun 22, 2005 10:49 pm, edited 1 time in total.
strace of zmc
open("/etc/localtime", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
close(6) = 0
open("/etc/localtime", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
close(6) = 0
rt_sigaction(SIGPIPE, {0x4033b5c0, [], 0}, {SIG_IGN}, 8) = 0
send(3, "<139>Jun 21 10:29:25 zmc_m1[4388"..., 57, 0) = 57
rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
close(5) = 0
gettimeofday({1119364165, 460861}, {240, 0}) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1 USR2], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [USR1 USR2], NULL, 8) = 0
gettimeofday({1119364165, 461174}, {240, 0}) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.0
.253")}, 16) = 0
write(5, "GET /nphMotionJpeg?Resolution=32"..., 192) = 192
select(6, [5], NULL, NULL, {0, 500}) = 0 (Timeout)
gettimeofday({1119364165, 468996}, {240, 0}) = 0
open("/etc/localtime", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
close(6) = 0
open("/etc/localtime", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
close(6) = 0
open("/etc/localtime", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
fstat64(6, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
close(6) = 0
open("/etc/localtime", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
close(6) = 0
rt_sigaction(SIGPIPE, {0x4033b5c0, [], 0}, {SIG_IGN}, 8) = 0
send(3, "<139>Jun 21 10:29:25 zmc_m1[4388"..., 57, 0) = 57
rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
close(5) = 0
gettimeofday({1119364165, 460861}, {240, 0}) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1 USR2], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [USR1 USR2], NULL, 8) = 0
gettimeofday({1119364165, 461174}, {240, 0}) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5
connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("192.168.0
.253")}, 16) = 0
write(5, "GET /nphMotionJpeg?Resolution=32"..., 192) = 192
select(6, [5], NULL, NULL, {0, 500}) = 0 (Timeout)
gettimeofday({1119364165, 468996}, {240, 0}) = 0
open("/etc/localtime", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
close(6) = 0
open("/etc/localtime", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
close(6) = 0
open("/etc/localtime", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
And anyone familiar with ZM internals... or anyone with half a *brain* (like my cow-orker Kevin) would spot that this:
> select(6, [5], NULL, NULL, {0, 500}) = 0 (Timeout)
means I turned the global network timeout down, and I turned it down *too far*.
Which leads inexorably back to the first rule of working with new software: if you change any default settings at *all* before you have it working -- or even just before you at least *try* the defaults, then you are, as I am... a moron.
Nice package, Phil, even if I'm not smart enough to use it. :-)
> select(6, [5], NULL, NULL, {0, 500}) = 0 (Timeout)
means I turned the global network timeout down, and I turned it down *too far*.
Which leads inexorably back to the first rule of working with new software: if you change any default settings at *all* before you have it working -- or even just before you at least *try* the defaults, then you are, as I am... a moron.
Nice package, Phil, even if I'm not smart enough to use it. :-)
Well. Maybe not... quite.
I do have it working, but if I try to use nphMotionJpeg, I get all kinds of binary crap in my logs, under the guise of "Unknown Media Type" (or whatever the heck it is that that HTTP header is actually called).
Switching back to SnapshotJPEG works, though even at 2500ms, I still have some selects time out.
Is the BL-C10 *really* that slow?
Could anyone who's got them running reliably please post their configs?
Switching back to SnapshotJPEG works, though even at 2500ms, I still have some selects time out.
Is the BL-C10 *really* that slow?
Could anyone who's got them running reliably please post their configs?