openephys legacy format : handle gaps more correctly

[samuelgarcia]

@weiglszonja @bendichter @alejoe91 @CodyCBakerPhD
This PR should fix the gap problem in openephys legacy format.

The old an erroreneous ignore_timestamps_errors is deprecated.
Now there is a gap checking when parsing the header. If gaps are detected then internally the reader go in a gap mode reading which is slower because it need np.seachrsorted at every get_analogsignal_chunk().

I propagate this on spikeinterface side here SpikeInterface/spikeinterface#2450

[zm711]

Just a couple initial assert/error question comments for this.

[zm711]

strange is a bit hard to parse as an end user. What does strange mean? The previous not continuous would make the person think about the fact they paused/stopped and remember. Strange is not quite as descriptive. Is the issue that there are other problems than pauses/stops?

[CodyCBakerPhD]

If it's the file I'm thinking of, the 'strangeness' came from the headstage getting unplugged mid recording

[zm711]

Haha. That would make the recording a bit 'strange', but I think the old message still covered that. I can't think of a better single word then strange, but maybe the old verbosity would still be better than a difficult to parse word?

[samuelgarcia]

I will find a better message. The old message is outdated because we handle gaps now.
But in some case we have assymetric block size series instead of 1024 1024 1024 2048 1024 which is now correct we can have 700 524 700 524 700 524 which is very hard to handle and maybe is wrong.

[weiglszonja]

Thank you @samuelgarcia, I can confirm this fixes the files that I have from the lab where this issue was discovered. The read time is definitely slow;

reader = OpenEphysRawIO(dirname=folder, ignore_timestamps_errors=None)
reader.parse_header()

6-7 minutes to parse the header and

traces = reader.get_analogsignal_chunk(block_index=0, seg_index=0, i_start=0, i_stop=sig_size, stream_index=stream_index, channel_indexes=None)

and I measured 5 minutes to retrieve the traces for the whole recording (~3 hours) with 32 channels.

I think this is acceptable until we can guarantee that the timestamps are continuous and aligned with the data.

[bendichter]

That sounds good to me!