Builds with BOOST_TYPE_CONVERSIONS=ON` fail on macOS about app-labrecorder HOT 11 CLOSED

I reproduced the issue and fixed it. As far as I can see the commit hasn't been included in any officially released binaries so all you'd need to do is to pull the latest commit for liblsl.

from app-labrecorder.

Hi thanks for the report.
Resources (i.e. my time) to work on these kinds of errors are pretty limited these days. Someone will try to get to it as soon as possible.

Is there a reason the prebuilt binaries aren't working for you?
https://github.com/labstreaminglayer/App-LabRecorder/releases/tag/1.13.0-b4

from app-labrecorder.

from app-labrecorder.

That's the code path for non-standard cpu architectures (e.g. some big endian machines, but definitely nothing macOS or iOS run on).
In theory, CMake should detect that this isn't needed for you, but there are some circumstances where this could fail. If you could remove your build directory and paste the CMake log (cmake -S /path/to/LabRecorder -B /path/to/LabRecorder/build) I could take a look at it. You could also disable the check with cmake -DLABRECORDER_BOOST_TYPE_CONVERSIONS=OFF -DLABRECORDER_SKIP_CPUTESTS=ON /path/to/the/builddir.

But, as both cboulay and dmedine said the prebuilt binaries are your best bet.

from app-labrecorder.

Thanks a lot for responding. The binaries work perfectly. I'll check if it can receive streams and record data correctly.

I was trying to build labstreaminglayer source which is having labrecorder app source. I am writing some custom lsl data streamers. To my understanding, unless all the apps are built with the same pre-compiled lsl libraries, they may fail in obtaining the correct data stream.

Errors like these appear only if I enable BOOST TYPE CONVERSIONS or XDFZ flags. I am using Apple clang version 11.0.3 (clang-1103.0.32.62), Target: x86_64-apple-darwin19.2.0 and boost 1.65.1.

Could you please share the compiler and boost library details used for compiling mac version of the recorder app (1.13.0-b4)?

from app-labrecorder.

To my understanding, unless all the apps are built with the same pre-compiled lsl libraries, they may fail in obtaining the correct data stream.

Absolutely not, we have some vendor supplied programs that are still stuck on a liblsl version from half a decade ago and if there are any interoperability problems they will need to be fixed.

Errors like these appear only if I enable BOOST TYPE CONVERSIONS

The builds shouldn't fail, but BOOST_TYPE_CONVERSIONS is only meant for running LabRecorder on exotic platforms (and is therefore mostly untested).

Could you please share the compiler and boost library details used for compiling mac version of the recorder app (1.13.0-b4)?

The entire build log is here: https://travis-ci.org/github/labstreaminglayer/App-LabRecorder/builds/584154595 (Apple LLVM version 10.0.0, clang-1000.11.45.5 without Boost)

from app-labrecorder.

To my understanding, unless all the apps are built with the same pre-compiled lsl libraries, they may fail in obtaining the correct data stream.

Whoever told you this is wrong.

from app-labrecorder.

In my case for windows (64bit), any app compiled with newer lsl.dll/lib and labrecorder running on liblsl64.dll throw error such as follows when I hit the start button.

"ERR| Stream transmission broke off (The received test-pattern samples do not match the specification. The protocol formats are likely incompatible.); re-connecting... "

If I keep same dlls in both the apps, I do not get this error.

from app-labrecorder.

Hmmm, this is troubling news indeed. Thanks for pointing it out!

I just ran a quick sanity check by firing up the ancient Mouse app from the SCCN ftp (which uses liblsl version 1.10, LSL protocol version 100) and recorded with the latest version of LabRecorder (liblsl version 1.13, protocol version 110) on the latest version of Windows 10 and had no issues.

This error message can be generated during the moment when an inlet connects to an outlet (https://github.com/sccn/liblsl/blob/8e257f74b98876a7b1bca7a3be25eefd146f94ab/src/data_receiver.cpp#L276-L293). There is a test pattern generated and there are if/else statements that should properly handle the cases where the LSL protocols are mismatched between sender and receiver. I have never been able to trigger this error, but I typically only use Windows and Linux and often only on very up-to-date software systems.

@niteshbhatia008, if you can, please start a new issue in the sccn/liblsl repository (https://github.com/sccn/liblsl/tree/8e257f74b98876a7b1bca7a3be25eefd146f94ab) with details for how to reproduce this error.

from app-labrecorder.

There's already an issue for that (sccn/liblsl#76). I couldn't reproduce the issue locally yesterday, but it seems to have cropped up very recently.

from app-labrecorder.

@niteshbhatia008 The pattern mismatch was fixed in liblsl recently. The BOOST_TYPE_CONVERSIONS=ON is not something we're going to be testing in the near future. If you are still having trouble using liblsl then please open an issue there. If you are still having trouble with LabRecorder then please reopen this issue or open a new one if it's on a different topic. Thank you.

from app-labrecorder.