Connection problem from Windows to Linux

[satoshi5454]

I have a problem related to LSL connection from windows to Linux. An inlet working on Linux can't find an outlet working on Windows.
The detail is below:

I have 3 programs.

• program1 (C++): gets sensor data from NI board, and sends it to program2 using LSL
• program2 (MATLAB): gets data from program1 using LSL, processes it, and sends the result to program3 using LSL
• program3 (Python): gets data from program2 using LSL, and shows the image file according to the get data

I run program1 and program2 on the same Windows PC (Windows 10), and program3 on the Linux PC (Ubuntu 20.04).
If I run program2 before program1, program3 can find the outlet of program2 and get data.
But I run program1 before program2, program3 can't find the outlet of program2.

When I use Lab Recorder working on the Linux PC, Lab Recorder can't find the outlet of program2 in the case that program1 has been run before program2.

Instead of my own programs, I use the SendData.exe of the lslexamples (program1), and the simple MATLAB program that only gets data and sends it using LSL (program2), then Lab Recorder on the Linux PC can't find the outlet of the MATLAB program similarly.

Do you have any ideas to solve this problem?

[cboulay]

To summarize:

Windows PC: NI board C++ --> Matlab processing -->
Linux (20.04): --> Python feedback

Linux cannot resolve the Matlab stream if the NI stream is created first.

Hmm, that's definitely a weird one. I guess it has to do with multicast packets.

Check here and here.

[cboulay]

Could you retest this startup-order-dependent Windows → Linux discovery problem with liblsl v1.18.0.b3? The release assets are now available.

The beta includes #278, which sends UDP discovery queries from the same socket that receives replies, addressing a source/return-port mismatch relevant to stateful firewalls. It also includes improvements to same-machine discovery (#282) and handling unusable multicast interfaces (#283). These are relevant changes, but we have not reproduced your particular cross-machine failure and are not marking it fixed yet.

Please verify which liblsl build is actually loaded by each application (C++, MATLAB, Python, and/or LabRecorder); upgrading a wrapper alone may leave an older native library in use. If it still fails, please provide:

• Exact OS, application/wrapper, and loaded liblsl versions on both computers.
• A minimal reproduction with the two startup orders and which streams are visible in each case.
• Relevant lsl_api.cfg settings, network interfaces, firewall configuration, and discovery logs if available.

Please retain the original setup details where possible so we can compare results directly. Leaving this open pending updated evidence.