Frigate installs this bundle into its container image by pinning tag v2.1.0 (see docker/main/install_memryx.sh). SDK 2.2 is now the current release, but there is no 2.2 tag here — main still ships memryx/x86/libmemx.so.2.1.0 and was last updated 2025-11-13.
What is already available for 2.2:
- apt (
https://developer.memryx.com/deb): memx-drivers 2.2.4-1, memx-accl 2.2.5-1, mxa-manager 2.2.5-1, for both amd64 and arm64
- docs: SDK 2.2 is the unversioned
developer.memryx.com root; 2.1 is archived under /2p1/
The memryx wheel from developer.memryx.com/pip is not a drop-in substitute for this bundle inside a container. Its package __init__ imports memryx.neural_compiler, so a plain --no-deps install fails with ModuleNotFoundError: No module named 'pyximport', and satisfying it fully would pull in torch/tensorflow/PySide6. Removing the neural_compiler and gui trees and substituting a runtime-only __init__ that imports mxa/mxapi alongside Dfp/*Accl does work (99M -> 31M, AsyncAccl connects to mxa-manager and a 2p0-era DFP parses), but that is vendor-package surgery that does not belong in Frigate's Dockerfile.
Request: tag a 2.2 bundle in the same shape as v2.1.0 — runtime-only memryx package plus libmemx.so/libmx_accl.so for cp311/cp312 on x86_64 and aarch64.
For context on urgency: this is not currently breaking anything. Per memx/accl/messages.h in memx-accl 2.2.5, SDK 2.0/2.1 clients speak PROTO_1, SDK 2.2 speaks PROTO_2, and a 2.2 mxa-manager accepts both [1,2] — so the existing 2.1 in-container client works against a 2.2 host. A 2.2 bundle is needed to move the container side forward, not to keep it working.
Frigate installs this bundle into its container image by pinning tag
v2.1.0(seedocker/main/install_memryx.sh). SDK 2.2 is now the current release, but there is no 2.2 tag here —mainstill shipsmemryx/x86/libmemx.so.2.1.0and was last updated 2025-11-13.What is already available for 2.2:
https://developer.memryx.com/deb):memx-drivers2.2.4-1,memx-accl2.2.5-1,mxa-manager2.2.5-1, for both amd64 and arm64developer.memryx.comroot; 2.1 is archived under/2p1/The
memryxwheel fromdeveloper.memryx.com/pipis not a drop-in substitute for this bundle inside a container. Its package__init__importsmemryx.neural_compiler, so a plain--no-depsinstall fails withModuleNotFoundError: No module named 'pyximport', and satisfying it fully would pull in torch/tensorflow/PySide6. Removing theneural_compilerandguitrees and substituting a runtime-only__init__that importsmxa/mxapialongsideDfp/*Accldoes work (99M -> 31M,AsyncAcclconnects tomxa-managerand a 2p0-era DFP parses), but that is vendor-package surgery that does not belong in Frigate's Dockerfile.Request: tag a 2.2 bundle in the same shape as
v2.1.0— runtime-onlymemryxpackage pluslibmemx.so/libmx_accl.sofor cp311/cp312 on x86_64 and aarch64.For context on urgency: this is not currently breaking anything. Per
memx/accl/messages.hinmemx-accl2.2.5, SDK 2.0/2.1 clients speakPROTO_1, SDK 2.2 speaksPROTO_2, and a 2.2mxa-manageraccepts both[1,2]— so the existing 2.1 in-container client works against a 2.2 host. A 2.2 bundle is needed to move the container side forward, not to keep it working.