You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current flow of the session_id in the Experiment class is in two parts: the session_id itself, and the timestamp that it contains, it is updated as follows:
Start of Stytra: first timestamp is defined in the __init__ call, session_id is set to None.
Start of experiment: session_id is updated to the first timestamp, the timestamp variable stays the same.
Start of the protocol: nothing happens.
End of the protocol: set_id is called, but session_id does not get updated because we still use the first timestamp. After this, the timestamp gets updated. So session_id reflects the first timestamp, but the timestamp itself is already the second timestamp.
Start of the second protocol run: nothing happens.
End of the second protocol run: set_id is called, it gets updated to the second timestamp. After this, the timestamp gets updated. So session_id reflects the second timestamp, but the timestamp itself is already the third timestamp.
So between 3 and 4, the first (and correct) timestamp is used. Between 5 and 6, the first (and incorrect) timestamp is used. And between a potential 7 and 8, the second (and incorrect) timestamp will be used.
The resulting effect (at least for me) is since there is a dependency session_id -> filename_prefix -> filename_base. So the filename during a protocol run will reflect the previous protocol from the second protocol onward. Only once the protocol is ended will it get updated. This usually poses no problem, since most files are written after this. However, I don't think this is a logical flow for session_id, and it results in problems such as when writing the video file, since it needs a file to write to from the onset of the protocol.
Since this code comes from the Experiment class I do not know how much code is reliant on the current behaviour. It would likely be good to test/check the code that makes use of this before pushing a fix.
The text was updated successfully, but these errors were encountered:
The current flow of the
session_id
in theExperiment
class is in two parts: thesession_id
itself, and the timestamp that it contains, it is updated as follows:__init__
call,session_id
is set toNone
.session_id
is updated to the first timestamp, the timestamp variable stays the same.set_id
is called, butsession_id
does not get updated because we still use the first timestamp. After this, the timestamp gets updated. Sosession_id
reflects the first timestamp, but the timestamp itself is already the second timestamp.set_id
is called, it gets updated to the second timestamp. After this, the timestamp gets updated. Sosession_id
reflects the second timestamp, but the timestamp itself is already the third timestamp.So between 3 and 4, the first (and correct) timestamp is used. Between 5 and 6, the first (and incorrect) timestamp is used. And between a potential 7 and 8, the second (and incorrect) timestamp will be used.
The resulting effect (at least for me) is since there is a dependency
session_id
->filename_prefix
->filename_base
. So the filename during a protocol run will reflect the previous protocol from the second protocol onward. Only once the protocol is ended will it get updated. This usually poses no problem, since most files are written after this. However, I don't think this is a logical flow for session_id, and it results in problems such as when writing the video file, since it needs a file to write to from the onset of the protocol.Since this code comes from the
Experiment
class I do not know how much code is reliant on the current behaviour. It would likely be good to test/check the code that makes use of this before pushing a fix.The text was updated successfully, but these errors were encountered: