omconvert.py doesn't process the whole .omx file if there is a long non-wear period

[RuotsaI]

Hi @danielgjackson ! Thanks for the great tool. I have used OmConvert tool (from openmovement.process) to convert my .omx files (from MoveMonitor) to .csv. I noticed that when there's a long non-wear period (>24 h) in the middle of the measurement, OmConvert stops and does not process the rest of the file. Is there any possibility to get the rest of file also converted/analysed even though there are long periods of non-wear time?

Thanks!
Ilona

[danielgjackson]

The Python code uses an underlying binary:

• https://github.com/digitalinteraction/omconvert

The maximum "gap" duration is set to 7 days here:

• https://github.com/digitalinteraction/omconvert/blob/master/src/omconvert/omdata.c#L1409

The reason there is a maximum value is that omconvert is designed to always generate a fixed output rate -- even if there are gaps. This makes sense for .WAV files, as they have only got a single block of samples, so cannot have any gaps. For CSV, this still makes sense if the user really wants a fixed rate.

If the allowed gap was much larger, the output file will become even larger, and mostly filled with empty content.

What range of gaps do you have in your data files?

I have already started work on a Python-based OMX loader, and I think this will be more appropriate for your job -- I will update this issue when it is ready.

[RuotsaI]

Thank you for the answer! The longest gap I have is less than 2 days. So that should not be the problem, but the produced .csv file is still incomplete. In the .omx file the begin and end time are T0,2021/06/09,12:00:00 T1,2021/06/16,12:00:00, but the converted .csv ends at 2021-06-12 07:03:36.240, just before the beginning of the 24 h non-wear period. Do you have any ideas what might be going on?

I have already started work on a Python-based OMX loader, and I think this will be more appropriate for your job -- I will update this issue when it is ready.

That would be great!