Labstreaminglayer not working on OpenSuse Linux
basophobic opened this issue · comments
Greetings,
for the past couple of days I'm trying to make labstreaminglayer to work with an OpenBCI EEG board on my OpenSuse Linux machine, but with no luck. I have used the OpenBCI-Python code from their git repo, and the liblsl-Python and liblsl-Matlab from here. The same configuration was also used on two other PCs that I have running Windows 10 and Ubuntu 16.04 LTS and no problems have occurred - everything worked out-of-the-box. But when I try the same installation steps on my Tumbleweed opensuse laptop, data can't be streamed.
In particular, the OpenBCI-Python is installed correctly with all requirements and my board is detected, but when invoking the /start streaming command, although there are no obvious errors, no data is streamed through the network, as neither of my other two PCs that is in listening mode (Windows, Ubuntu) receives anything. On the contrary, when any of these two PCs streams, the other can see the EEG data and plot it in Matlab (using the vis_stream program, or the ReceiveData.m program), or using Python with the RecieveData.py program. Both working PCs have Anaconda 4.5.4, Python 3.7.0 and pylsl 1.10.4 (installed using pip).
In the last couple of days I have tested various builds and configurations on my OpenSuse PC such as the exact same config as the Ubuntu PC, different anaconda environments with python 3.4 and python 2.7, using all different versions of pylsl (1.10.3, 1.10.4, 1.10.5, 1.12.0), even compiled the liblslXX.so library and the pylsl from source using instructions here either using the include boost libraries, or my system's boost libraries, but I still get nothing.
It's really frustrating, and I'm out of any ideas....Can anyone give a hint on this?
Sorry I don’t use OpenSUSE so I have no idea what could be different. Do you have an IDE and can you debug one of the C++ benchmark apps?
How is the OpenSUSE PC connected to the network? I suspect a firewall issue, but we've also had some problems with PCs with two network interfaces. In case that's the problem, you could set the IPs in the config so the correct interface is selected.
@tstenner No, I have specifically disabled the firewall (suspected this could cause some issues as in other posts was suggested), the laptop is connected to the network via WiFi. but the problem is that this is not working even when I send and (try to) receive data on the same PC.
However the output of lsl_loadlib() in Matlab is the following (I don't know what to make out of it):
lsl_loadlib
ans =
struct with fields:
hlib: 140432864318400
lsl_protocol_version: 140430821315984
lsl_library_version: 140430821316016
lsl_local_clock: 140430821316032
lsl_resolve_all: 140430821316096
lsl_resolve_byprop: 140430821316768
lsl_resolve_bypred: 140430821317488
lsl_create_streaminfo: 140430821369200
lsl_destroy_streaminfo: 140430821370608
lsl_get_name: 140430821369808
lsl_get_type: 140430821369824
lsl_get_channel_count: 140430821369840
lsl_get_nominal_srate: 140430821369856
lsl_get_channel_format: 140430821369872
lsl_get_source_id: 140430821369888
lsl_get_version: 140430821369904
lsl_get_created_at: 140430821369920
lsl_get_uid: 140430821369936
lsl_get_session_id: 140430821369952
lsl_get_hostname: 140430821369968
lsl_get_desc: 140430821369984
lsl_get_xml: 140430821370016
lsl_create_outlet: 140430821329024
lsl_destroy_outlet: 140430821329264
lsl_push_sample_f: 140430821335376
lsl_push_sample_ft: 140430821335824
lsl_push_sample_ftp: 140430821336288
lsl_push_sample_d: 140430821338160
lsl_push_sample_dt: 140430821338608
lsl_push_sample_dtp: 140430821339072
lsl_push_sample_l: 140430821353472
lsl_push_sample_lt: 140430821353920
lsl_push_sample_ltp: 140430821354384
lsl_push_sample_i: 140430821340944
lsl_push_sample_it: 140430821341392
lsl_push_sample_itp: 140430821341856
lsl_push_sample_s: 140430821356256
lsl_push_sample_st: 140430821356704
lsl_push_sample_stp: 140430821357168
lsl_push_sample_c: 140430821332592
lsl_push_sample_ct: 140430821333040
lsl_push_sample_ctp: 140430821333504
lsl_push_sample_str: 140430821349712
lsl_push_sample_strt: 140430821350288
lsl_push_sample_strtp: 140430821350880
lsl_push_sample_buf: 140430821351472
lsl_push_sample_buft: 140430821352064
lsl_push_sample_buftp: 140430821342912
lsl_push_sample_v: 140430821329392
lsl_push_sample_vt: 140430821330032
lsl_push_sample_vtp: 140430821330704
lsl_have_consumers: 140430821331392
lsl_wait_for_consumers: 140430821331504
lsl_get_info: 140430821331616
lsl_create_inlet: 140430821327536
lsl_destroy_inlet: 140430821328032
lsl_get_fullinfo: 140430821318144
lsl_open_stream: 140430821318336
lsl_close_stream: 140430821318464
lsl_time_correction: 140430821318576
lsl_pull_sample_f: 140430821325648
lsl_pull_sample_d: 140430821326592
lsl_pull_sample_l: []
lsl_pull_sample_i: 140430821320880
lsl_pull_sample_s: 140430821321824
lsl_pull_sample_c: 140430821318976
lsl_pull_sample_str: 140430821324928
lsl_pull_sample_buf: 140430821324144
lsl_pull_sample_v: 140430821318704
lsl_samples_available: 140430821318848
lsl_first_child: 140430821371216
lsl_last_child: 140430821371264
lsl_next_sibling: 140430821371312
lsl_previous_sibling: 140430821371360
lsl_parent: 140430821371408
lsl_child: 140430821371456
lsl_next_sibling_n: 140430821371520
lsl_previous_sibling_n: 140430821371584
lsl_empty: 140430821371648
lsl_is_text: 140430821371696
lsl_name: 140430821371744
lsl_value: 140430821371776
lsl_child_value: 140430821371808
lsl_child_value_n: 140430821371840
lsl_append_child_value: 140430821372480
lsl_prepend_child_value: 140430821372576
lsl_set_child_value: 140430821372384
lsl_set_name: 140430821371888
lsl_set_value: 140430821371936
lsl_append_child: 140430821371984
lsl_prepend_child: 140430821372048
lsl_append_copy: 140430821372112
lsl_prepend_copy: 140430821372192
lsl_remove_child_n: 140430821372272
lsl_remove_child: 140430821372320
on_cleanup: [1×1 onCleanup]
@cboulay I have build the liblsl as mentioned in this file with no errors using cmake. The only debug I have performed (not much of help) is in MATLAB when running the ReceiveData.m script. The program executes the lsl_loadlib and then it gets trapped in the following loop
while isempty(result)
result = lsl_resolve_byprop(lib,'type','EEG'); end
as the result is always empty.
Based on your description so far, I suspect the library is failing to create the outlet, or at least to make it visible, so you won't be able to debug that with any of the library wrappers.
The only C++ IDE I've ever used in Linux is Code::Blocks. You can use the CMakeLists.xt file to create a Code::Blocks project. Once the project is setup, you can build a debug version of liblsl. Then you can build a debug version of (e.g.) the CppSendRand app which links to the debug dll.
First try to 'debug' the app (i.e., run the debug version using the debug tools in the IDE) and see if you get any useful messages. If you don't get anything useful there, try putting a break point in the app code before the outlet is made, then run in debug mode again and it should pause execution at your break point. From there step through the code until it hangs (if it hangs).
If you've never debugged a C++ application before then it may sound like a lot, but given what you've described so far I can guess that this is certainly within your ability and I think you'll find it to be a very powerful tool for many applications.
Oh, one more thing. Don't link LSL to "system boost" and maybe even change the LSL_LSLBOOST_PATH value to lslboost (-DLSL_LSLBOOST_PATH="lslboost").
While we certainly want to be able to use system boost at some point, right now this isn't a supported option.
Maybe OpenSuse does something similar?
You can find this out quickly with ip addr / ip link.
@dmedine There is no problem pinging from opensuse to other network machines and vice-versa. In addition, maybe I wasn't clear in the first post, but I'm currently not able to stream data from opensuse and receive them from the same machine. Switching to Ubuntu is a consideration, but for now, this is rather difficult due to the fact that the opensuse is already installed and configured for various other projects that can't be postoponed unfortunatelly.
@cboulay Used KDevelop and compiled liblsl in debug mode successfully. Now, if only I could pass the error it keeps giving me when trying to compile CppSendRand.cpp in the Examples folder concerning the LSL_INSTALL_ROOT directory:
Precompiled LSL was not foung. Set LSL_INSTALL_ROOT to the LSL installation path
I tried using the path where my ldlsl64-debug.so is, but with no luck until now...
Did you do it all as one project with -DLSLAPPS_Examples=ON (what we call an 'in tree' build) or are you trying to do this in an independent project (what we call an out of tree build)? I'm pretty sure the former works with Debug because I think I've done it before. The latter might not work with Debug though we would like it to.
I tried using the path where my ldlsl64-debug.so is, but with no luck until now...
The CMake build looks for the CMake configuration files in LSL_INSTALL_ROOT/share/LSL.
The easiest way to debug it would be an in-tree-build as suggested by Chadwick:
- clone the repository
- in the repository:
mkdir build; cd build - create the project files:
cmake -DCMAKE_BUILD_TYPE=Debug -DLSL_LSLBOOST_PATH=lslboost -DLSLAPPS_Examples=1 .. cmake --build . --target install
You will now have the examples and lsl library in the install subfolder. I haven't used kdevelop in some time, but cmake might have a project file generator (check cmake -h) for it or it might be able to open the CMakeLists.txt by itself
@cboulay You're right! I was trying to debug independent project. Now I have performed an in tree build and is working OK. First results after runnning in debug mode the CppSendRand program: It gets stuck in the while expresion:
Line 19: while(!outlet.wait_for_consumers(120));
Lowering the argument in the wait_for_consumers to 1 (don't know what this is for), keeps the code in the same while line, not progressing inside the loop.
Program variables:
info has an obj 0x1b7e7a0
outlet has channel_count = 8 and the obj
No arguments are given when I run the program. I believe the default in case of no arguments is the Simple Stream EEG and nchannels.
Immediately after that starts running, try to run a separate instance of something that creates an inlet and receives data (i.e., a consumer). You don't have to use a debugged CPP application for this, you can use Matlab or Python receive data examples.
Latest update:
- I have successfully compiled
lsland basic apps for sending / receiving streams (debug and release). - When running the
CppSendRandit creates aSimpleStreamEEG that I can receive (at last) from the same machine using Python wrappers that use the freshly compiled version of thelsllibrary. - When using my OpenBCI to create an OpenBCI_EEG stream and send it, the
CppReceivecan't resolve any stream. - When using the
CppSendRandto make a test stream, theCppReceivecan't resolve the stream. - The SimpleStream from (2) is not visible in other PCs on the network (Ubuntu, Linux that are configured properly and talk to each other)
- When using
MATLABwith the freshly compiledliblsl64.so(release version), the program now complains about the library and errors with this:
Could not load library '/extdisk2/_openbci/liblsl-Matlab/bin/liblsl64.so'...
Error code: /extdisk/MATLAB/R2017a/bin/glnxa64/../../sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /extdisk2/_openbci/liblsl-Matlab/bin/liblsl64.so)
Error using lsl_loadlib_
Exiting now.
- When using my OpenBCI to create an OpenBCI_EEG stream and send it, the Python wrappers that use the freshly compiled version of the
lsllibrary cannot find the stream.
It's getting weirder and weirder....
and this is the loop where the CppReceive is stuck:
Line 148, File: task_io_service.ipp
std::size_t n = 0;
for (; do_run_one(lock, this_thread, ec); lock.lock())
if (n != (std::numeric_limits<std::size_t>::max)())
++n;
When using my OpenBCI to create an OpenBCI_EEG stream and send it, the CppReceive can't resolve any stream.
OpenBCI is using pylsl. Does it ship its own pylsl / liblsl?
When using the
CppSendRandto make a test stream, theCppReceivecan't resolve the stream.
I've pushed some more example apps, does the GetAllStreams example show anything?
The SimpleStream from (2) is not visible in other PCs on the network (Ubuntu, Linux that are configured properly and talk to each other)
Are they connected by wire or wireless? What does ip addr report?
When using MATLAB with the freshly compiled liblsl64.so (release version), the program now complains about the library and errors with this:
Yes, Matlab ships its own libraries and some of them can be quite outdated or cause other problems. We've already included our own boost libraries because of this, but anything more can be problematic.
The Debian Matlab package deletes the included libgcc / libstdc++ in Matlab, maybe renaming it will help.
OpenBCI is using pylsl. Does it ship its own pylsl / liblsl?
@tstenner Tristan the OpenBCI uses pylsl but it doesn't come with its own version of pylsl / liblsl. I have used the compiled version from this repo as well as all previous compiled version from the sccn FTP site as well (with no luck).
I've pushed some more example apps, does the
GetAllStreamsexample show anything?
I'll try that later in the day and post results.
Are they connected by wire or wireless? What does ip addr report?
I have set up a local network using a home router. The two PCs that are working (Windows and Ubuntu) are wired connected to the router, the laptop (Opensuse) is tested with wireless as well as wire connection with no success.
koutras@koutras-xps:~> ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 9c:b6:d0:ee:e0:ef brd ff:ff:ff:ff:ff:ff
inet 192.168.1.66/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp58s0
valid_lft 85909sec preferred_lft 85909sec
inet6 2a02:2149:8471:e200:61a8:b17d:dd48:1460/64 scope global temporary dynamic
valid_lft 86383sec preferred_lft 85876sec
inet6 2a02:2149:8471:e200:7b39:a497:bfc7:e900/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86383sec preferred_lft 86383sec
inet6 fe80::c50c:9c16:7293:f547/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Could that be a problem caused by inet6 IPV6 protocol? Will disable that as well and test again.
Yes, Matlab ships its own libraries and some of them can be quite outdated or cause other problems. We've already included our own boost libraries because of this, but anything more can be problematic.
The Debian Matlab package deletes the included libgcc / libstdc++ in Matlab, maybe renaming it will help.
The strange thing is that when I use a precompiled version ofliblsl64.sofrom the sccn FTP site (regardless version), the MATLAB functions work correctly (lsl_loadlib(), ReceiveData(), ...) when data are streamed from the opensuse laptop with the CppSendRand. So I guess it must be a matter of arguments I use when I build my own version of the liblsl library. I have tried both with the lslboost as well as the external option as mentioned by @cboulay Chadwick, but both versions crash MATLAB.
Just run GetAllStreams with output:
koutras@koutras-xps:/extdisk2/_openbci/labstreaminglayer_new/labstreaminglayer/build/Apps/Examples>
./GetAllStreams
Here is a one-shot resolve of all current streams:
<?xml version="1.0"?>
<info>
<name>OpenBCI_AUX</name>
<type>AUX</type>
<channel_count>3</channel_count>
<nominal_srate>250</nominal_srate>
<channel_format>float32</channel_format>
<source_id>openbci_aux_id1</source_id>
<version>1.1000000000000001</version>
<created_at>2546.0799156180001</created_at>
<uid>ab7ce48c-f79f-4e94-8076-5918b00e03a7</uid>
<session_id>default</session_id>
<hostname>koutras-xps.localdomain</hostname>
<v4address />
<v4data_port>16574</v4data_port>
<v4service_port>16574</v4service_port>
<v6address />
<v6data_port>16575</v6data_port>
<v6service_port>16575</v6service_port>
<desc />
</info>
Press any key to switch to the continuous resolver test:
OpenBCI_AUX
OpenBCI_AUX
OpenBCI_AUX
OpenBCI_AUX
OpenBCI_AUX
OpenBCI_AUX
OpenBCI_AUX
OpenBCI_AUX
OpenBCI_AUX
OpenBCI_AUX
OpenBCI_AUX
OpenBCI_AUX
...
Seems like the only stream that is being transmitted to the network is OpenBCI_AUX and not the second one OpenBCI_EEG from OpenBCI.
When I initialize the OpenBCI I get:
(openbcienv) koutras@koutras-xps:/extdisk2/_openbci/OpenBCI_Python-master> python user.py -p /dev/ttyUSB0 --plugins-path /extdisk2/_openbci/OpenBCI_Python-master --add streamer_lsl --add print
------------user.py-------------
Board type: OpenBCI Cyton (v3 API)
('Port: ', '/dev/ttyUSB0')
------------SETTINGS-------------
Notch filtering:True
user.py: Logging Disabled.
-------INSTANTIATING BOARD-------
Connecting to V3 at port /dev/ttyUSB0
Serial established...
OpenBCI V3 8-16 channel
On Board ADS1299 Device ID: 0x3E
LIS3DH Device ID: 0x33
Firmware: v2.0.1
$$$
No daisy:
(8, 'EEG channels and', 3, 'AUX channels at', 250.0, 'Hz.')
------------PLUGINS--------------
Found plugins:
[ streamer_tcp ]
[ streamer_lsl ]
[ streamer_osc ]
[ csv_collect ]
[ udp_server ]
[ noise_test ]
[ print ]
[ sample_rate ]
Activating [ streamer_lsl ] plugin...
Creating LSL stream for EEG. Name:OpenBCI_EEG- ID:openbci_eeg_id1- data type: float32.8channels at250.0Hz.
Creating LSL stream for AUX. Name:OpenBCI_AUX- ID:openbci_aux_id1- data type: float32.3channels at250.0Hz.
Plugin [ streamer_lsl] added to the list
Activating [ print ] plugin...
Print activated
Plugin [ print] added to the list
--------------INFO---------------
User serial interface enabled...
View command map at http://docs.openbci.com.
Type /start to run (/startimp for impedance
checking, if supported) -- and /stop
before issuing new commands afterwards.
Type /exit to exit.
Board outputs are automatically printed as:
% <tab> message
$$$ signals end of message
-------------BEGIN---------------
-->
and then I /start transmitting.
The following is the result of GetAllStreams when only the SimpleStream from CppSendRand is transmitted (identified correctly)
koutras@koutras-xps:/extdisk2/_openbci/labstreaminglayer_new/labstreaminglayer/build/Apps/Examples> ./GetAllStreams
Here is a one-shot resolve of all current streams:
<?xml version="1.0"?>
<info>
<name>SimpleStream</name>
<type>EEG</type>
<channel_count>8</channel_count>
<nominal_srate>0</nominal_srate>
<channel_format>float32</channel_format>
<source_id />
<version>1.1000000000000001</version>
<created_at>3013.7655890639999</created_at>
<uid>ff2667ef-de2b-43fa-bf12-e145b0ee2b05</uid>
<session_id>default</session_id>
<hostname>koutras-xps.localdomain</hostname>
<v4address />
<v4data_port>16572</v4data_port>
<v4service_port>16572</v4service_port>
<v6address />
<v6data_port>16573</v6data_port>
<v6service_port>16573</v6service_port>
<desc />
</info>
Press any key to switch to the continuous resolver test:
And here is the output of the GetAllStreams when a SimpleStream from CppSendRand and OpenBCI are sending at the same time (same opensuse machine):
koutras@koutras-xps:/extdisk2/_openbci/labstreaminglayer_new/labstreaminglayer/build/Apps/Examples> ./GetAllStreams
Here is a one-shot resolve of all current streams:
<?xml version="1.0"?>
<info>
<name>SimpleStream</name>
<type>EEG</type>
<channel_count>8</channel_count>
<nominal_srate>0</nominal_srate>
<channel_format>float32</channel_format>
<source_id />
<version>1.1000000000000001</version>
<created_at>3175.006512336</created_at>
<uid>e51741d6-0dad-45c1-8815-8d6fec91f33f</uid>
<session_id>default</session_id>
<hostname>koutras-xps.localdomain</hostname>
<v4address />
<v4data_port>16576</v4data_port>
<v4service_port>16576</v4service_port>
<v6address />
<v6data_port>16577</v6data_port>
<v6service_port>16577</v6service_port>
<desc />
</info>
It detects only the SimpleStream.
Note that all runs described here are on the same opensuse laptop (no network connection with other PCs)
[jumping in the conversation since I'm following it, for using a lot LSL and for being the one putting that into OpenBCI python in the first place]
The script assumes that pylsl is installed on the system, e.g. through pip; version 1.10.4 is set in the requirements.txt at the moment.
@jfrey-xx of course you are right. In my case I tried all different versions of pylsl to be installed by pip, I also installed the compiled liblsl64.so manually at the anaconda3/envs/openbcienv/lib/pythonXX/site-packages/pylsl directory. Let alone the fact that I have also tested all different python versions (2 and 3).
All with no luck.
In one of my tries, vis_stream only detected the AUX channel and not the EEG from the openBCI, something that I also found when I ran the GetAllStreams program. This alone could make me think that the problem is somewhere inside the OpenBCI-Python, but as I mentioned in an earlier post:
When using the CppSendRand to make a test stream, the CppReceive can't resolve the stream.
Weirder and weirder, I don't see how AUX and EEG would differ...
Everything related to LSL lies here: https://github.com/OpenBCI/OpenBCI_Python/blob/master/openbci/plugins/streamer_lsl.py
You could try to disable AUX (comment the stream creation on line 44, and comment push on line 55), see if it changes something.
You could try to disable AUX (comment the stream creation on line 44, and comment push on line 55), see if it changes something.
Just tried it and guess what.... It works! Streams of EEG data are sent from the OpenBCI and received by ReceiveData in Matlab and Python and vis_stream as well as the data of the stream are captured by the test program GetAllStreams.
BUT: The stream is not broadcasted on the network, no other machines sees it (that's a start)...
The question is: Why when there are more than 1 stream broadcasted, this doesn't work (or in most of the cases) only 1 stream is detected?
So you now have 2 separate problems:
1 - Streams visible locally are not visible by other computers on the network
2 - OpenBCI streams are often not available, even locally.
The first problem is almost definitely a network problem. When using WiFi to connect to the network, try disabling (not just unplugging) the wired ethernet adapter. My suggestions for going the debugging route were to see if the network problem might be high-level, and maybe you could see if creating the stream or pushing samples is throwing non-fatal errors.
The second problem might be my fault, depending on how you're doing things.
On July 3 2018, I updated pylsl on pypi to version 1.12.0.
Previously, (1.10.5) pylsl had been an egg with all of the .so/.dylib/.dll @ 32/64 bundled in.
There are a few differences in the new version:
- This time I made a 'universal' wheel, but only the 64-bit binaries bundled in.
- I would like to make platform-specific wheels, but Pypi doesn't let you make a linux wheel without going the 'anylinux' route, and that requires a lot of work with things I'm not too familiar with.
- The Mac and Linux shared libs are symlinks to the version-specific shared libs, also included.
- I tested the install only on Windows 10 64, MacOS High Sierra, and Ubuntu 18.04.
I wouldn't be terribly surprised if the .so I compiled in Ubuntu 18.04 doesn't work with an older version of Linux, indeed this is why pypi insists on the more onerous 'anylinux' config for building libraries to ship for linux. You can try using pylsl==1.10.5; Christian's .so will be linking against older shared libs and is therefore more likely to be compatible with older versions of Linux. However, this is still not ideal. The best way to do it would be to build and install to your system the most recent liblsl, then do a pip install . from the liblsl-Python directory. Edit: Make sure you don't have a .so file in the liblsl-Python/pylsl folder, otherwise installing pylsl will copy over those .so files and it won't use the system .so. Also, use this repo for pylsl.
To install to your system, you'll have to set the CMAKE_INSTALL_PREFIX to whatever the directory is for OpenSuse. Maybe /usr/local ?
So you now have 2 separate problems:
1 - Streams visible locally are not visible by other computers on the network
Checked by disabling ethernet / wireless. In both cases, same results, no connectivity with other Listeners.
2 - OpenBCI streams are often not available, even locally.
The problem is systematic and consistent. When more than one streams are on the network (I'm just guessing here - I don't know if they are pushed in the network maybe they don't even make it up there) ReceiveData cannot resolve any of them streams. But when I comment the creation of the AUX and the pushing of the AUX stream as proposed by @jfrey-xx , ReceiveData works well.
I did the manual compiling, installed libraries in system (/usr/local/lib64), performed pip install . in the lillsl-Python/pylsl directory from the mentioned repo as @cboulay suggested, but still getting same results.
It's just so frustrating when things work without trouble in other distros (Ubuntu), even in Windows 10 (!), but not in Opensuse and still can't figure out if it's OpenBCI's (python) problem or the liblsl problem.
Debugging is the way for answers, but due to the size of the project and my lack of experience, it will take a while to get there (and oddly enough no other user of liblsl and opensuse around?)...
Can you see multiple streams if none of them are OpenBCI? How about if none of them are Python?
[this might be obvious but I feel the necessity to point it out: instead of running tests using OpenBCI scripts, try a simpler example on the python side to avoid any side effect, e.g. https://github.com/labstreaminglayer/liblsl-Python/blob/master/pylsl/examples/SendData.py You could duplicate the streams there (changing name/ID) ]
The problem is systematic and consistent. When more than one streams are on the network (I'm just guessing here - I don't know if they are pushed in the network maybe they don't even make it up there) ReceiveData cannot resolve any of them streams. But when I comment the creation of the AUX and the pushing of the AUX stream as proposed by @jfrey-xx , ReceiveDataworks well.
I did the manual compiling, installed libraries in system (/usr/local/lib64), performed pip install . in the lillsl-Python/pylsl directory from the mentioned repo as @cboulay suggested, but still getting same results.
It's just so frustrating when things work without trouble in other distros (Ubuntu), even in Windows 10 (!), but not in Opensuse and still can't figure out if it's OpenBCI's (python) problem or the liblslproblem.
Debugging is the way for answers, but due to the size of the project and my lack of experience, it will take a while to get there (and oddly enough no other user of liblsl and opensuse around?)...
I would be surprised if LSL is not compatible with OpenSUSE. That LSL works under some conditions confirms this. I am most suspicious about the quality of your network. Try connecting your OpenSUSE computer with wired internet, disabling your wireless network, confirming that you can ping to/from your OpenSUSE computer and then repeating the OpenBCI tests. If that passes, we can talk about how to improve your wireless network (assuming it is required for your setup).
If that fails, try to use something simpler than OpenBCI to test LSL, but stay on the wired network. jfrey-xx's suggestions is fine, if you are using python, though I tend to like the C++ examples because they have even fewer dependencies. You can try loading up multiple streams in different command windows to test that.
SOLVED!
After a lot of experimentation using the compiled program SendDataC to send 4 different streams, I saw that GetAllStreams program managed to resolve only the last stream to start from the four. Furthermore when I stopped one stream at a time, I observed that for a random time interval (seconds), two streams were simultaneously detected on the network and after that only one again from the remaining streams. The same was observed using the Python versions of the SendData scripts as well.
My laptop doesn't have an ethernet card, the connection is performed using a Type-C to Ethernet adapter. Motivated from the above comments, as well as the peculiar behavior of the streams (nothing alarming though when I used the laptop to connect to the internet except some small lags), I decided to replace my adapter with a USB->ethernet and finally everything worked as they should be!
Thank you all for your valuable help and support these couple of days and keep up the good work!
Rule: Always make sure your hardware is functional first...
I'm glad you got it working.