part5 has missing samples

[dora201888]

Hi Vincent,

I recently ran GGIR v3.3.2 and noticed that some samples are missing already in part 2 and part 4. After checking, this seems to be due to missing IDs in the header line (with idloc = 1). This behavior did not occur when I previously ran GGIR v2.9.2 with the same data.

I was therefore wondering how summary data are merged in part 5 in the newer versions of GGIR. Specifically, is the merging done based on the extracted participant ID, or on the filename? I am trying to understand whether missing or malformed IDs at earlier stages could explain the downstream sample loss I am observing in part 5.

Many thanks for your time and for maintaining GGIR.

Best regards,
Wei

[vincentvanhees]

Could it be that those files were collected with GENEAsleep? If yes, then this is an open issue: #1432 I I am hoping to fix in the upcoming days via #1434

If not: Could you check that GGIR part 1 still generates a milestone file in meta/basic for those missing IDs? If this is not the case, then my theory is that it relates to a similar problem as issues #1432: Earlier this year @jhmigueles added internal function inspect_binFile_brand.R to distinguish GENEActiv .bin files from Parmay .bin files but based on a strong assumption that the word GENEActiv needs to be in a field named Device Type, which at least for GENEAsleep is not the case.

@jhmigueles - Here are the possible solutions I can think of, what do you think?

1. Change mon = "not_recognised" in this line to mon = MONITOR$GENEACTIV. In that way it is impossible for any (historical) GENEActiv binary file formats to be missed.
2. Update code to generate an error every time the binary file format is not recognised, which forces the users to report the anomalies such that we can improve the code to catch all variations.
3. Combination of both, assume GENEActiv binary, but generate warning if the actual test for GENEActiv fails. This warning messages needs to ask the GGIR users to report the issue.

[dora201888]

Hi Vincent, Thank you for your reply. I would like to clarify that this is *not* the GENEAsleep device data. All other data files—including basic, CSV, MS2.out, MS6.out, as well as the part2 and part4 summary results—are complete and appear correct. The only issue is with *part5*, which contains some missing values. Thank you for your attention. Best, Wei

…

On Fri, Dec 19, 2025 at 2:17 PM Vincent van Hees ***@***.***> wrote: Could it be that those files were collected with GENEAsleep? If yes, then this is an open issue: #1432 <#1432> I I am hoping to fix in the upcoming days via #1434 <#1434> If not: Could you check that GGIR part 1 still generates a milestone file in meta/basic for those missing IDs? If this is not the case, then my theory is that it relates to a similar problem as issues #1432 <#1432>: Earlier this year @jhmigueles <https://github.com/jhmigueles> added internal function inspect_binFile_brand.R <https://github.com/wadpac/GGIR/blob/main/R/inspect_binFile_brand.R> to distinguish GENEActiv .bin files from Parmay .bin files but based on a strong assumption that the word GENEActiv needs to be in a field named Device Type, which at least for GENEAsleep is not the case. @jhmigueles <https://github.com/jhmigueles> - Here are the possible solutions I can think of: 1. Change mon = "not_recognised" in this line <https://github.com/wadpac/GGIR/blob/main/R/inspect_binFile_brand.R#L2> to mon = MONITOR$GENEACTIV. In that way it is impossible for any (historical) GENEActiv binary file formats to be missed. 2. Update code to generate an error every time the binary file format is not recognised, which forces the users to report the anomalies such that we can improve the code to catch all variations. 3. Combination of both, assume GENEActiv binary, but generate warning if the actual test for GENEActiv fails. This warning messages needs to ask the GGIR users to report the issue. — Reply to this email directly, view it on GitHub <#1436 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKJXY4BUHBMUL3AEBUCCZED4CRFK5AVCNFSM6AAAAACPSEOEISVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMZQGE3DCNQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[vincentvanhees]

@dora201888 could you share an example file with me to investigate? Via e-mail is also fine.

[dora201888]

Hi Vincent, I guess this issue could be fixed by changing idloc=6 (separate by .). I am still trying to see if this will work on my 3 GeneActiv data set (.bin). I will let you know if there are any issues. Thanks. Best regards, Wei

…

On Mon, Dec 22, 2025 at 3:18 AM Vincent van Hees ***@***.***> wrote: @dora201888 <https://github.com/dora201888> could you share an example file with me to investigate? Via e-mail is also fine. — Reply to this email directly, view it on GitHub <#1436 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKJXY4E3LTHTR47PCB7YHRT4C6SNTAVCNFSM6AAAAACPSEOEISVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMZRGU2TSMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>