All API requests are of the form specified section of 'Query'.
Recommended calling method: POST.
All functions return either a response with its own parameters, or, in case of an error or inability to perform the requested operation, reply with the standard settings:
The standard response with error message (for example XML)
<response>
<error>
<code>UNKNOWN</code>
<message>Unknown error</message>
</error>
<servertime>1292870500</servertime>
</response>The presence of error is the presence in the response of the parameter <error> with a non-empty value of parameter <code>.
Parameter <code> returns a generic alias errors, and not numerical values.
All functions are divided into
• sessional
• working
• control
Task authorization functions: the creation of a working session with obtaining its unique ID (short: SID), maintaining the session in the active state and close the session.
All functions, except the authorization function of the session creation, only work within an open session, passing the SID session COOKIE in HTTP request or a query parameter. Total standard session looks like this:
• invoked the authorization function create a new session (the SID and other session parameters);
• performed all the necessary working and control functions;
• authorization function is called the closure of the session.
Remark
Unlike API versions below v1.0, is no longer manufactured, no server conversion.
Because with this:
1. Time_zone contains the settings and TIME_SHIFT stored in the system by the client API is not used directly. API in this case only provides a mechanism for the conservation, alteration, obtaining the specified parameters.
2. Times in UNIXTIMESTAMP format (including EPG) are given to the server as is. Taking into account the local time zone of the client owes, the client program, by adding to the received time the number of seconds offset of client time zone relative to Greenwich (GMT, UTC). The time_shift value passed in the request is returned in the response in the form of number of seconds.
3. If You want to take advantage of the offset broadcast backwards in time (time_shift), You will need to pass this parameter directly in the query. For this You can use it stored in the system, the value obtained by the query get_settings, or to specify a different integer value in the range 0...24 (hours). If the specified parameter in the request You skipped (absent), its default value is considered to be 0.
The example client program with the times API:
Take the current client time = 15:00 UTC = 14:00 (time zone +0100). The client wants to see the current show and coming 1 hour ago. Let's assume it started at exactly 14:00 the customer (13:00 UTC).
To do this, the client first queries the API /get_settings and gets saved on the server value of the client time zone (+0100) and time shift (3 hours). As you can see, the TimeShift saved is not the one we need and we need the value (1 hour) or save or use without saving.
Then the client passes in a query time_shift=1. And receives the EPG transmission time UNIXTIMESTAMP corresponding Greenwich mean time = 13:00 & parameter time_shift=3600. The client saw your local EPG in time, he will have to add to this UNIXTIMESTAMP even your time zone in seconds (in our case = +3600) and time_shift=3600. Then it will convert UNIXTIMESTAMP to its string representation and get their local transmission starting time = 15:00.