Closed grebdems closed 6 years ago
Thanks!
I've had similar issues in the past, and resolved to only writing to disk when stop_recording
is called. In that way, a crash will cause less data loss (at most from the last call to stop_recording
, which generally is at the end of each trial). EDIT: I just checked, and it is already called in there. Should be fine, I think :)
After some testing it seems like the issue stems from high I/O loads, which in turn leads to callbacks not being consumed quick enough, leading to data drops, and disconnects from the eye tracker (automatic response). Apparently flushing to disk at every write creates a lot more io (haven't dug into exactly why), so the fix here is just to simply not flush until after recording is stopped. Btw, iirc the constant flushing was added with the idea that if the experiment should crash, the data would at least be safe. Should this become an issue in the future, there may be more advanced solutions that could combine the two approaches. The extra commit is just to fix some flake8 warnings (file is also committed to a local repo where we have automatic flake8 checks).