search

sccn / lsl_archived

Multi-modal time-synched data transmission over local network
242 stars 134 forks source link

sometimes no clock offsets get recorded #338

Closed dmedine closed 5 years ago

dmedine commented 5 years ago

This issue has been coming up more and more lately. I have had it happen to me at random (about 15% chance) when recording data on a local host. Also see (https://github.com/sccn/labstreaminglayer/issues/337). Other users have reported this to me as well.

I think this is either a problem with liblsl or LabRecorder, but I believe it has been a very long time since the part of liblsl that does this operation has ever changed.

I made a few changes to LabRecorder a few years ago so that I could test the online synchronization methods, so it could be related to that.

mgrivich commented 5 years ago

I suspect (without thorough investigation) that this happens if and only if there is a stream that connected but has no data, either because none was sent or the connection reset. Without being able to reproduce it, it would be difficult for me be sure or to fix. If someone would like to loan me hardware (with an open source LSL wrapper) that exhibits the issue, I should be able to fix it.

tstenner commented 5 years ago

Related to #331?

tstenner commented 5 years ago

I suspect (without thorough investigation) that this happens if and only if there is a stream that connected but has no data, either because none was sent or the connection reset.

I tried that (https://github.com/labstreaminglayer/App-Examples/commit/e8102806634b495558144a8f132765c40f040202), but I can't reproduce it (even before any data is sent).

dmedine commented 5 years ago

Yes, this is related to https://github.com/sccn/labstreaminglayer/issues/331

I will try to reproduce this and report back.

gisogrimm commented 5 years ago

Here are hex dumps of time synchronization packages, one at the beginning of a recording session and one at the end, sent by mbt smarting streamer version 2.2.3 (time synchronization works) and with version 3.0 (time synchronization returns immediately with a timeout error). Maybe it can help identifying the problem:

with mbt smarting 2.2.3

0000 f4 8e 38 76 e4 ec f4 8e 38 76 e5 82 08 00 45 00 ..8v....8v....E. 0010 00 45 64 4d 40 00 40 11 54 74 c0 a8 00 32 c0 a8 .EdM@.@.Tt...2.. 0020 00 64 86 07 40 bd 00 31 82 29 4c 53 4c 3a 74 69 .d..@..1.)LSL:ti 0030 6d 65 64 61 74 61 0d 0a 2d 37 39 35 37 35 35 36 medata..-7957556 0040 38 34 20 34 30 33 36 2e 32 32 30 34 30 39 31 35 84 4036.22040915 0050 38 0d 0a 8..

0000 f4 8e 38 76 e4 ec f4 8e 38 76 e5 82 08 00 45 00 ..8v....8v....E. 0010 00 44 75 1c 40 00 40 11 43 a6 c0 a8 00 32 c0 a8 .Du.@.@.C....2.. 0020 00 64 86 07 40 bd 00 30 82 28 4c 53 4c 3a 74 69 .d..@..0.(LSL:ti 0030 6d 65 64 61 74 61 0d 0a 36 37 36 39 34 33 30 30 medata..67694300 0040 39 20 34 30 37 36 2e 34 38 30 33 39 38 33 34 31 9 4076.480398341 0050 0d 0a ..

with mbt smarting 3.0

0000 f4 8e 38 76 e4 ec f4 8e 38 76 e5 82 08 00 45 00 ..8v....8v....E. 0010 00 45 3c 12 40 00 40 11 7c af c0 a8 00 32 c0 a8 .E<.@.@.|....2.. 0020 00 64 b4 39 40 bc 00 31 82 29 4c 53 4c 3a 74 69 .d.9@..1.)LSL:ti 0030 6d 65 64 61 74 61 0d 0a 2d 37 39 35 37 35 35 36 medata..-7957556 0040 38 34 20 34 38 36 36 2e 38 37 34 34 31 30 30 30 84 4866.87441000 0050 38 0d 0a 8..

0000 f4 8e 38 76 e4 ec f4 8e 38 76 e5 82 08 00 45 00 ..8v....8v....E. 0010 00 44 42 36 40 00 40 11 76 8c c0 a8 00 32 c0 a8 .DB6@.@.v....2.. 0020 00 64 b4 39 40 bc 00 30 82 28 4c 53 4c 3a 74 69 .d.9@..0.(LSL:ti 0030 6d 65 64 61 74 61 0d 0a 39 34 39 33 33 33 39 38 medata..94933398 0040 35 20 34 38 38 31 2e 31 39 37 32 31 36 33 31 34 5 4881.197216314 0050 0d 0a

gisogrimm commented 5 years ago

In both cases the stream is available without problems.

tstenner commented 5 years ago

https://github.com/labstreaminglayer/App-LabRecorder/commit/19202145c6ea0462932210a72f47208eb53a1d6b displays an error message when a timeout occurs, in the long run we should replace it with a better logging mechanism (e.g. an additional comment field in the XDF file?).

The packets look fine to me, but since the time exchange mechanism uses UDP it can't detect dropped packets.

tstenner commented 5 years ago

I suspect (without thorough investigation) that this happens if and only if there is a stream that connected but has no data, either because none was sent or the connection reset.

I tried that (labstreaminglayer/App-Examples@e810280), but I can't reproduce it (even before any data is sent).

Another update: even with the outlet open without any sent data on a different computer the time correction gets queried successfully.

mgrivich commented 5 years ago

Okay. I think I'd need the hardware (with an open source LSL wrapper) that exhibits the issue to be able to fix it. I may have time to look at it in Germany, but I don't want to make promises. Otherwise, someone would have to mail me the device.

cboulay commented 5 years ago

I had missed the mailing list thread about this that precipitated this issue. It turns out they are using gUSBamps. I have a couple of those.

I've been using the g.NEEDaccess LSL app to record from them. However, g.NEEDaccess isn't for everyone. I'm in the middle of updating the gUSBamp LSL app. I'll let you know how that goes.

cboulay commented 5 years ago

@gisogrimm I've compiled a very slightly newer version of gUSBampLSL app. You can find it here. I've only made a couple small changes, the most relevant to you is that it is built with Qt5, a recent version of boost, and the latest liblsl. Please let me know if this fixes your problem.

tstenner commented 5 years ago

Moved to https://github.com/labstreaminglayer/liblsl/issues/8