broken debian upgrade to 1.30->1.32: multiple broken monitors

Forum for questions and support relating to the 1.32.x releases only.
marcmerlin
Posts: 80
Joined: Thu Jan 17, 2013 6:13 pm

broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by marcmerlin » Wed Dec 11, 2019 3:17 am

All my cameras were working with 1.30. Upgrading to 1.32 broke a lot of things, some of them were due to packaging issues.

Now, all my cameras that use RSTP on some way, seem to fail, and in different ways. Of course, my settings worked perfectly fine with ZM 1.30:
zmc_m17[11011]: WAR [zmc_m17] [Can't find payload details for audio payload type 97, name MPEG4-GENERIC]
zmc_m17[11011]: WAR [zmc_m17] [Can't find payload details for application payload type 111, name X-KATA]
zmc_m17[11011]: WAR [zmc_m17] [The device is using a codec that may not be supported. Do not be surprised if things don't work.]
zma_m17[10809]: INF [zma_m17] [In mode 5/1, warming up]
zma_m17[10809]: WAR [zma_m17] [Impossible situation. No timestamp on captured image index was 0, image-buffer_count was (50)]
zma_m17[10809]: WAR [zma_m17] [Impossible situation. No timestamp on captured image index was 0, image-buffer_count was (50)]
Wansview RTP/Unicast port 80 /live/ch0

zma_m23[10983]: ERR [zma_m23] [Shared data not initialised by capture daemon for monitor cam-mailbox-rear]
zmc_m23[17527]: WAR [zmc_m23] [Can't find payload details for audio payload type 97, name MPEG4-GENERIC]
zmc_m23[17527]: ERR [zmc_m23] [Unexpected response code 404, text is 'Stream Not Found']

zmc_m24[10945]: WAR [zmc_m24] [Can't find payload details for audio payload type 97, name MPEG4-GENERIC]
zmc_m24[10945]: ERR [zmc_m24] [Unexpected response code 404, text is 'Stream Not Found']
both reolink rlc-410 RTP/RTSP port 554 path /h264Preview_01_main

I've enabled PATH update, and I get this:
zmc_m24[31781]: INF [zmc_m24] [Received new Content-Base in DESCRIBE response header. Updated device Url to: 'rtsp://192.168.205.88/h264Preview_01_main/']
zmc_m24[31781]: WAR [zmc_m24] [Can't find payload details for audio payload type 97, name MPEG4-GENERIC]
zmc_m24[31781]: ERR [zmc_m24] [Unexpected response code 400, text is 'Bad Request']

This is quite vexing as now ZM is mostly dead in the water, and downgrading is very non trivial :-/

Any suggestions? Thanks, Marc

User avatar
snake
Posts: 298
Joined: Sat May 21, 2016 2:20 am

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by snake » Wed Dec 11, 2019 6:59 am

Can you confirm the streams are working in ffmpeg and/or VLC? Also see https://wiki.zoneminder.com/Finding_Camera_Stream_Paths

VLC is from gui. FFMPEG is from terminal (ffmpeg -i "rtsp://<user>:<pass> etc..." output.mp4)

Does onvif report the same paths? I've seen cameras change paths after disconnecting from them, and installing a new ZM. Onvif should indicate where they are.

User avatar
iconnor
Posts: 987
Joined: Fri Oct 29, 2010 1:43 am
Location: Toronto
Contact:

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by iconnor » Wed Dec 11, 2019 12:18 pm

Switch to ffmpeg type monitors.

Also switch to master 1.33.15. We are close to release of 1.34 and have fixed a lot since 1.32

marcmerlin
Posts: 80
Joined: Thu Jan 17, 2013 6:13 pm

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by marcmerlin » Mon Dec 16, 2019 8:16 am

snake wrote:
Wed Dec 11, 2019 6:59 am
Can you confirm the streams are working in ffmpeg and/or VLC? Also see https://wiki.zoneminder.com/Finding_Camera_Stream_Paths

VLC is from gui. FFMPEG is from terminal (ffmpeg -i "rtsp://<user>:<pass> etc..." output.mp4)

Does onvif report the same paths? I've seen cameras change paths after disconnecting from them, and installing a new ZM. Onvif should indicate where they are.
Sorry for the late reply, thank you for doing that. So, it looks like the onvif manager is broken in 1.32 and honestly while I wish I had never upgraded to start with, further upgrading to source from master, seems like just making a bad matter even worse. If stable releases aren't stable, how can I trust top of tree?
In the meantime, debian, seems to have nothing newer that 1.32.

Back to the point, one of my broken cameras is not even using RSTP, but jpegs.
http://wansview-q2-1.svh.merlins.org/mj ... .cgi?chn=0 still works fine from a browser.
In ZM, it's setup as

Code: Select all

http
simple
pict:pictpwd@wansview-q2-1
80
/mjpeg/snap.cgi?chn=0
24bit
1920
1080
orientation normal
deinterlacing disabled
it was working in ZM 1.30, and not 1.32

Code: Select all

Dec 16 00:15:06 gargamel zma_m8[13447]: INF [zma_m8] [In mode 5/1, warming up]
Dec 16 00:15:06 gargamel zma_m8[13447]: WAR [zma_m8] [Impossible situation.  No timestamp on captured image index was 0, image-buffer_count was (50)]
Dec 16 00:15:06 gargamel zma_m8[13447]: WAR [zma_m8] [Impossible situation.  No timestamp on captured image index was 0, image-buffer_count was (50)]
Dec 16 00:15:06 gargamel zmdc[15144]: INF ['zma -m 8' exited normally]
Dec 16 00:15:06 gargamel zmc_m8[17018]: INF [zmc_m8] [Starting Capture version 1.32.3]
Dec 16 00:15:06 gargamel zmc_m8[17018]: WAR [zmc_m8] [Unable to capture image, retrying]
Dec 16 00:15:06 gargamel zmdc[4230]: INF ['zmc -m 8' sending stop to pid 17018 at 19/12/16 00:15:06]
Dec 16 00:15:06 gargamel zmc_m8[17018]: INF [zmc_m8] [Got signal 15 (Terminated), exiting]
Dec 16 00:15:07 gargamel zmdc[4230]: INF ['zma -m 8' already running at 19/12/16 00:15:06, pid = 17042]
Dec 16 00:15:16 gargamel zmdc[15144]: INF [Starting pending process, zma -m 8]
Dec 16 00:15:16 gargamel zmdc[15144]: INF ['zma -m 8' starting at 19/12/16 00:15:16, pid = 17276]
Dec 16 00:15:16 gargamel zmdc[17276]: INF ['zma -m 8' started at 19/12/16 00:15:16]
Dec 16 00:15:21 gargamel zmdc[4230]: INF ['zma -m 8' sending stop to pid 17042 at 19/12/16 00:15:21]
Dec 16 00:15:21 gargamel zmdc[4230]: INF ['zma -m 8' exited, signal 14]
Dec 16 00:15:22 gargamel zmdc[4230]: INF ['zmc -m 8' sending stop to pid 17018 at 19/12/16 00:15:22]
Dec 16 00:15:22 gargamel zmc_m8[17018]: INF [zmc_m8] [Got signal 15 (Terminated), exiting]
I'm not sure what to say, it's pretty disappointing.
Last edited by marcmerlin on Mon Dec 16, 2019 8:24 am, edited 3 times in total.

marcmerlin
Posts: 80
Joined: Thu Jan 17, 2013 6:13 pm

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by marcmerlin » Mon Dec 16, 2019 8:21 am

snake wrote:
Wed Dec 11, 2019 6:59 am
Can you confirm the streams are working in ffmpeg and/or VLC? Also see https://wiki.zoneminder.com/Finding_Camera_Stream_Paths

VLC is from gui. FFMPEG is from terminal (ffmpeg -i "rtsp://<user>:<pass> etc..." output.mp4)

Does onvif report the same paths? I've seen cameras change paths after disconnecting from them, and installing a new ZM. Onvif should indicate where they are.
ffmpeg -i rtsp://u:p@cam-mailbox-rear:554/h264Preview_01_main /tmp/out.mp4
out.mp4 plays ok enough.
VIDEO: [H264] 2560x1440 24bpp 12.000 fps 3925.3 kbps (479.2 kbyte/s)

setup:

Code: Select all

RTSP
RTP/RSTP
p:u@cam-mailbox-rear
554
/h264Preview_01_main
24bit
2560
1440
orientation: normal
deint: disabled
logs say:

Code: Select all

gargamel:~# tail -f /var/log/zoneminder.log | grep -E '(m 23|_m23)'
Dec 16 00:21:16 gargamel zmc_m23[26231]: FAT [zmc_m23] [No RTSP sources]
Dec 16 00:21:16 gargamel zmdc[4230]: ERR ['zmc -m 23' exited abnormally, exit status 255]
Dec 16 00:21:18 gargamel zms_m23[26348]: ERR [zms_m23] [Terminating, last frame sent time 10.103243 secs more than maximum of 10.000000]
Dec 16 00:21:19 gargamel zms_m23[26379]: WAR [zms_m23] [no last_frame_sent.  Shouldn't happen. frame_mod was (1) frame_count (0) ]
Dec 16 00:21:22 gargamel zmdc[4230]: INF ['zma -m 23' sending stop to pid 26381 at 19/12/16 00:21:22]
Dec 16 00:21:22 gargamel zmdc[4230]: INF ['zma -m 23' exited, signal 14]
Dec 16 00:21:22 gargamel zmdc[4230]: INF [Command 'zmc -m 23' removed from pending list at 19/12/16 00:21:22]
Dec 16 00:21:22 gargamel zmdc[4230]: WAR [Can't find process with command of 'zma -m 23']
Dec 16 00:21:22 gargamel zmdc[4230]: INF ['zma -m 23' starting at 19/12/16 00:21:22, pid = 26671]
Dec 16 00:21:22 gargamel zmdc[26671]: INF ['zma -m 23' started at 19/12/16 00:21:22]
Dec 16 00:21:22 gargamel zmdc[4230]: WAR [Can't find process with command of 'zmc -m 23']
Dec 16 00:21:22 gargamel zmdc[4230]: INF ['zmc -m 23' starting at 19/12/16 00:21:22, pid = 26685]
Dec 16 00:21:22 gargamel zmdc[26685]: INF ['zmc -m 23' started at 19/12/16 00:21:22]
Dec 16 00:21:23 gargamel zmdc[4230]: INF ['zma -m 23' already running at 19/12/16 00:21:22, pid = 26671]
Dec 16 00:21:23 gargamel zmc_m23[26685]: INF [zmc_m23] [Starting Capture version 1.32.3]
Dec 16 00:21:24 gargamel zmc_m23[26685]: INF [zmc_m23] [Received new Content-Base in DESCRIBE response header. Updated device Url to: 'rtsp://192.168.205.87/h264Preview_01_main/']
Dec 16 00:21:24 gargamel zmc_m23[26685]: WAR [zmc_m23] [Can't find payload details for audio payload type 97, name MPEG4-GENERIC]
Dec 16 00:21:24 gargamel zmc_m23[26685]: ERR [zmc_m23] [Unexpected response code 400, text is 'Bad Request']
Dec 16 00:21:26 gargamel zms_m23[26773]: WAR [zms_m23] [no last_frame_sent.  Shouldn't happen. frame_mod was (1) frame_count (0) ]

User avatar
snake
Posts: 298
Joined: Sat May 21, 2016 2:20 am

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by snake » Mon Dec 16, 2019 10:08 pm

For the second camera, rlc / cam-mailbox:

I don't know why I didn't notice this earlier. 1.32 and later have the ability to record audio. This was not in 1.30. It may be that the audio stream is incompatible.

Post the full output of "ffmpeg -i <stream> output.mp4" you did earlier

Then, go on the camera, and look to disable audio recording. Post the full output of ffmpeg -i again, and confirm the audio is absent (ffmpeg will indicate what streams (audio,video) it is recording when it starts). Finally, see if ZM works with audio disabled.

For the wansview:
try FFMPEG. I believe it will work with MJPEG/JPEG.

As for onvif, there are other programs, aside from ZM that should also do the same thing. More than one way to do it.

marcmerlin
Posts: 80
Joined: Thu Jan 17, 2013 6:13 pm

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by marcmerlin » Tue Dec 17, 2019 7:54 pm

Thanks @snake, good call on the audio.
I checked my RLC cameras, I made sure record audio is off, well, except that out.mp4 has audio anyway like you guessed. WTF?
Looks like it adds audio in the stream even if it's not recorded by the camera (turned off in settings).
For jpeg capture, which is my bigger problem right now as I use this on most my other cameras, I'll make a separate reply as it's a different issue.

Back to rstp, is there a way to turn off attempts at audio processing in ZM 1.32?

[lavf] stream 0: video (h264), -vid 0
[lavf] stream 1: audio (aac), -aid 0, -alang und
VIDEO: [H264] 2560x1440 24bpp 12.000 fps 3925.3 kbps (479.2 kbyte/s)
[VO_XV] Could not grab port 181.
[VO_XV] Could not grab port 182.
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 58.35.100 (external)
Mismatching header version 58.18.100
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Clip info:
major_brand: isom
minor_version: 512
compatible_brands: isomiso2avc1mp41
title: Session streamed by "preview"
encoder: Lavf58.20.100
comment: h264Preview_01_main
Load subtitles in /tmp/
==========================================================================
Forced audio codec: mad
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 16000 Hz, 1 ch, floatle, 49.5 kbit/9.67% (ratio: 6191->64000)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
==========================================================================

marcmerlin
Posts: 80
Joined: Thu Jan 17, 2013 6:13 pm

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by marcmerlin » Tue Dec 17, 2019 8:02 pm

snake wrote:
Mon Dec 16, 2019 10:08 pm
For the wansview:
try FFMPEG. I believe it will work with MJPEG/JPEG.
Jpeg capture is like a basic feature that's been in ZM forever. How can it be broken? How can I debug the meager error messages it's giving me while processing those jpegs that are otherwise perfectly fine when retrieved in a browser?

Here's a jpeg from http://cam-outgarage1/mjpeg/snap.cgi?chn=0
identify /tmp/s.jpeg
/tmp/s.jpeg JPEG 1920x1080 1920x1080+0+0 8-bit DirectClass 224KB 0.000u 0:00.000
You can get the full jpeg here: http://marc.merlins.org/tmp/wansview-q2-1.jpg

Why would ZM be unhappy with it and say this?
"No timestamp on captured image index was 0, image-buffer_count was (50)]" seems like a clue

Code: Select all

Dec 16 00:15:06 gargamel zma_m8[13447]: INF [zma_m8] [In mode 5/1, warming up]
Dec 16 00:15:06 gargamel zma_m8[13447]: WAR [zma_m8] [Impossible situation.  No timestamp on captured image index was 0, image-buffer_count was (50)]
Dec 16 00:15:06 gargamel zma_m8[13447]: WAR [zma_m8] [Impossible situation.  No timestamp on captured image index was 0, image-buffer_count was (50)]
Dec 16 00:15:06 gargamel zmdc[15144]: INF ['zma -m 8' exited normally]
Dec 16 00:15:06 gargamel zmc_m8[17018]: INF [zmc_m8] [Starting Capture version 1.32.3]
Dec 16 00:15:06 gargamel zmc_m8[17018]: WAR [zmc_m8] [Unable to capture image, retrying]
Dec 16 00:15:06 gargamel zmdc[4230]: INF ['zmc -m 8' sending stop to pid 17018 at 19/12/16 00:15:06]
Dec 16 00:15:06 gargamel zmc_m8[17018]: INF [zmc_m8] [Got signal 15 (Terminated), exiting]
Dec 16 00:15:07 gargamel zmdc[4230]: INF ['zma -m 8' already running at 19/12/16 00:15:06, pid = 17042]
Dec 16 00:15:16 gargamel zmdc[15144]: INF [Starting pending process, zma -m 8]
Dec 16 00:15:16 gargamel zmdc[15144]: INF ['zma -m 8' starting at 19/12/16 00:15:16, pid = 17276]
Dec 16 00:15:16 gargamel zmdc[17276]: INF ['zma -m 8' started at 19/12/16 00:15:16]
Dec 16 00:15:21 gargamel zmdc[4230]: INF ['zma -m 8' sending stop to pid 17042 at 19/12/16 00:15:21]
Dec 16 00:15:21 gargamel zmdc[4230]: INF ['zma -m 8' exited, signal 14]
Dec 16 00:15:22 gargamel zmdc[4230]: INF ['zmc -m 8' sending stop to pid 17018 at 19/12/16 00:15:22]
Dec 16 00:15:22 gargamel zmc_m8[17018]: INF [zmc_m8] [Got signal 15 (Terminated), exiting]

marcmerlin
Posts: 80
Joined: Thu Jan 17, 2013 6:13 pm

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by marcmerlin » Tue Dec 17, 2019 8:21 pm

I enabled debug logging and found more stuff in /tmp/zm/zm_debug.log.28351 but nothing obviously wrong.
Does it look helpful to you?

Code: Select all

zmc_m8[28351].DB1-zm_logger.cpp/251 [LogOpts: level=DB1/DB1, screen=OFF, database=OFF, logfile=DB1->/tmp/zm/zm_debug.log.28351, syslog=DB9]
zmc_m8[28351].DB1-zm_utils.cpp/284 [Detected a x86\x86-64 processor with AVX]
zmc_m8[28351].DB1-zm_monitor.cpp/2059 [Got 0 for v4l_captures_per_frame]
zmc_m8[28351].DB1-zm_monitor.cpp/406 [monitor purpose=1]
zmc_m8[28351].DB1-zm_monitor.cpp/416 [mem.size SharedData=600 TriggerData=560 VideoStoreData=4116 total=311045740]
zmc_m8[28351].DB1-zm_storage.cpp/94 [No id passed to Storage constructor.  Using default path /var/cache/zoneminder/events instead]
zmc_m8[28351].DB1-zm_monitor.cpp/420 [Storage path: /var/cache/zoneminder/events]
zmc_m8[28351].DB1-zm_monitor.cpp/551 [Unable to map file /dev/shm/zm.mmap.8 (311045740 bytes) to locked memory, trying unlocked]
zmc_m8[28351].DB1-zm_monitor.cpp/555 [Mapped file /dev/shm/zm.mmap.8 (311045740 bytes) to unlocked memory]
zmc_m8[28351].DB1-zm_monitor.cpp/486 [Monitor cam-outgarage1 has function 5]
zmc_m8[28351].DB1-zm_monitor.cpp/487 [Monitor cam-outgarage1 LBF = '%N - %y/%m/%d %H:%M:%S', LBX = 0, LBY = 0, LBS = 1]
zmc_m8[28351].DB1-zm_monitor.cpp/488 [Monitor cam-outgarage1 IBC = 50, WUC = 25, pEC = 25, PEC = 100, EAF = 1, FRI = 1000, RBP = 0, ARBP = 0, FM = 0]
zmc_m8[28351].DB1-zm_zone.cpp/862 [Got 1 zones for monitor cam-outgarage1]
zmc_m8[28351].DB1-zm_monitor.cpp/2322 [Loaded monitor 8(cam-outgarage1), 1 zones]
zmc_m8[28351].INF-zmc.cpp/223 [Starting Capture version 1.32.3]
zmc_m8[28351].WAR-zm_remote_camera_http.cpp/1092 [Unable to capture image, retrying]
zmc_m8[28351].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[28351].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[28351].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[28351].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[28351].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[28351].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[28351].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[28351].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[28351].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[28351].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[30631].DB1-zm_logger.cpp/251 [LogOpts: level=DB1/DB1, screen=OFF, database=OFF, logfile=DB1->/tmp/zm/zm_debug.log.30631, syslog=DB9]
zmc_m8[30631].DB1-zm_utils.cpp/284 [Detected a x86\x86-64 processor with AVX]
zmc_m8[30631].DB1-zm_monitor.cpp/2059 [Got 0 for v4l_captures_per_frame]
zmc_m8[30631].DB1-zm_monitor.cpp/406 [monitor purpose=1]
zmc_m8[30631].DB1-zm_monitor.cpp/416 [mem.size SharedData=600 TriggerData=560 VideoStoreData=4116 total=311045740]
zmc_m8[30631].DB1-zm_storage.cpp/94 [No id passed to Storage constructor.  Using default path /var/cache/zoneminder/events instead]
zmc_m8[30631].DB1-zm_monitor.cpp/420 [Storage path: /var/cache/zoneminder/events]
zmc_m8[30631].DB1-zm_monitor.cpp/551 [Unable to map file /dev/shm/zm.mmap.8 (311045740 bytes) to locked memory, trying unlocked]
zmc_m8[30631].DB1-zm_monitor.cpp/555 [Mapped file /dev/shm/zm.mmap.8 (311045740 bytes) to unlocked memory]
zmc_m8[30631].DB1-zm_monitor.cpp/486 [Monitor cam-outgarage1 has function 5]
zmc_m8[30631].DB1-zm_monitor.cpp/487 [Monitor cam-outgarage1 LBF = '%N - %y/%m/%d %H:%M:%S', LBX = 0, LBY = 0, LBS = 1]
zmc_m8[30631].DB1-zm_monitor.cpp/488 [Monitor cam-outgarage1 IBC = 50, WUC = 25, pEC = 25, PEC = 100, EAF = 1, FRI = 1000, RBP = 0, ARBP = 0, FM = 0]
zmc_m8[30631].DB1-zm_zone.cpp/862 [Got 1 zones for monitor cam-outgarage1]
zmc_m8[30631].DB1-zm_monitor.cpp/2322 [Loaded monitor 8(cam-outgarage1), 1 zones]
zmc_m8[30631].INF-zmc.cpp/223 [Starting Capture version 1.32.3]
zmc_m8[30631].WAR-zm_remote_camera_http.cpp/1092 [Unable to capture image, retrying]
zmc_m8[30631].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]
zmc_m8[30631].INF-zm_signal.cpp/40 [Got signal 15 (Terminated), exiting]

CountyLine
Posts: 61
Joined: Thu Aug 29, 2019 5:22 pm
Location: USA

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by CountyLine » Wed Dec 18, 2019 4:07 am

For what its worth, I too upgraded to 1.32 on Debian (Sid) and found myself with an essentially useless ZoneMinder installation. I bit the bullet and moved to 1.33.

All is fine now. 1.33 is by far the most stable ZoneMinder installation I have enjoyed to date.

User avatar
snake
Posts: 298
Joined: Sat May 21, 2016 2:20 am

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by snake » Thu Dec 19, 2019 6:51 pm

ZMRepo has packages for 1.33 for Debian.

Can always go back to 1.32 if that doesn't work. As was mentioned, I would try FFMPEG for the jpeg cameras. Functionally its no different from Remote to the end user.

marcmerlin
Posts: 80
Joined: Thu Jan 17, 2013 6:13 pm

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by marcmerlin » Thu Dec 19, 2019 7:18 pm

Thanks snake. https://zmrepo.zoneminder.com/ it is, will look.
As for jpeg pull vs ffmpeg/rtsp, they are quite different.
1) I have 15 cameras and more network bandwidth than CPU on my server. rtsp requires work to handle the compressed video, more work than jpegs
2) if my server gets overwhelmed, the rstp shoved at it will get out of sync, I'll get half frames, garbage that will trigger events and I don't want that. RSTP is generally fragile because there is no flow control, you keep up or you lose. Jpeg has no such issue.

Generally I'm sad that such a simple day 1 feature as jpeg is now half broken in ZM 1.32, at least the debian version, and that the logs and even debug logs, give 0 information as to what's going on.
Since I'm hosed as of right now, I'll upgrade to 1.33, but I don't think I can go back to 1.32, just like I can't go back to 1.30. Once my DB has been upgraded, I don't think downgrades work.

User avatar
snake
Posts: 298
Joined: Sat May 21, 2016 2:20 am

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by snake » Thu Dec 19, 2019 8:47 pm

marcmerlin wrote:
Tue Dec 17, 2019 7:54 pm
Back to rstp, is there a way to turn off attempts at audio processing in ZM 1.32?
Without looking at the code, in 1.33 (and assuming also 1.32) audio is only recorded in FFMPEG and storage of H264 passthrough.

I don't know if it still parses the audio, when you use either Save JPEG or H264 encode, but I suppose you should try that. May be worth investigating whether audio parsing should be disabled, if it's not enabled. Here it looks like bad audio broke the recording.

marcmerlin
Posts: 80
Joined: Thu Jan 17, 2013 6:13 pm

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by marcmerlin » Fri Dec 20, 2019 6:53 am

marcmerlin wrote:
Thu Dec 19, 2019 7:18 pm
Thanks snake. https://zmrepo.zoneminder.com/ it is, will look.
As for jpeg pull vs ffmpeg/rtsp, they are quite different.
1) I have 15 cameras and more network bandwidth than CPU on my server. rtsp requires work to handle the compressed video, more work than jpegs
2) if my server gets overwhelmed, the rstp shoved at it will get out of sync, I'll get half frames, garbage that will trigger events and I don't want that. RSTP is generally fragile because there is no flow control, you keep up or you lose. Jpeg has no such issue.

Generally I'm sad that such a simple day 1 feature as jpeg is now half broken in ZM 1.32, at least the debian version, and that the logs and even debug logs, give 0 information as to what's going on.
Since I'm hosed as of right now, I'll upgrade to 1.33, but I don't think I can go back to 1.32, just like I can't go back to 1.30. Once my DB has been upgraded, I don't think downgrades work.
Mmmh, the only i386 package I found doesn't seem very happy on my system

Code: Select all

gargamel:/tmp# dpkg -i zoneminder_1.33.16~20191220.6-stretch_i386.deb 
(Reading database ... 251775 files and directories currently installed.)
Preparing to unpack zoneminder_1.33.16~20191220.6-stretch_i386.deb ...
Unpacking zoneminder (1.33.16~20191220.6-stretch) over (1.32.3-2) ...
dpkg: dependency problems prevent configuration of zoneminder:
 zoneminder depends on libavcodec57 (>= 7:3.2.14) | libavcodec-extra57 (>= 7:3.2.14); however:
  Package libavcodec57 is not installed.
  Package libavcodec-extra57 is not installed.
 zoneminder depends on libavformat57 (>= 7:3.2.14); however:
  Package libavformat57 is not installed.
 zoneminder depends on libavutil55 (>= 7:3.2.14); however:
  Package libavutil55 is not installed.
 zoneminder depends on libmariadbclient18 (>= 10.1.41-0+deb9u1); however:
  Package libmariadbclient18 is not installed.
 zoneminder depends on libmp4v2-2; however:
  Package libmp4v2-2 is not installed.
 zoneminder depends on libswresample2 (>= 7:3.2.14); however:
  Package libswresample2 is not installed.
 zoneminder depends on libswscale4 (>= 7:3.2.14); however:
  Package libswscale4 is not installed.
 zoneminder depends on libx264-148; however:
  Package libx264-148 is not installed.
 zoneminder depends on libnumber-bytes-human-perl; however:
  Package libnumber-bytes-hu
dpkg: error processing package zoneminder (--install):
gargamel:/tmp# apt-get -f install
The following packages will be REMOVED:
  consolekit zoneminder
will play with it some more to see if I can make it work somehow

marcmerlin
Posts: 80
Joined: Thu Jan 17, 2013 6:13 pm

Re: broken debian upgrade to 1.30->1.32: multiple broken monitors

Post by marcmerlin » Sun Dec 22, 2019 10:45 pm

vikiyaty wrote:
Sun Dec 22, 2019 4:22 pm
Sorry for the late reply, thank you for doing that. So, it looks like the onvif manager is broken in 1.32 and honestly while I wish I had never upgraded to start with, further upgrading to source from master, seems like just making a bad matter even worse. If stable releases aren't stable, how can I trust top of tree?
Unfortunately, that's exactly my thought too (and I wrote something similar upthread).
I've been using and contributing/writing to open source for over 25 years, and most times I've seen this happen, it's always been between bad news and very bad news for general code health.

Even if stick with ZM, which I'm really reconsidering now given how much time I've lost on it, how can I ever trust new versions, never mind code between releases?

I am grateful to all the volunteers who have put work into this code. Where it's gone to given where it came from, is truly inspiring, but unfortunately it doesn't negate the above either. Stable releases without clear problems or even possible big regressions, is something paramount to users. Hopefully this is something that can get back on track.

Post Reply

Who is online

Users browsing this forum: No registered users and 17 guests