[solved] failure to start recording

christod

I am conducting an eyetracking study and I received the following message while running the experiment: Failed to start recording. Before the message appears the experiment ends. I am guessing this is related to the start recording prompt for the eyelink tracker. Any ideas what might be causing the failure? To create the experiment I used the Schreij and Owens template.

Alex

sebastiaan

Hi Alex,

That's weird. If you get to this point, it sounds like the Eyelink software/ PyLink have been installed properly, which is usually the cause for trouble. So, let's track the problem down:

• Do the demo Python Eyelink experiments, bundled with PyLink, run properly?

If so:

• Which Eyelink are you using? (1000/ 2/ 1)

• Which versions of OpenSesame / Eyelink plug-ins are you using?

• Does it happen always or only occasionally? I have noticed that the Eyelink 2 sometimes gives this error, which has (sort of) been resolved in the latest Eyelink plug-ins code by simply re-trying the start recording function a couple of times.

Regards,
Sebastiaan

christod

Hi Sebastiaan,

I checked the demos bundled with PyLink and they work
I followed the instructions on this link when installing opensesame http://osdoc.cogsci.nl/plug-ins/eyelink-plug-ins
I have installed opensesame 0.24 and plugins for eyelink 0.14. Are those the latest ones? We are using eyelink 2.

I don't get the error message all the time. I would say 1/4 or 1/5 times.

Also, another issue has cropped up. The .edf files are being overwritten. It seems that when the .edf is created it is labelled according to the first digit of the subject number. So subject number 11 writes over the .edf file for subject 1.
Thanks for your help,

Alex

sebastiaan

Alright, so let's track it down further. There are two slightly different error messages:

Failed to start recording (startRecording error)

and

Failed to start recording (waitForBlockStart error)

Which one do you get? (Or does it vary?) If you see the first one, you should also see a lot of messages in the debug window, like (if you don't see this, please try to update the eyelink plug-ins):

libeyelink.start_recording(): failed to start recording (attempt 1 of 100)

It seems that when the .edf is created it is labelled according to the first digit of the subject number. So subject number 11 writes over the .edf file for subject 1.

Yes, that's because the Eyelink can handle filenames of up to 8 characters. So subject11 (9 characters), becomes subject1 (8 characters). If you use shorter filenames, the problem will disappear. Perhaps the 8 character limitation could be dealt with a bit more elegantly, but it's easily overcome by using short filenames.

Hope this helps!

christod

Hi Sebastiaan,
I wasn't able to replicate the warning message today but I am pretty sure it was the former than the latter. After the message appeared, the debug window was filled with messages. I don't remember exactly what they said though. However, I had a different problem today that might relate to the existing issue. During drift correct I was getting large corrections (distance form the fixation point and the detected fixation). After a few consistently severe drift corrections the eyelink software on the host computer would abort the drift correction scene and go to the camera set up screen. At that point I had to hit the escape key to end the experiment. I tried going back to the drift correction scene but the experiment wouldn't advance to the following screen. I checked the debug window and there were a ton of drift correct failure messages. Is it possible that the start recording error is associated with an accumulation of drift error over trials? If that is the case, is there a way of escaping to the calibration screen when the drift correct fails repeatedly?
Thanks for clearing up the filename issue!

Alex

sebastiaan

It's hard for me to say how drift correction problems and startRecording errors might be related. The OpenSesame plug-ins simply wrap around the Eyelink software, which is closed so I have no insight into what goes on underneath. Quite conceivably, yes: If tracking is poor (as it often is) the software may have trouble in performing drift correction as well as starting recording. But that's all I can say, really.

You can always return to the calibration screen by pressing 'q'. 'Escape' will abort the experiment, so you probably want to stay clear of the 'escape' key!

May I suggest that you double-check whether the errors that you see are indeed as I described in the previous post? Specifically, are there indeed 100 messages like this in the debug window:

libeyelink.start_recording(): failed to start recording (attempt 1 of 100)

The reason that I'd like to be sure is that I'm a bit worried that you're running an older version of the plug-ins, which do not try startRecording() multiple times. If you are up to date, this would mean that startRecording() really fails 100 times in succession, which would be quite strange (but stranger things are known to happen).

christod

Hi Sebastiaan,
I haven't replicated the start recording issue so I wasn't able to check the debug window, unless there is a log saved in the bowels of open sesame. However, I re-downloaded the plugins from your website and compared the date of creation with the installed ones. It seems that you are right, I had the older version of the plugins. I just couldn't believe you had updated the plugins within such a short time. I think I installed your software a month ago.
Previously I would hit q during drift correct but it wouldn't go to the calibration screen. I had read about this procedure in the comments of your python script but it wouldn't work. It seems to be working great with the new plugins though. Hitting q during drift correct brings me to the calibration screen. After the calibration q brings me back to where the experiment left off! This is great!
Thanks for your continuous help.

Alex

sebastiaan

Awesome!

Yes, I update the plug-ins quite regularly, clearing the issues as they crop up. I suspect that, in this case I was a bit sloppy with the version number, though. I'll mark it as solved for now.