Support ZM 1.38.0 SharedData struct format and fix decode errors#58
Support ZM 1.38.0 SharedData struct format and fix decode errors#58jantman wants to merge 1 commit intoZoneMinder:masterfrom
Conversation
ZoneMinder 1.38.0 changed the SharedData struct in shared memory: - Added image_count, latitude, longitude fields - Renamed 'active' bool to 'capturing', added 'analysing', 'recording', 'reserved1', 'reserved2' bool fields - Added last_viewed_time, last_analysis_viewed_time time fields - Added janus_pin[64] string field This change auto-detects the ZM version by reading the 'size' field (first uint32 in SharedData) and selecting the appropriate struct format (760 bytes for ZM 1.36, 872 bytes for ZM 1.38). For backward compatibility, when reading ZM 1.38 shared memory, the returned dict includes 'active' as an alias for 'capturing'. Also fixes UnicodeDecodeError on non-UTF-8 bytes in shared memory string fields by using .decode(errors='replace').
|
Curious - what issue are you seeing with the shared struct? I am on 1.37.77 with my fork of pyzm (0.4.0) and I'm not seeing an issue |
|
I use https://github.com/jantman/zoneminder-prometheus-exporter to send a bunch of stats from ZM to Prometheus, and then on to Grafana for dashboarding and alerting on things like last write time for a monitor, etc. With the existing pyzm that was working with 1.36.33, I was seeing some crazy numbers for some of the metrics. I threw the problem to Claude and it looked at the ZM code and determined that the overall size of the shared memory struct had changed, and therefore some of the offsets were incorrect. These fixes appear to address the issue. One note, I went right from 1.36.33 to 1.38.0. Claude's comments about this:
I didn't dig into the struct code myself, but I can say that with these changes I'm now seeing the proper results again. |
|
There is a problem here. 194b55a21ca34b8deee824b8915b1fa79bd906aa add image_count and two reserved fields to fix issues with imagesize, last_frame_score and audio_frequency... that was 1.36.34. So you need yet another 1.36 struct for 1.36.34 onwards |
|
Oh. Well... crap. I guess that's what I get for staying on 1.36.33 until last week :( I'll have a go at this over the weekend. I've never had 1.36.34 running, so will need to spin it up to test. |
|
Hi @jantman, thanks for this PR. I'm Claude, an AI assistant working with @pliablepixels on pyzm v2. We've incorporated your fixes into pyzm v2. Same approach — size-based auto-detection from the first Regarding @connortechnology's comment about 1.36.34 — I checked ZM commit Relevant file: https://github.com/pliablepixels/pyzm/blob/master/pyzm/zm/shm.py This repo ( |
ZM commit 194b55a added int32_t image_count after last_read_index, changing the struct size from 760 to 768 bytes. Without this layout, SharedMemory would raise ValueError on 1.36.34+ instances. Ref: ZoneMinder#58 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This fixes #57 and another significant issue I found when using pyzm with ZM 1.38.0. I've had this code running for most of the day and it seems to work well and solve the issues with the new SharedData struct format in 1.38. I have not tested on a previous version as I no longer have one.
Summary
sizefield in SharedData (first uint32) and select the correct struct format: 760 bytes for ZM 1.36.x, 872 bytes for ZM 1.38.0+image_count,latitude,longitudefields; renamedactivebool tocapturingand addedanalysing,recording,reserved1,reserved2bools; addedlast_viewed_time,last_analysis_viewed_timetime fields; addedjanus_pin[64]string fieldactiveas an alias forcapturingwhen reading ZM 1.38 shared memoryUnicodeDecodeErroron non-UTF-8 bytes in shared memory string fields by using.decode(errors='replace')instead of.decode()Test plan
_SIZE_136(760) and_SIZE_138(872) match expected struct sizesactivealias is present in returned dict when reading ZM 1.38 shared memoryUnicodeDecodeErroron monitors with non-UTF-8 bytes in string fields🤖 Generated with Claude Code