Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Reading chunk length error" after a Python crash at the end of the recording, any solution ? #83

Open
Jbelo-Inria opened this issue Dec 13, 2021 · 5 comments

Comments

@Jbelo-Inria
Copy link

Jbelo-Inria commented Dec 13, 2021

Hi guys,
I'm trying to read .xdf files with the pyxdf.load_xdf() function but I have this error for some of my files :

Error reading chunk length
Traceback (most recent call last):
File "/user/jbelo/home/anaconda3/lib/python3.7/site-packages/pyxdf/pyxdf.py", line 237, in load_xdf
chunklen = _read_varlen_int(f)
File "/user/jbelo/home/anaconda3/lib/python3.7/site-packages/pyxdf/pyxdf.py", line 487, in _read_varlen_int
raise RuntimeError("invalid variable-length integer encountered.")
RuntimeError: invalid variable-length integer encountered.
got zero-length chunk, scanning forward to next boundary chunk.

For those files, Python crash during the recording at the very end of the experiment and even if the experiment was already finished it seems that the files were corrupted by it.
I check in the files and there is no "Footer" dict.
And the second problem is when I want to transform my .xdf files in .fif ones (using MNElab), it doesn't work probably because of this error.

Do you have any suggestion to solve this problems or those files are definitely unusable ?

Thanks in advance,
Joan

@cbrnr
Copy link
Contributor

cbrnr commented Dec 13, 2021

You don't need a footer for a valid XDF file, but if the recording crashes without properly closing, you will end up with invalid data. I don't know if there are any repair tools available, but in principle it should be possible to use all chunks up until the corrupted one.

@agricolab
Copy link
Member

You can use XDFBrowser to inspect the file: https://github.com/xdf-modules/XDFBrowser, which can give you a little bit more info about the misbehaving chunk.

Considering the recording stopped, the warning you see is likely simply the data loss, and the recorder stopped writing to the file before the chunk (and the footer) was correctly finished. I also don't know about any tool for repairing but that's certainly doable and not too hard. I don't know about your pipeline for fif-conversion. If you share it, we can give more advice.

Following these two example scripts, wouldn't first loading with pyxdf, then conversion to mne,Raw and then saving not work?
https://mne.tools/dev/auto_examples/io/read_xdf.html
https://mne.tools/stable/generated/mne.io.Raw.html#mne.io.Raw.save

image

@Jbelo-Inria
Copy link
Author

Thanks for the comments and advices guys.
Ok, so I can use the files up until the corrupted chunk, that's good news.

To give you more details, I'm using LSL to record multiple streams (EEG, Eye tracker, Markers) synchronously and a modified version of Open Sesame to run the experiment.
This way of recording things allow me, at the end, to synchronise the markers with the EEG (and Eye tracker) data. From the files (and also the corrupted ones), I can extract the marker stream and the EEG stream, create a Raw file using mne raw data structure creation pipeline and add the markers extracted as annotation and then record this raw file as a .fif file.
But the weird think with the corrupted files is that the annotation starts very lately (while they should start at the beginning of the experiment). It's like an information about the real start time of the annotations is missing in the .xdf file. This real start time probably correspond to the "orig time" variable of the mne annotations. But I'm not sure how to obtain this information and if it's at least present in the my corrupted .xdf file.
So my question is : is a solution exist to fix this issue ?

Thanks,
Joan

Unfortunately I cannot attached one of those .xdf files because this file type is not supported...

@agricolab
Copy link
Member

agricolab commented Dec 15, 2021

I struggle a little bit with understanding your issue here. What i understand is that there is an additional marker stream, and you want to use that one to create annotations for the mne.Raw. But, the timestamps of this marker stream are not aligned well?

What i usually do is create a plot of the timestamps to inspect the distribution. If they are only shifted (but not clustered due to a network issue), you might be able to recover them. Did you start recording with LabRecorder and your experimental task via a script, or was everything started separate and manually?

This seems to be in addition to the file recording having been aborted prematurely. Might be that both was caused by a common error in the recording PC, but the fix is probably different.

@cbrnr
Copy link
Contributor

cbrnr commented Dec 15, 2021

I agree that these might be two separate issues.

FYI, I've just added an option to view XDF chunks to MNELAB. It's pretty much what XDFBrowser does, but it should be easier to deploy (not everyone is familiar with compiling a C++ program for those who cannot use the provided Windows binary). If you want to use this feature right now (i.e. before the next release), you can install the dev version with:

pip install git+https://github.com/cbrnr/mnelab

The option is then available under "File" – "Show XDF chunks...".
Screen Shot 2021-12-15 at 14 10 27

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants