Clients should not be able to change the stream contents when it is known that Central's File.exe is recording.
IMO the NSP or hub should not know or care what another client is doing, so this feature should not be relied on and I think it should be impossible.
The better solution is for every application that is sensitive to changes in the contents of a datastream (e.g., visualization, processing with tight buffer sizes) to register a callback for config change packets, and to appropriately modify their operation (reset buffers or stop recording) when a config change is acknowledged.
However, even this isn't a perfect solution at the moment because it's currently possible in the Gemini system for packets to be out of order (config change acknowledged then old-config data packets come through for a few msec).
Clients should not be able to change the stream contents when it is known that Central's File.exe is recording.
IMO the NSP or hub should not know or care what another client is doing, so this feature should not be relied on and I think it should be impossible.
The better solution is for every application that is sensitive to changes in the contents of a datastream (e.g., visualization, processing with tight buffer sizes) to register a callback for config change packets, and to appropriately modify their operation (reset buffers or stop recording) when a config change is acknowledged.
However, even this isn't a perfect solution at the moment because it's currently possible in the Gemini system for packets to be out of order (config change acknowledged then old-config data packets come through for a few msec).