ZoneMinder Forums

Well loaded another SD card into my RPi4B 8Gb with the same Buster Lite image (2021-05-07-raspios-buster-armhf-lite.img) as above, and followed exactly the install procedure above (https://wiki.zoneminder.com/Debian_10_B ... om_ZM_Repo).

ZM version 1.36.0 is now up and running. And the NaN issue is still there!

Everything else seems to be working correctly -- live monitor, thumbnails, motion capture, etc. Nothing special posts to the logs when I try to view an event. And everything works fine with these same Hikvision cameras and my RPi3B running ZM v1.34.22.

For the most part my log settings are still at the defaults. I'll go play with those a bit to see if anything more useful pops up in the logs.

Still working this NaN issue. Time available is limited but this is what I have found so far:

1) The problem is present on all installations I have tried on my 8Gb Raspberry Pi 4. These include:

- The full (and fully updated) GUI system that came with the Raspberry Pi. On this system I first installed ZM 1.32 from the RPi repos, then used the ZM repo to upgrade to 1.34.22 and later 1.36.0
- The RPi Lite OS installed exactly as per the ZM wiki instructions for ZM 1.36.0, except that I substituted the 1.34.22 repo,
- and RPi Lite OS again exactly as the wiki directs, including the 1.36.0 repo.

2) The problem does NOT occur on my RPi 3B which is still running ZM 1.34.22.

- The 3b is also a stock RPi full-GUI system where I first installed ZM 1.32 from the default RPi repos, then upgraded to 1.34.22 from the ZM repo.
- I am limited in my ability to debug on the RPi 3b because it is a remote installation and currently in use as a security system

By enabling debug logs on zms (debug level 4) I can see that the jQuery status reply goes out as expected:
You can see it has the Event, Duration, Paused, Progress, Rate and Zoom values.

However when received at the (Firefox) client, the browser's debugger shows the received data only has Rate and Zoom values, both of which are zero. Yet the packet status is "Ok" and result is "Success." I set a breakpoint at getCmdResponse() in skins/classic/views/js/event.js

It is acting like the client interprets the data differently (perhaps as an object?) from how the server is sending it (maybe as an array?)

I see this same behavior in all installations that show the NaN problem.

I have tried to get the RPi 3b to spit out similar debug messages for comparison, but oddly I can't seem to get that to work on the 3b system. I get no debug messages from the zms component, even if I leave the target field blank instead of setting it to _zms. And on the receiving end, the debugger never breaks on getCmdResponse(). Yet the event display seems to work as designed. It's acting like the QUERY-STATUS command-response never happens on the RPi3b.

I will be at the RPi 3b location later this week. I will try to swap in an SD card prepped with Buster Lite and ZM as per the wiki to see if I can get debug logging to behave any better.

If anyone has any suggestions or guidance based on what I'm seeing, let me know!

OK, I was finally able to get the naanaanaa and etc.
Fresh install of Raspberry lite with Apache2, Mariadb and PhP. Zoneminder 1.34.22
With ZM set to record videos (Video Writer H264 or H264 Camera Passthrough) playback workd "normally"
With ZM Set to Save JPEGs (Frames or Frames+ Analysis omages) playback froze and NaaNaa

So,the solution is to use the Video Writer. Yes, it could be a hardware issue with Pi-4. More likely an FFMPEG issue.
But the install procedure in the WIKI is correct.

Thanks for looking into it. Yes I have been using FFMPEG in all cases above. I will go explore other options there.

FWIW...
If you are having issues with your Pi 4 on Rasberry OS 32 bit You might want to try Ubuntu 20.04. There is a 32 and 64 bit version for the Pi 3 and Pi 4 that works well with Zoneminder. Today I tested the 64 bit version with Zoneminder 1.36.5 storing JPEGs or video. Both played back without the NaaNaa error in the progress bar.
Ubuntu Server 20.04 can be installed to your micro SD card or a thumbdrive with Raspberry Imager: https://www.raspberrypi.org/software/

One note of caution with this Ubuntu setup: Unattended upgrades will run automatically upon install and connection to the network. This will make things slow until it finishes.

I can confirm that on my RPi4 with Buster Lite and ZM 1.36.0, changing Video Writer from Disabled to Camera Passthrough was all that it took to cure the NaN issue.

"Save JPEGs" apparently can be any setting (I had "Frames and Analysis Images" selected for all of the tests above). I assume the same will be true on all of the other operating system variants I tried.

I also see that with Video Writer set to Camera Passthrough, the debug behavior is now identical to ZM 1.34.22 (without Video Writer enabled) on my RPi3.

Specifically:

- if I enable debug level logging on files, set target to _zms and debug level to 4, I get no log files at all for zms or zms_m2 etc. It is as if zms is not running.
- And if I set a browser breakpoint on getCmdResponse(), execution never stops there -- suggesting the Query-Status Ajax exchange never happens.

Not sure why that is true, but that is what I see.

Your FWIW about Ubuntu 20.04 64 bit does sound very worthwhile -- since the whole point of this RPi4 experiment was to evaluate the performance improvements possible in ZM by upgrading from RPi3 (2GB) to RPi4 (8GB). I think I will have to explore the Ubuntu 20.04 option.

But that effort is probably more appropriate for another thread. For this thread I think it is sufficient to say that if you see the NaN issue when displaying events, try setting Video Writer to Camera Passthrough!

Just a follow up here. I did successfully install Ubuntu 20.04 and ZM 1.36.5. I can confirm that it does NOT have the NaN issue when Video Writer is Disabled. Event playback is not great -- jumpy and halts often -- still investigating why. But event playback does basically work.

This process also led to a bit of a "lightbulb moment" for me that I thought would be worth sharing in this thread.

In the post above, I did not understand why my breakpoints weren't being hit, and why I wasn't getting debug messages from zms. Now I think I understand.

When Video Writer is not "Disabled", there will be a video file in the subdirectory for that event. When you go to view the event, ZM will use that video file for play,, pause, frame forward and frame reverse. In this case it seems possible that zms is not even invoked for these operations -- that would explain why I didn't get any debug messages from zms when Video Writer was enabled.

However, when Video Writer is Disabled (as it was during all of my NaN issues), then ZM does not write a video file into the event directory. For my tests I always had the "Save JPEGs" option set to "Frames and Analysis Images (if available)". So my event directories had lots of JPEGs, but no MP4 video file.

ZM tries to do the best it can -- so zms tries to play the JPEGs in sequence, to approximate a video stream. This is where I saw the debug QUERY-STATUS messages coming from zms and hit a breakpoint at getCmdResponse() in the browser.

But there is some bug in the Ajax data exchange when running on Raspian OS -- and that's what results in the received data in the browser receiving no Progress field (among others) -- which then causes the Javascript to spit out NaNs when it can't find the field it's expecting.

However, on the Ubuntu 20.04 OS if you Disable Video Writer, sure enough you can break on getCmdResponse() and see all the correct fields in the JSON packet sent over by zms.

So the reason why enabling Video Writer cures the NaN issue on Raspian OS is because the code that tries to approximate video by sending a bunch of JPEGs doesn't have to run -- it just sends the video file instead. And the bug is not present in Ubuntu 20.04 -- so ZM can send all those JPEGs without error when there is no video file.

On a practical level, if your camera puts out H264 then I can't see any reason why you _wouldn't_ want to have Video Writer set to Camera Passthrough. I had it Disabled only because that was the default in those ZM versions I was working with, and I did not understand exactly what it was doing anyway. Now I do1