-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ContinuousResolver Issue #30
Comments
Link to sccn/liblsl#29 |
Hello, I think this is due to the timeout, too low for an actual network, plus once the resolve fails there is no new attempts. We had similar issue and fixed that in our branch of LSL4Unity, located at https://github.com/jelenaLis/LSL4Unity -- this commit in particular: jelenaLis@4576012 Sorry for the huge diff, there was some diff in code formatting in top of the fix. If the workaround works for both of you I can try to make a proper pull request if you want to integrate that here, or you can just cherry-pick (actually, there might be some other hack of interest in the branch). Note that the hack need some refinements, e.g. if the connexion breaks. |
Note: posted too quickly, actually I did not investigate your own workaround it might be better than to keep calling the ContinuousResolver after launch, what we did ^^ |
Just a quick idea: does the oneshot resolver (with the normal continuous resolver object) work? |
In Ubuntu 18.04, I detected the next problem: I created 2 different StreamOutlet(...) but resolve_streams() [without inputs] always returned a single stream. I tried the next: stream1 = resolve_stream( 'name', 'test1' ) and stream2 = resolve_stream( 'name', 'test2' ) but the issue remained. I tried LabRecorded, but only a single stream is showed. |
@manmermon thanks for the report. Is this all one computer or over a network? Can you try providing a unique id to each outlet during creation? |
@cboulay only one computer (locahost). I used 2 different unique id. from pylsl import StreamInfo, StreamOutlet info1 = StreamInfo('test1', 'value', 1, 0, 'float32', 'myuid2424' ) outlet1 = StreamOutlet( info1, 32, 360 ) |
And did you push some samples to each stream before trying to resolve them? |
Yes, did. This is the sender:
And this is my receiver:
The output is "length=1" |
I've uploaded a test build of the multicast branch, could you try if this fixes it? |
I tried the test build and it is not working. The next message is obtained after calling resolve_streams() : Loguru caught a signal: SIGSEGV |
That shouldn't happen at all. |
This is the result:
|
The good news is that the error is reproducible, the bad news is that the network configuration looks ok. I'll add some more debug messages to see what's (not) happening behind the scenes and upload another build some time next week. |
I've updated the debug build, could you download it again, run |
This the result:
|
In the Slack Channel, we had opened a discussion regarding an issue of not being able to receive streams through the network in Unity:
With Chad's help, we were able to resolve this issue by bypassing the ContinuousResolver found in AInlet.cs and using liblsl.resolve_streams() instead. Below is the edited AStringInlet class that allowed my program to work over a network connection:
The text was updated successfully, but these errors were encountered: