macOs - freezing for about 10 seconds when NDI sender is disconnected

[dimitre]

First of all thanks for your work, ofxNDI is great!

I'm experiencing this on macOS, not sure if it is something related to NDI itself or the addon. I'm running the example receiver, and sending NDI from NDI Test Patterns. If I close the sender (NDI Test Patterns) , after about 2 to 5 seconds the receiver hangs for about 8 seconds (beach ball cursor) and then it comes back to normal.

It seems to be related to p_NDILib->recv_destroy Have you seen something similar?

[leadedge]

I have not seen this effect.

p_NDILib->recv_destroy would be called in ofxNDIreceive::ReleaseReceiver() when the Test Patterns application is closed. But I have never seen a delay there. You could check that with a couple of printf statements.

In ofxNDIreceive::FindGetSources there is a call to "p_NDILib->find_wait_for_sources" with a 1 msec timeout and in ofxNDIreceive::CreateReceiver there is a loop calling "p_NDILib->find_get_current_sources" with a 4 second timeout in case of network dropout. You could try to find any problems there.

You could try different versions of the NDI library by copying the relevant dll into the "bin" folder or removing this file to use the runtime library.

[dimitre]

@leadedge I now finally took some time to see this, and the function that actually takes a while (and freezes software) is this one

        p_NDILib->recv_destroy(pNDI_recv);

As I'm using in a time sensitive application (film set) I was wondering if the receiver needs to be destroyed when NDI stops receiving from some source. For example openFrameworks ofVideoPlayer object still exists if you close the video and open another. so I've commented out this parts, just for testing

//  if(pNDI_recv) 
//      p_NDILib->recv_destroy(pNDI_recv);
//  pNDI_recv = nullptr;
//  bReceiverCreated = false;

And it doesn't freeze the software anymore, but if I open Test Patterns it takes a while to connect again (about 12, 13 seconds)

[dimitre]

Seems like this, but strangely it is from 2017 and they said it was already fixed https://forums.newtek.com/threads/hang-in-call-to-ndilib_recv_destroy-when-source-is-closed.153412/

[leadedge]

Yes it works. Because pNDI_recv is set to null, the receiver is created again with a new pointer. The only problem could be a leak. But this could be acceptable.

On a single machine, I find that there is typically 20-50msec delay for p_NDILib->recv_destroy. But if the sender selection is repeated quickly, the delay can be up to 800 msec. I am not sure what this means.

[leadedge]

Because this worked, I made the corrections some time back for the "testing" branch. Please remind me if I need to make any further changes. Otherwise let's close this now.