"Error trying to send a time packet: Invalid argument" when accessing a new stream about labstreaminglayer HOT 8 CLOSED

I've been trying to reproduce this, but after killing and automatically restarting SendStringMarkers for half an hour I didn't encounter the error even once (both debug and release builds).

If I had to guess, there's something weird about the locking in the recovery process. Maybe tstenner/liblsl@c0ea534 fixes the problem.

from labstreaminglayer.

Your commit seems to have fixed the time_receiver.cpp bug. At least it suppressed the warning message. However, note there is also the same kind of error at data_receiver.cpp:342, which is thrown by conn_.get_tcp_endpoint() at line 154. conn_.address() is empty again. Could you apply the same treatment to that file?

Thanks.

from labstreaminglayer.

The data receiver is notified of the new connection differently, so I'll have to see how what kind of locking is / isn't needed there. I can do it, but I'm kind of swamped at the moment and it might be a week or two until I get around to it.

from labstreaminglayer.

Could I get a status update on this? This is preventing me from updating our apps to latest.

from labstreaminglayer.

I tried to reproduce it on a few free evenings, but haven't been able to reproduce it so far. It doesn't really help much that the only Windows PC I can install things on is the one I use for my taxes...

from labstreaminglayer.

I was able to fix the remaining issue. Your changes, above, are still required. What was happening is that sometimes the source stream would re-appear as ipv6 instead of ipv4. The code below checks for and fixes the issue. I'd like this to be merged in the main branch. Let me know how you'd like me to go about that, or if you'd like to handle it. In inlet_connection.cpp, starting from line 204:

if (infos.size() == 1) {

	if(infos[0].v4address().empty() && infos[0].v6address().empty()) {
		continue;
	}

	// update the endpoint
	host_info_ = infos[0];
	
	// Source may have jumped ipv4 -> ipv6 or vice versa.
	// re-select TCP/UDP protocol versions
	if (api_config::get_instance()->allow_ipv6()) {
		// if IPv6 is optionally allowed...
		if (host_info_.v4address().empty() || !host_info_.v4data_port() ||
			!host_info_.v4service_port()) {
			// then use it but only iff there are problems with the IPv4 connection data
			tcp_protocol_ = tcp::v6();
			udp_protocol_ = udp::v6();
		} else {
			// (otherwise stick to IPv4)
			tcp_protocol_ = tcp::v4();
			udp_protocol_ = udp::v4();
		}
	} else {
		// otherwise use the protocol type that is selected in the config
		tcp_protocol_ = api_config::get_instance()->allow_ipv4() ? tcp::v4() : tcp::v6();
		udp_protocol_ = api_config::get_instance()->allow_ipv4() ? udp::v4() : udp::v6();
	}												
	
	// cancel all cancellable operations registered with this connection
	cancel_all_registered();
	.
	.
	.
}

from labstreaminglayer.

Ah, good to know the issue wasn't a mutex problem I missed after looking for it a few times.

I added a small helper method so the protocol selection can be used in both the constructor and the recovery path (sccn/liblsl#195).

from labstreaminglayer.

Thanks. Looks good now.

from labstreaminglayer.