Inlet does not return info if it was queried once before the stream was open on Ubuntu 20.04 and 22.04

[mscheltienne]

I found this surprising behavior using the python binding, which hints to a bug in the C++ library as the methods invoked are one-line wrapper around the C++ functions.

import uuid

from pylsl import StreamInfo, StreamInlet, StreamOutlet


sinfo = StreamInfo("test", "Gaze", 2, 10.0, "string", uuid.uuid4().hex[:6])
outlet = StreamOutlet(sinfo, chunk_size=1)
inlet = StreamInlet(sinfo)
inlet.open_stream(timeout=5)
info = inlet.info(timeout=5)  # works

del inlet
inlet = StreamInlet(sinfo)
inlet.info(timeout=2)  # TimeoutError, normal
inlet.open_stream(timeout=5)
info = inlet.info(timeout=5)  # TimeoutError, failure

If you open the stream and then query for the attached StreamInfo, it works.
If you query for the attached StreamInfo an inlet that did not open the stream first, it fails with TimeoutError as it should. But if you then open the stream and query again for the attached StreamInfo, instead of working it raises a TimeoutError again.

Note that this behavior was observed on CIs running ubuntu-latest and on my debian 22.04 LTS (POP_OS) machine and on codespace running Ubuntu 20.04 LTS, using the 1.16 version of the library for the 20.04 (focal) version.

This behavior is not observed on macOS or on Windows. On those 2 OS, the last call does not timeout and returns the StreamInfo.

[cboulay]

I wouldn't have thought to use liblsl this way. I either construct an info for creating an outlet, or I get an info from a resolver for creating an inlet. I wouldn't have thought to use a manual stream_info to create an inlet. After all, how do you know a stream exists and you can connect to it if not for finding the streaminfo via a resolver?

But I might be wrong; we seem to have a unit test implying this is a valid workflow:
https://github.com/sccn/liblsl/blob/master/testing/ext/discovery.cpp#L23-L26

However, if I augment that unit test trying to do anything with the inlet (.info(5.0) or .open_stream(5.0)) then the test hangs (Ubuntu 22.04). So I think the inlet created in this way is not valid.

I honestly don't know why the inlet.open_stream(timeout=5) line works for you. Given my above results, I wouldn't expect it to.

@tstenner , should someone be able to create a valid inlet from a hand-made stream_info? How about from an outlet.info()?

[cboulay]

The stream_inlet constructor docstring implies that this should work though it is discouraged.

	 * @param info A resolved stream info object (as coming from one of the resolver functions).
	 * Note: The stream_inlet may also be constructed with a fully-specified stream_info, if the
	 * desired channel format and count is already known up-front, but this is strongly discouraged
	 * and should only ever be done if there is no time to resolve the stream up-front (e.g., due
	 * to limitations in the client program).

[tstenner]

I would say it should be possible, even though it might not always be the best idea. @chkothe disagreed on that one a few years ago (#35).