Hi James, thanks for reaching out. And no, I've not abandoned ship yet. Running the tiny cluster as a render farm is just too tempting. Nevertheless it's already a challenge to get it running anyway with a number of other apps as well, especially with K3S :) ... And yes, I wish they were 64 bit. I just have 32 of those 2B monsters so that's what I have to work with together with a few (virtual) X86-machines. Indeed when availability gets better, I will expand the cluster with probably 3 8Gb 4B's and a Nvidea Jetson. Meanwhile . . . It's correct that you have not supported 32-bit officially however 030 and 031 did not exclude that either. In the 030 and 031 the __INI__.py scripts only differentiated between Darwin, Windows and Linux. Only from 032 onwards, Linux 64-bit came in to play making the 32-bit obviously invalid. But anyway, Blender 2.83.5 runs fine on the Raspbian 11 Bullseye 2B's and Python version 3.9.2 too. So it was a bit weird to see that Blender with a full (albeit very slow) GUI did a render-test with the standard cube in about 5 seconds, whereas a Blender 2.83 + CrowdRender 030 on both ends took 28 seconds. That means the obviously the communication overhead is so vast, the "bacth network" version takes a factor >4 compared to the GUI version. I must admit that after swapping back and forth with versions from 030 up to 041, I sometimes got a surprising and unexplained 7.5 seconds which would be somewhat acceptable. After all, the load would be shared between 20+ nodes. In an attempt to get 041 working on a 2B, I did not only change the code in the __INIT__.py script but of course in a special 041-zip I did also include the folders in a new Linux_aarch32 folder with the pymzq binaries copying them from an older 030 version (which apparently worked). So actually i don't quite understand why I got the pymzq errors earlier since you obviously include them in your install bundle anyway. So since this is not working well, I assume that the handling of them changed as well from versions 032 onwards until 041. With a Blender 2.83 on the Mac syncing does not happen at all without any error messages in the log to show. I also must say that after flipping between various versions of Crowdrender, the install started to act "weird". See screenprint. I could not explain the cause or got over it. I guess I have to clean ~/library/ApplicationSupport or sth like that. Strangely enough with a Blender 2.91.1 and CrowdRender 041 sync starts, tries to upload an untitled.blend file unasked, that gives an error on the node "file written by a newer Blender binary." (that's right) followed up by an error "engine 'Crowdrender' not available for scene 'Scene'" and then the Mac abandons the sync again with a fail :((( All help and tip's highly appreciated. I can do some programming myself but need some guidance where to look :))) Cheers, Rob

To answer some of my questions myself: obviously from CR032 onwards, it's been decided not to support armv7l anymore. When installing, in __INIT__.py all Linux archs except x86_64 and aarch64 became invalid. I've tried to bake sth myself from CR030 and CR041 but that did not go very well. Sync from my Mac (CR030 and CR041) does start (sometimes) but fails quickly. def select_platform(): """ checks python/blender versions and sets import paths accordingly """ global cr_source if platform.system() == 'Darwin' and platform.machine() == 'x86_64': set_sys_path('Darwin_x86_64') elif platform.system() == 'Darwin' and platform.machine() == 'arm64': set_sys_path('Darwin_arm64') elif platform.system() == 'Linux' and platform.machine() == 'x86_64': set_sys_path('Linux_x86_64') elif platform.system() == 'Linux' and platform.machine() == 'aarch64': set_sys_path('Linux_aarch64') """ add 32 bit architecture to include 32 bit ZMQ libraries """ elif platform.system() == 'Linux' and platform.machine() == 'armv7l': set_sys_path('Linux_aarch32') elif sys.platform.startswith('win'): set_sys_path('Win64') else: raise RuntimeError(f" unsupported operating system! :\ {sys.version_info} Linux, MacOS and Win64 are supported") from . import cr_source Nowhere to go obviously. Probably abandoning this route. Cheers.