1.8 Alpha - Trouble With Some API Calls

Developer Experience
1

How can I get a list of all the displays in the 1.8 Alpha API?

All of these fail:

'displayId'=>'', 'displayId'=>'*', 'displayId'=>'!=""', and 'displayId'=>'!=\'\''

There must be another way.

I also tried to use the default displayGroupId of “1”

'data_to_pass' => array('displayGroups' => array('displayGroupId' => '1'))

Still did not work.

Got this in the log:

Named route not found for name: display.manage#0 C:\wamp\www\xibo18alpha\vendor\slim\slim\Slim\Slim.php(1087): Slim\Router->urlFor(‘display.manage’, Array) #1 C:\wamp\www\xibo18alpha\lib\Controller\Base.php(131): Slim\Slim->urlFor(‘display.manage’, Array) #2 C:\wamp\www\xibo18alpha\lib\Controller\Display.php(303): Xibo\Controller\Base->urlFor(‘display.manage’, Array) #3 [internal function]: Xibo\Controller\Display->grid() #4 C:\wamp\www\xibo18alpha\vendor\slim\slim\Slim\Route.php(173): call_user_func_array(Array, Array) #5 [internal function]: Slim\Route->Slim{closure}() #6 C:\wamp\www\xibo18alpha\vendor\slim\slim\Slim\Route.php(468): call_user_func_array(Object(Closure), Array) #7 C:\wamp\www\xibo18alpha\vendor\slim\slim\Slim\Slim.php(1357): Slim\Route->dispatch() #8 C:\wamp\www\xibo18alpha\vendor\slim\slim\Slim\Middleware\Flash.php(85): Slim\Slim->call() #9 C:\wamp\www\xibo18alpha\vendor\slim\slim\Slim\Middleware\MethodOverride.php(92): Slim\Middleware\Flash->call() #10 C:\wamp\www\xibo18alpha\lib\Middleware\ApiAuthenticationOAuth.php(53): Slim\Middleware\MethodOverride->call() #11 C:\wamp\www\xibo18alpha\lib\Middleware\State.php(91): Xibo\Middleware\ApiAuthenticationOAuth->call() #12 C:\wamp\www\xibo18alpha\lib\Middleware\Storage.php(39): Xibo\Middleware\State->call() #13 C:\wamp\www\xibo18alpha\vendor\slim\slim\Slim\Slim.php(1302): Xibo\Middleware\Storage->call() #14 C:\wamp\www\xibo18alpha\web\api\index.php(95): Slim\Slim->run() #15 {main}

2

We also have various other API calls that are not working. Such as when trying to add a user:

3	7109399	2015-09-27 22:05	API	POST	DEBUG		/user	User name must be between 1 and 50 characters.

The username was set to a 16 characters in length.

When trying to upload media we get “File Type Not Allowed” on everything; mp4, jpg, and in the CMS log we see:

3 983664a 2015-09-28 20:52 API POST DEBUG /library Loading 1. All Objects = 0
2 8e4c340 2015-09-28 20:52 API POST DEBUG /library Loading 1. All Objects = 0

We are assuming that we are still sending the file to the api and not just the path. (Although we tried the file path as well)

When we delete media, the media is deleted from the CMS, but nothing is logged in the log, and we also get nothing returned from the API.

When trying to get statistics on anything the returned response is always empty, and we see Converted Times received are: FromDt=. ToDt=1970-01-01 in the log.

We just want to double check where the problems on these are. Our end, on how we are trying to do the calls? Is there some additional logging that can shed some light on these?

3

Your first one was a problem (the display list). As for the others, i’m not so sure - with each problem can you post the code you are using to send the request?

Media uploading has changes a little bit to a standard interface between jquery-file-upload and the api, so that we don’t have to maintain separate code paths for both (cut down on errors, not just being lazy).

Essentially this means that your API application needs to send files in the same way as this: https://github.com/blueimp/jQuery-File-Upload/blob/master/js/jquery.fileupload.js

I’ve not worked out how to do that yet, but I know its possible because the file upload tool does it :smiley:

4

We will check into that, as we are looking to replace how we do it as well.

Trouble adding user:
Code

function addClient_user($userName_, $email, $userTypeId, $homePageId, $libraryQuota, $password, $groupId) {
$params = array(
‘api_path’ => ‘/api/user’,
‘api_method’ => ‘post’,
‘data_to_pass’ => array(‘userName’ => $userName_, ‘email’ => $email, ‘userTypeId’ => $userTypeId, ‘homePageId’ => $homePageId, ‘libraryQuota’ => $libraryQuota, ‘password’ => $password, ‘groupId’ => $groupId)
);
callService($params, true);
}

function callService($params, $echo = false) {

$client = new Client();
$request = $client->$params[‘api_method’](SERVER_BASE.$params[‘api_path’],
[‘Authorization’=>[‘access_token’=>'Bearer ‘.$client_access_token’]],
[$params[‘data_to_pass’]]
);

$full_response = $request->send();
$GLOBALS[‘return’] = $full_response->getBody();
}

Deleting Media:
Code

function LibraryMediaDelete(){
$params = array(
‘api_path’ => ‘/api/library/’.intval($_GET[‘mediaId’]),
‘api_method’ => ‘delete’,
‘data_to_pass’ => NULL

);

callService($params, true);
}

function callService($params, $echo = false) {

$client = new Client();
$request = $client->$params[‘api_method’](SERVER_BASE.$params[‘api_path’],
[‘Authorization’=>[‘access_token’=>'Bearer ‘.$client_access_token’]],
[$params[‘data_to_pass’]]
);

$full_response = $request->send();
$GLOBALS[‘return’] = $full_response->getBody();
}

Getting Statistics:
Code

function statsMedia() {
$params = array(
‘api_path’ => ‘/api/stats’,
‘api_method’ => ‘GET’,
‘data_to_pass’ => array(‘display’ => 1)
);

callService($params, true);

}

function callService($params, $echo = false) {

$client = new Client();
$request = $client->$params[‘api_method’](SERVER_BASE.$params[‘api_path’],
[‘Authorization’=>[‘access_token’=>'Bearer ‘.$client_access_token’]],
[$params[‘data_to_pass’]]
);

$full_response = $request->send();
$GLOBALS[‘return’] = $full_response->getBody();
}

Getting Display Statistics:
Tried the latest as of today. We don’t see an error anymore, but we also don’t get anything else. Log shows this:
logId,runNo,logDate,channel,page,function,message,display.display,type

1,8aee385,“2015-09-29 20:55:47”,API,/display,GET,“Loading 1. All Objects = 0”,DEBUG
2,8aee385,“2015-09-29 20:55:47”,API,/display,GET,“Config loaded [0]: ”,DEBUG

5

Regarding stats - there should be a default value of yesterday - today, but there isn’t… i’ll fix that. If you provide fromDt and toDt to the call you should get some results.

I’ll add to the docs too

6

Dan,

I tried to add fromDt and toDt but still get an empty response.

I noticed in the database that the “statDate” entries are 14 hours in the future. Not sure why that is. I checked the regional settings in the CMS and they are correct. I don’t think this would affect pulling the data.

7

Dan will be able to confirm for sure, but I think the CMS records timestamps in UTC and then converts forward/back depending on the users timezone. Would a 14 hour offset make sense on that basis?

8

Alex,

Depending on the time of year, since we have “Daylight Savings” time here, it should be 7-8 hours difference. I Think.

We are in the PST time zone. GMT -08:00

9

What values did you have for those? all dates provided should be in the format y-m-d H:i:s. In my test I am supplying this:

http://192.168.0.19/api/stats?access_token={{access_token}}&fromDt=2015-01-01 00:00:00&toDt=2015-10-01 00:00:00

I am not sure why your stats are being recorded ahead of time in that manner - we will have to see the SubmitStats log to determine what values are coming from the Player

10

2015-09-29 07:38:52 and 2015-09-30 07:38:52

Where do I find the SubmitStats log?

This format does work when it is typed into the browser. So the problem must be in our submission to the API.

Thank you.

11

If you have auditing turned on for that display it will log all statistics submissions from the player > CMS in the raw XML. If we can prove that those dates are correct then I need to hunt for the conversion problem :slight_smile:

12

Everytime I check to see if Auditing is turn on, on the display, it shows off. If I turn it on save and then check again it again says it is off.

Otherwise if I understand correctly, you are saying that if Auditing on the display is on, the information you are looking for will be passed to the CMS log, and you would then like a copy of the CMS log?

13

Yes exactly so - and I will look at that form issue on Display.

14

views/display-form-edit.twig line 139 should read:

{{ forms.dropdown("isAuditing", "single", title, display.isAuditing, options, "id", "value", helpText) }}
15

StatSubmit:

Received XML. <log><stat type="layout" fromdt="2015-09-30 11:24:14" todt="2015-09-30 11:24:35" layoutid="2" scheduleid="-1" mediaid="null" tag="null"></stat><stat type="media" fromdt="2015-09-30 11:24:24" todt="2015-09-30 11:24:34" layoutid="2" scheduleid="-1" mediaid="2" tag="null"></stat><stat type="media" fromdt="2015-09-30 11:24:35" todt="2015-09-30 11:24:45" layoutid="2" scheduleid="-1" mediaid="1" tag="null"></stat><stat type="layout" fromdt="2015-09-30 11:24:35" todt="2015-09-30 11:24:55" layoutid="2" scheduleid="-1" mediaid="null" tag="null"></stat><stat type="media" fromdt="2015-09-30 11:24:45" todt="2015-09-30 11:24:55" layoutid="2" scheduleid="-1" mediaid="2" tag="null"></stat><stat type="media" fromdt="2015-09-30 11:24:55" todt="2015-09-30 11:25:05" layoutid="2" scheduleid="-1" mediaid="1" tag="null"></stat><stat type="layout" fromdt="2015-09-30 11:24:55" todt="2015-09-30 11:25:06" layoutid="2" scheduleid="-1" mediaid="null" tag="null"></stat><stat type="media" fromdt="2015-09-30 11:25:05" todt="2015-09-30 11:25:06" layoutid="2" scheduleid="-1" mediaid="2" tag="null"></stat></log>

The edit to views/display-form-edit.twig did fix the Audit option being read correctly. “Interleave Default” also has the same problem.

16

Sorry - are those dates correct? I.e. matching the ones that get written to the stat table? Or are they being fudged somehow?

You’d except the statDate to be the date they were received by the CMS and the start/end to be the dates of the actual events.

17

Sorry, yes those dates are correct but the statDate entries are not.

18

statDate is the date the record is written - start/end should be player time. Are they all in the future, or only the statDate?

19

Only the statDate is in the future.

20

Well that is very strange indeed - the statDate is populated with the result of this: date("Y-m-d H:i:s")… i’ll do some digging