The Eye Tribe

Hi, all!

I user VS2005, boost 1.55 and c++ client v. 0.9.49 for developing.
I have faced with problem when program freez on calibration_start() function.
It happens almost when I use debug version of client dll and my program and sometimes when I use release version of client dll and my program.
I debug SDK library and found next source code

Code: Select all

        bool calibration_start( int const point_count )
        {
            m_calibration_proxy.start_calibration( point_count );
            std::stringstream ss;
            ss << "{\"category\":\"calibration\",\"request\":\"start\",\"values\":{\"pointcount\":" << point_count << "}}";

            clear_sync_req( SR_CSTART );
            send( ss.str() );
            return wait_sync_req( SR_CSTART );
        }

there is problem with wait_sync_req( SR_CSTART ) there. This function runs in circle with next values:
m_sync_requests = 0x2e;
sr = 0x10

Do any have idea about it?

What is the value of the point_count argument?
Are you using the latest public release of the server?
Is the server running and do you have a valid socket connection with the server?
Is the server returning any console messages (INFO, WARNING, ERROR), or anything in the log file?

The m_sync_requests member indicates that all control flags are set except for SR_ERROR and SR_CSTART, which states that the GazeAPI has been connected to the server and successfully retrieved the initial requests. The C++ SDK is not multithread robust in the way that if multiple threads access the same GazeAPI instance it is possible to steal and/or overwrite the control flags.

To secure you're not hitting an MT sync issue, could you try only to access the same GazeAPI obj from the same thread?`

Micky wrote:What is the value of the point_count argument?
Are you using the latest public release of the server?
Is the server running and do you have a valid socket connection with the server?
Is the server returning any console messages (INFO, WARNING, ERROR), or anything in the log file?

The m_sync_requests member indicates that all control flags are set except for SR_ERROR and SR_CSTART, which states that the GazeAPI has been connected to the server and successfully retrieved the initial requests. The C++ SDK is not multithread robust in the way that if multiple threads access the same GazeAPI instance it is possible to steal and/or overwrite the control flags.

To secure you're not hitting an MT sync issue, could you try only to access the same GazeAPI obj from the same thread?`

Hello, Micky! Thank You for reply!
Yes, I do. Server version is 0.9.56
Connection is good and log file is writing. I have looked into log file and found last message

2015-05-19 13:14:56.996|1008566568|I|Creating new connection [184683626496]
2015-05-19 13:16:27.665|1008566568|I|Default calibration profile saved successfully

This message was called from last calibration. After that I call another calibration and program freezed.
I make calibration with 9 points.
I don't have another messages from server or in log file.

In debug version I have log:

2015-05-19 14:00:54.724|1470291525|I|New connection detected [176093691904]
2015-05-19 14:00:54.792|3357221379|I|The device stream has started
2015-05-19 14:00:54.792|1470291525|I|Tracker started
2015-05-19 14:00:54.792|1470291525|I|Creating new connection [176093691904]

I use only one thread to gaze api access.

With the next official release of TheEyeTribeSDK we will update the SDKs as well.
The C++ SDK will include a fix for the experienced problem.

Hi,
My name's Jordi. I tried implement my custom client done in c++ and SDL_net 2.0 and I have my own mini client that parses/sends JSON messages. I achieved communication with the Eyetribe server perfectly.

Then, I tried to do the calibration in the same way and I achieved it. But sometimes the calibration stage hangs always from "start_point" requests when you redoes calibration ... so that's because I came at this forum and I saw this message on the problem about "point_start" requests.

My questions are ... Is the problem already solved? When is expected the next release ?

Cheers,

I finally got around to look into the issue.
There's an internal network deadlock issue that stalls the thread in a send_sync call. The method never terminates because the expected reply message from the server is never received, due to the thread is stalled.
Temporarily, the problem can be fixed using async send to update the internal states that is triggered by server changed notifications.