Commit ce9ce4a0 authored by PAPADOPOULO Theodore's avatar PAPADOPOULO Theodore

Stop the GDFFileReader box at end of file.

parent c398a2c2
......@@ -681,6 +681,11 @@ void CGDFFileReader::writeEvents()
boolean CGDFFileReader::process()
// Stop the processing if we are at the end of the input stream.
if (m_oFile.eof())
return false;
//Don't do anything if an error as occurred while reading the input file
//for instance, if the file has channels with different sampling rates
  • Hi, I just (re?)noticed this branch while looking what to merge to the next release. I'm a bit suspicious about this commit as the behavior is not following the usual convention that a box returns "false" only if there's an error. EOF imo is not an error but entirely normal. Instead, the 'openvibe-like' behavior would be to have a secondary stimulation output stream added to the box to pass this information as a 'end of file reached' stimulation (this is very pedantic -- the stim could also be added to the normal stimulation stream but then the receiver could not be sure if its in the file or coming from the box). Player controller box could then react to this info and stop the player.

    Typically we handle this situation either by a timeout box or just expect the file to have the trigger to stop the scenario.

  • Honestly, I totally forgot about this.... I agree with what you say and we can close this branch.

    That being said I'm more and more unhappy with how OV deals with stopping. The scenario you depict is not safer than what is done in this wrong patch. Typically (I have not rechecked recently), the player is stopped as soon as the Player Controller receives the STOP tag. This is unpractical and the effect is not repeatable (depends on the scheduling).

    In my view, the player should be stopped only when all the boxes have seen and handled the STOP TAG. Obviously, this would also mean that the stimulation stream is sent to all boxes (or at least to all important boxes) or some complex interaction with the scheduler (to stop boxes only when they have dealt with the input chunk containing the stim). I have looked at doing that, but it requires too much time and too many changes, so that I fear I will not have time to do the job and/or it would not be accepted (as it might require an API change for plugins).

    We have a similar problem where we send a tag TRAIN followed by a tag STOP and stopping is sometimes done before the tag TRAIN is recorded is the ov file. This regrettably makes OV unpredictable.

Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment