Outlet connection fails ("received test-pattern samples do not match the specification")

[tstenner]

Hi SCCN,
I'm just following on this thread even though the problem is a bit different.
When connecting from MacOS Catalina (10.15.4) to a Windows 10 based LSL stream I get the following error:
data_receiver.cpp:340 ERR| Stream transmission broke off (The received test-pattern samples do not match the specification. The protocol formats are likely incompatible.); re-connecting...

This only happens if I connect across operating systems.
Any idea what I do wrong?

Originally posted by @MichaelUM in sccn/labstreaminglayer#57 (comment)

[tstenner]

Could you replace the liblsl library with this one and try to connect to the outlet again?

[MichaelUM]

Thanks for moving the question.
Unfortunately no luck, still the same error.

[cboulay]

Someone just messaged me on Slack with the same error using Raspberry Pi and Windows 10 using the latest pylsl on both. It's a big coincidence to get the first reports of this error twice in the same day. Was there a recent Windows update that could have done something here?

I'll try to look into it, but 2 jobs + helping with homeschooling doesn't leave a whole lot of time for volunteer work on lsl. While you wait for me, I encourage you to dive deeper into debugging if you're able.

[tstenner]

I think the fastest way without adding a ton of debug messages is a packet dump, i.e. all the network packets received from your mac: sudo tcpdump -i any -n '(udp or tcp) and portrange 16571-16600' -w lsl.pcap.

To keep things short, it'd be best to start the packet capture, connect to the outlet, pull a single sample and then quit.

[cboulay]

BTW, the conversation I had with the user who was having trouble with pi <--> Windows ended up resolving by him rebuilding liblsl.so on his pi then putting that in pylsl.

@MichaelUM , can you try rebuilding liblsl on your own? I wonder if there's something different about your MacOS configuration?

[MichaelUM]

I tried both, building it myself and using the pre-built but I god the same behavior.
Is there a specific configuration necessary to run on MacOS?

[MichaelUM]

Using a different pre-built library solved the problem.
Differences that I found were the compatibility version 1.0.0 which was in my case 0.0.0 and the @loader_path instead of @rpath which I used.

I'm not sure if this is the cause of the problem. But I definitely did something wrong when compiling / setting it up.

[cboulay]

I don't think any of us are going to do a deep dive into MacOS rpath details at the moment, so I'm going to go ahead and close this issue. Please reopen and/or comment further if you have any follow-up questions or comments.

[tstenner]

Ok, I found the bug in ffe3b09 and fixed it in 376f9e6. I've also tagged it as second prerelease for liblsl so the CI builds new packages. The 1.14.0b1 builds aren't affected, so it'd be interesting to know where the newer builds popped up a few days ago.

[cboulay]

I'm encountering this now. My android liblsl is built from the master HEAD, used by SendStringMarkers. My linux box is using pylsl 1.13.6, and there python -m pylsl.examples.ReceiveStringMarkers is complaining: Stream transmission broke off (The received test-pattern samples do not match the specification. The protocol formats are likely incompatible.); re-connecting...

Outlet	Inlet	Result
Android liblsl HEAD	Ubuntu pylsl 1.13.6	BAD
Android liblsl 1.13	Ubuntu pylsl 1.13.6	OK
Android liblsl HEAD	Ubuntu C++ examples HEAD	OK
Android liblsl HEAD	Ubuntu C++ examples 1.13	BAD
Mac pylsl 1.13.6	Ubuntu pylsl 1.13.6	OK

I'll test a few more scenarios

[cboulay]

(About a week ago I made a commit on what I thought was HEAD, but I was behind, and git automatically replayed all subsequent commits. This duplicated many commits, but kept authorship and the sequence. If anyone knows how to fix this without breaking everything then please do so, but I'm afraid to take the risk.)

I did git bisect and I can confirm that it's that same commit that's problematic, now found here: 12ef2be
I guess the fix (now 8dd6bf8) didn't solve all cases.

I can try to debug tomorrow.

[cboulay]

Here is the bug for string-type streams:
ffe3b09#r41008052