-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log messages in OpenGaze / GazePoint #165
Comments
Yes, I elected to use the To tackle the problem, I've tried an internal queue of messages that are simply stacked together until we know for certain that they are logged. A problem with this approach is that it requires monitoring the incoming logs for messages, and there seems to be a delay on this sometimes. Haven't fully figured out why, to be honest, but the net result was that sometimes messages repeated a few times (and some still slipped through the cracks!). For other trackers, I've used markers at the start of lines for data (e.g. DAT) or a log messages (e.g. MSG). We could do something similar here, and simply bind them to the latest incoming sample. (I.e. use the latest incoming sample time as a timestamp for the logged message.) |
Yes, that probably seems like the best solution. So basically messages correspond to additional rows (one per message) that are timestamped with the latest sample. What would that look like in the log file? |
Previously, I used to do something like:
But after seeing some common reading functions for x-delimited text files choke on this (inconsistent number of columns per line), I now think it should be something like this:
|
Hi Sebastiaan and Edwin. I'm a bit stuck here with the gazepoint. I'm sending log messages by using the "eyetracker.log" command into an inline script. Even if I'm sending messages with several seconds of interval, in the .tsv file, at least half of the messages are missing... Do you have any ideas ? |
Hi @JeanBaptisteMelmi , good to see you here! The GazePoint API only allows one message per sample, which means that if you send more than one message per sample duration, the messages get lost in the All messages should still be present in the additional text log, though, although of course it's inconvenient to have to work with two separate log files. |
As I mentioned in #164 , the current log-file format for OpenGaze / GazePoint does not lend itself well to logging lots of information. Essentially, log messages are recorded as part of the
USER_DATA
field of gaze samples. Therefore, you can only have one log message per sample (i.e. 60 log messages per second). And what's worse: users lose data when they send log messages more often than that.This limitation isn't necessary, because the log rate of PyGaze isn't limited by the sampling rate of the eye tracker. The main question is what we would like the log file to look like if there are multiple messages. Do you have any suggestions?
The text was updated successfully, but these errors were encountered: