Lynn Jarvis

I can reproduce the crash if the fbo is allocated larger than the sender size. The reason is that the internal pixel buffer is too small to contain the pixels...

I have been able to simulate the image corruption which agrees in appearance with your earlier image.  I believe the problems can be explained if the texture is RGB...

Excellent. A few errors were fixed along the way too so this has been a useful exercise.

Thanks for the change to get the correct library name for Linux. To isolate the sender or receiver, could you test combinations with the NDI programs "Studio Monitor" and "Test...

Should "ssize_t" be "size_t"? I answered my own question by looking this up. Can you check the return value of readlink? Is it causing an error? Use "perror"?

I checked the from the Openframeworks function "ofFilePath::getCurrentExePathFS()" and Can confirm that the final line - return ""; is missing. But the function should still return the executable path and...

ofApp.cpp [line 139](https://github.com/leadedge/ofxNDI/blob/37051b7b2135dfffa14fcb9a1f69f7aabffe41f8/example-sender-receiver/src/ofApp.cpp#L139), in the sender-receiver example activates pixel "upload" which calls the "LoadTexturePixels" function for pixel copy using pbos and ofxNDIutils::CopyImage. This can be replaced with direct Openframeworks texture...

Looks like there is a Newtek problem there. That could be the issue with the sender as well. What about the NDIlib_recv example? NDIlib_recv_PNG will show whether image data is...

I forgot to add that the equivalent for the sender is - ``` // ndiSender.SetReadback(true); ``` Disable this line. Default is false. This avoids use of pbos and OpenGL buffer...

Yes we have changed to NDI 6.0.1.1 If ofxNDIdynloader loads local library files, you could try previous versions. Try disabling async send as well - `// ndiSender.SetAsync();` One quick test...