Labrecorder builds but crashes
GitDoose opened this issue · comments
We were previously using labrecorder 1.13 from the ftp site on our Windows 7 machine but occasionally we would have .xdf files that were unable to be opened in eeglab using load_xdf - they'd come back with a "matrix must be positive-definite" error. I thought that might be the clock offsets errors referenced in an issue here and cloned and built the latest labrecorder on master here in VS 2017 per the instructions. It built successfully with lots of warnings (but no errors) but it does not work properly on the machine - we can start the exe and it appears and we can see the streams but once we hit start files remain at 0 kb, it doesn't seem to record the data properly, and also crashes whenever we hit the stop button. Firewall settings appear correct, or at least the same as labrecorder 1.13 and we've rebuilt several times (always in x86-release mode) and have the correct versions of QT and Boost, but behavior is consistent. Is it possible we've built it wrong, or are we missing something simple in setup?
Full error we were getting with 1.13:
Error using chol
Matrix must be positive definite.
Error in load_xdf>robust_fit (line 695)
L = sparse(chol(A'*A,'lower')); U = L';
Error in load_xdf (line 435)
mappings{r} = robust_fit([ones(idx(2)-idx(1)+1,1) clock_times(idx(1):idx(2))']/opts.WinsorThreshold,
clock_values(idx(1):idx(2))'/opts.WinsorThreshold);
The error you are getting with 1.13 is indeed the clock offsets error. That version should be removed from the ftp. @mgrivich or @arnodelorme can you help with that?
I'm seeing the same failure-to-close error as you. I thought this was related to #9 but @tstenner 's commits are already committed to master and the bug is still there. It's not solved.
For now there's a workaround. Tell LabRecorder to stop, then it'll hang, then close all your stream sources. Eventually LabRecorder will recognize that the streams are gone and it will finish closing the xdf files. This isn't ideal and I hope we can fix it soon.
Edit: Even when LabRecorder says 0-kb written, I am still getting full xdf files. I'm hoping that's just a GUI thing. I haven't looked into it yet.
Thank you for the very quick response, yes it does seem that I get files if I wait a while for it to close. It takes quite a while though. We're training operators for a big study that uses labrecorder pretty heavily and I'm afraid this may cause the trouble - is there a prior release, perhaps one of the 1.12 or even earlier versions you'd recommend as more stable than 1.13?
Here is the last commit before the clock offsets bug was introduced.
Shouldn't it be the case that one can simply replace liblslxx.dll with a non-bugged version and it should work correctly, regardless of the LabRecorder version?
Also, does anybody know if this bug affects only inlets or outlets as well? That is to say, is it only LabRecorder we need to worry about, or are streaming hardware clients also affected. I've never actually tried to check this myself.
I will contact Clement and ask him to remove 1.13.
Hello, thank you for all the responses and help. It seems @dmedine is correct, replacing the liblslxx.dll probably fixes the issue. We went through the historical archive related to the clock offsets bug, which seems to resolve itself here after a couple jumps: sccn/liblsl#8
There is a link at the bottom that goes to the 1.13 beta 2 release of liblsl, which specifically seems to fix this problem. We replaced the 64 bit dll in our 1.13 labrecorder directory and it seems to work, we're still doing more testing, since this bug is very intermittent for us, but it looks promising. Perhaps you can just release a 1.13b labrecorder that packages the updated liblsl dll on the ftp site?
We're not sure if it affects steaming hardware clients - we've actually built one and are using liblsl64.dll, and haven't noticed any issues, although I'm not certain which version of liblsl we are using there. Perhaps @mgrivich would know since he helped resolve the issue. It would be good to know if we needed to replace that dll in our application as well, since I'm sure it's not the beta 2 release.
I don't want to close this issue since I guess the original problem with the latest version not stopping gracefully still exists.
It only affects inlets. Outlets were fine all the time, the clock synchronization code only failed to retrieve the offsets in some more or less rare cases.
@GitDoose - The latest master uses a smaller timeout on calls to pull_chunk_multiplexed. The xdf file should be written to more often and therefore the kb parameter should update correctly, and LabRecorder should close the file properly when recording is stopped.
I'm working on getting AppVeyor to automatically deploy the Windows builds to the GitHub release page, but that's a separate issue.