Back to the main page.
Bug 2150 - buffer recording hangs when writing with mobita
| Status | CLOSED WONTFIX |
| Reported | 2013-05-01 07:29:00 +0200 |
| Modified | 2019-08-10 12:36:42 +0200 |
| Product: | FieldTrip |
| Component: | realtime |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2013-05-01 07:29:55 +0200
On 26 Apr 2013, at 11:51, Loukianos Spyrou wrote: Does the problem both happen with fieldtrip/realtime/bin/xxx/buffer and with fieldtrip/realtime/bin/xxx/recording, where xxx is your platform? I tried our full system mobita2ft(virtual machine)<->ft_buffer<->brain stream with the xxx/buffer and then with xxx/recording and it only crashed with the recording(twice). I have put the saved data/events for one crash here: https://dl.dropboxusercontent.com/u/xxx/crash.zip I neglected to take a screenshot but what happens is that the buffer hangs, no message or anything. Doing ft_read_header() from a separate matlab also is unresponsive. There are three components involved here. Could you try to rule out that it is not the rightmost one by running bufferViewer instead? I tried this and it crashed as well. Again, no message and ft_read_header() is unresponsive. The data are here https://dl.dropboxusercontent.com/u/xxx/crash_bufferviewer.zip Note, that in both cases the mobita2ft was still running normally. With the buffer (not recording) it hasn't crashed so far. Does it make sense that the recording implementation causes the problem? If you can confirm that the problem persists with bufferViewer, then it suggests be in the left or middle or combination of the two. If this is the case, please run the mobita2ft in combination with ftbuffer, but without the rightmost column (brainstream or bufferViewer). This should show whether the problem is purely the interaction between mobita2ft and ftbuffer, and not the interaction between the three. I tried that as well for about an hour and it didn't crash with the recording buffer (didn't try the normal buffer).
Robert Oostenveld - 2013-05-01 07:32:03 +0200
I filed it as bug here to give it a bug number, which is easier for tracking the workflow and files.
Robert Oostenveld - 2013-05-01 07:35:50 +0200
thanks for the detailed report on the additional tests. It seems that there is a bug in the recording utility, not the buffer itself. Why are you using the recording utility to start with? As far as I know, it was designed by Stefan for debugging, not for normal "production" type of work. It might well be (given its status as debug tool) that it has not been recompiled for a long time and that some of the older and (by now) fixed bugs in the buffer source code still linger in the executable.
Robert Oostenveld - 2013-05-01 07:45:13 +0200
(In reply to comment #2) regarding it not being compiled for a long time: the following log shows otherwise ------------------------------------------------------------------------ r7323 | roboos | 2013-01-16 00:58:15 +0100 (Wed, 16 Jan 2013) | 2 lines enhancement - even more cleanups to the Makefiles, now for improved 32/64 bit handling on OS X. Recompiled everything on maci 32 bit. ------------------------------------------------------------------------ so it is not that it is a stale executable based on older code.
Robert Oostenveld - 2013-05-01 07:50:14 +0200
I looked at the recording code from Stefan: it consists of a layer that is implemented on top of buffer/src/socketserver, which is implemented on top of the actual low-level buffer code. That makes it difficult to debug. For me the most important question is at this moment: why is it needed in the first place? I also see documented at http://fieldtrip.fcdonders.nl/development/realtime/implementation?s[]=recording#recording_and_playing_back_online_experiments that the file format is not finalized yet and not meant for archiving.
Robert Oostenveld - 2018-11-08 14:04:29 +0100
This is a very old bug. Since we don't have a mobita, I don't see how to further address this. Please reopen if needed.