Open Ephys GUI cause blue screen of death while recording ephys data and camera recording in parralel
HisayukiOsanai opened this issue · 17 comments
I am recording ephys data with open ephys GUI in parallel with video recording with Windows camera app (640*480, 30Hz). However, after 30 mins to 1 hours from the recording start, Windows always crashes and cause blue screen of death. It does not happen when only GUI or only camera app is running. I changed the camera to normal USB webcam, changed camera apps (e.g. Bonsai), and reduced the recording sampling rate from 30kHz to 2kHz, but the same problem still occurs.
I am now successfully recording ephys data and video using different PCs... but it's nicer to do in a single PC. Could you let me know what I can do? I attached the files of GUI node setting and the setting file in the recording folder when the PC was crashed.
- GUI version: v0.5.5.3.
- PC spec:
Windows 10 Home
Intel i9-11900K
Memory: 64GB
2TB M.2 SSD (1.62TB free)
Thank you!
Hisayuk
setting files.zip
Hi there! Everything looks good with your signal chain and your computer specs. It seems like this is due to some strange interactions at the level of the USB controller, so unfortunately I don't have any great ideas about how to fix it.
Here are a few things you can try, if you haven't already:
- Make sure your acquisition board and camera are both plugged into USB 3.0 ports
- Try installing the latest version of the Opal Kelly FrontPanel USB driver
Let me know if either of those things help!
Hi!
Thank you for your advise! I installed USB driver, but Windows still crushes 2-3h after recordings. I plugged both acquisition board and camera to USB 3.0 ports (currently trying in USB 3.1).
Also, sometimes Windows crushes during recordings only with open ephys GUI. (it is difficult to check this reproducibility)
It looks the situations get better but still have problem. Co you have any idea to solve it?
Can you test whether acquiring data with just the Rhythm FPGA plugin in the signal chain causes system crashes? That will tell us whether it's something related to USB data transfer, or something downstream in the signal chain.
Sorry for very late response. I checked it several times, and saw just the Rhythm FPGA cause PC crash and make the PC reboot automatically during recordings.
Ok, this is very strange. Do you know the model of the motherboard in your computer?
These are the list of PC parts:
-
Mother board: ROG Strix Z590-A Gaming WiFi 6 LGA 1200(Intel 11th/10thGen) ATX White Scheme Gaming Motherboard (PCIe 4.0, 14+2 Power Stages, WiFi 6, Intel 2.5 Gb LAN, Thunderbolt 4, 3X M.2/NVMe SSD, Aura RGB)
https://rog.asus.com/motherboards/rog-strix/rog-strix-z590-a-gaming-wifi-model/ -
CPU: Intel Core i9-11900K - Core i9 11th Gen Rocket Lake 8-Core 3.5 GHz LGA
-
Memory: G.SKILL TridentZ RGB Series 64GB (2 x 32GB) 288-Pin DDR4 SDRAM DDR4 3600 (PC4 28800)
-
Strage1: SAMSUNG 970 EVO Plus SSD 2TB - M.2 NVMe Interface Internal Solid State Drive with V-NAND Technology (MZ-V7S2T0B/AM)
-
Strage2: SAMSUNG 870 QVO SATA III 2.5" SSD 4TB (MZ-77Q4T0B) 4TB
-
Graphic card: ASUS GeForce GTX 1060 DUAL-GTX1060-O6G 6GB 192-Bit GDDR5 PCI Express 3.0 HDCP Ready Video Card
-
OS: Windows10 home
Thanks,
Oh sorry, I was testing with Rhythm FPGA plus other plugins as I attached. I am now testing with only Rhythm FPGA plugin.
211216.zip
I leave Open Ephys GUI only with Rhythm FPGA plugin turn on for 7 hours, but it does not cause crash. I suspect recording files but not acquiring can cause crash, so I am checking on recording data with just the Rhythm FPGA plugin and Recording node now.
I did recording only with Rhythm FPGA plugin and Recording node 3 times with >3hours, but it did not cause PC crash. Do you heard any report that using many plugins could crash PC? Do you have any idea what caused crash?
We have a computer with the same motherboard, so I don't think that's the issue. Looking at your signal chain again, it's possible that having multiple Record Nodes writing to the Open Ephys format is causing the crashes. Windows often has problems writing to many files in parallel. You could try placing a single Record Node in your signal chain, or switching to the Binary format.
Oh I see. We want to record LFPs (<500Hz) and Spikes (0.5-2kHz) at the same time, so I think we need to use at least two Record Node. Is there a way to record LFPs and Spikes in a single Record Node?
I'd like to keep using OpenEphys format if possible because I'm afraid mismatch of data length and recording timestamp if data missing error occurs during recording with Binary format.
If you want to extract spikes online, then you'll need to use two separate Record Nodes (one pre-filtering, and one post-filtering / spike detection). Alternatively, you could just record the original data stream, and perform filtering / spike detection offline.
Can you try doing a recording with a preview version of the next major release (0.6.0)? https://openephysgui.jfrog.io/artifactory/Test/windows/open-ephys-v0.6.0-rc2-windows-beta.zip
It includes a number of under-the-hood changes that should reduce CPU load, as well as an updated version of the JUCE library (which has some Windows-specific improvements). It's not quite ready for widespread release, but we've been using it for recordings at the Allen Institute and it's working great. I'm not sure if it will help in your case, but it's worth a shot.
The "Rhythm Plugins" are no longer included by default, they must be installed via the Plugin Installer. The Open Ephys acquisition board plugin is now called "Acquisition Board," to distinguish it from the one for the Intan RHD USB board.
It looks the v0.6.0 GUI does not cause PC crash! I tried ephys recording in parallel with video recording overnight, but it does not made PC crash although I used same node settings. I will tell you if the problem occurs again.
Thank you!
While PC crash error does not appear anymore at now, I think there is a bug in the Channel Map plugin in v0.6.0. I changed the order of the channels, but when I closed and reopened the GUI, channel order was reset and also loading channel order file did not work.
Also, the current version cannot set low cut filter less than 1Hz (e.g. 0.1Hz) in the Bandpass Filter plugin.
Glad to hear the crashes aren't happening with the latest version!
Thanks for reporting those issues. That Channel Map bug has been fixed now. For the Bandpass Filter we changed the cutoff parameters to integers, but I think it makes sense to change it back to float – having a ~0.1 Hz cutoff is definitely useful!
Thank you very much! It would be great if we can use the bug fixed version when it is available.
It sounds like this issue was resolved by GUI version 0.6.0, which has now been officially released. The problems with the Channel Map and Bandpass Filter plugins have also been fixed.