Yes, both on develop and master branches, DataID isn't protected by a mutex, even though rest of the data members are.
Paging Wim Vriend, hoping he'll step in and get this fixed in time for 1.8.
Only added data after the 'portable' part of the mapping is what's necessary to pass the NPClient 'api key' through the mappings. So it turns out tracker/filter data isn't passed in any way, no
I've fixed the DataID race in my fork ages ago:
https://github.com/opentrack/opentrack/blob/master/ftnoir_protocol_ft/ftnoir_protocol_ft.cpp but chances of it finding its way back to the original project are pretty slim
I'd disregard the DataID, treat data as always fresh, except for the all-zeros case. Does that sound even remotely sensible?
Will try to get DataID fix into the develop branch, fix mismatched locking, and some logic errors introduced into the shared memory segment class, in worst case I'll lose commit privileges but if hadn't given up on the parent project, wouldn't have forked it in the first place.