zoneminder mixing up my sources
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
-
- Posts: 32
- Joined: Sat Sep 17, 2005 4:10 pm
- zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
That's not actually the request to zms, but it will be in that page generated. An empty mode I think will just cause it to use the default and I think control is just blank, the space separates the url from the protocol. If you can get the contents of the page generated by your request it might tell us a bit more.
Phil
Phil
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
-
- Posts: 32
- Joined: Sat Sep 17, 2005 4:10 pm
Phil: a strings-filtered Ethereal capture of the session is at http://salem.dyndns.org/zmlogs/zm.dmp.txt
- zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
It's a bit of a long shot but have you tried changing your zms path to nph-zms rather than just zms? I'm a little concerned to see chunked encoding in your transfer log and I'm wondering if this messes things up at all. Using an nph script should prevent your httpd from interfering with the stream.
Phil
Phil
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
-
- Posts: 32
- Joined: Sat Sep 17, 2005 4:10 pm
-
- Posts: 32
- Joined: Sat Sep 17, 2005 4:10 pm
-
- Posts: 32
- Joined: Sat Sep 17, 2005 4:10 pm
Started looking through the zms debug output, see ***:
Sep 22 23:05:00 salem last message repeated 11 times
Sep 22 23:05:00 salem zms[667]: INF [16/20: ]
Sep 22 23:05:00 salem zms[667]: INF [Image size 19185]
Sep 22 23:05:00 salem zms[667]: INF [shared_data 4098e000]
Sep 22 23:05:01 salem last message repeated 13 times
Sep 22 23:05:01 salem zms[667]: INF [17/20: ]
Sep 22 23:05:01 salem zms[667]: INF [Image size 19185]
Sep 22 23:05:01 salem zms[667]: INF [shared_data 4098e000]
Sep 22 23:05:01 salem zms[667]: INF [19/20: ]
*** Sep 22 23:05:01 salem zms[667]: INF [Image size 21770] ***
Sep 22 23:05:01 salem zms[667]: INF [shared_data 4098e000]
Sep 22 23:05:00 salem last message repeated 11 times
Sep 22 23:05:00 salem zms[667]: INF [16/20: ]
Sep 22 23:05:00 salem zms[667]: INF [Image size 19185]
Sep 22 23:05:00 salem zms[667]: INF [shared_data 4098e000]
Sep 22 23:05:01 salem last message repeated 13 times
Sep 22 23:05:01 salem zms[667]: INF [17/20: ]
Sep 22 23:05:01 salem zms[667]: INF [Image size 19185]
Sep 22 23:05:01 salem zms[667]: INF [shared_data 4098e000]
Sep 22 23:05:01 salem zms[667]: INF [19/20: ]
*** Sep 22 23:05:01 salem zms[667]: INF [Image size 21770] ***
Sep 22 23:05:01 salem zms[667]: INF [shared_data 4098e000]
-
- Posts: 32
- Joined: Sat Sep 17, 2005 4:10 pm
-
- Posts: 32
- Joined: Sat Sep 17, 2005 4:10 pm
You know what though...earlier logs indicated that zmc was sticking with the program as far as capture goes - the same image size was getting picked up every time. This makes me think that there's some problem with the way the shared memory is being used.
In my last posted log, the "x/y" indicates the current last written index (x) and the total number of buffers for that source (y). It's odd that the index jumps around and back again, and that every time it jumps, zms gets the wrong image.
In my last posted log, the "x/y" indicates the current last written index (x) and the total number of buffers for that source (y). It's odd that the index jumps around and back again, and that every time it jumps, zms gets the wrong image.