I am wondering about api/stats api calls. More specificly pagination on stats. Currently I am getting 3 real results spread across 2 pages on the pagination, with 5 results per page and the api returning a total of 6 results. So first page shows 2 results, second page shows one result.
Edit: It would appear that if no media is defined this happens. It would appear that the stats api will return other items (layouts) besides images and video(Aka Media), which is fine. However we are in need of the ability to filter by media. We could filter the returned results, but the extra data is consuming resources needlessly, and this also makes pagination from the API useless.
I would like to request an enhancement to 1.8 on api/stats to allow for filtering by Type.
You are getting 6 results in total - 5 on the first page and 1 on the second? You’ve said 2 results on the first page and one on the second? making a total of 3 results?
Are you suggesting that the “layout” stats are not required in your case?
The stats data is aggregated by Layout, Media, Widget - so you are always going to get Layout in the results. Perhaps it is just the “entire layout” stat you don’t want?
Would it be better to have a view on the raw data?
Perhaps we need to approach this from the other direction - what are you actually trying to get out?
Sorry for the confusion. The problem I was seeing is that pagination is including both layouts and media, but our code was dropping anything not media. So the results looked strange.
Are you suggesting that the “layout” stats are not required in your case?
Yes. We have third party reports that get pulled live for media, so layout stats are not needed.
I am not sure what the difference between a “layout” stat and an “entire layout” stat. Is there a difference?
Approching it differently…
We have clients that we need to provide proof of play to, based on media, that is, well, theirs. Our client portal has been designed to pull data in realtime from Xibo. (They have no idea about layouts, and added data, well confuses some people). So we would like to be able to pull only the media stats, as the proof of play for them, while retaining the pagination from the Xibo API. This way, we do not need to manually calculate the pagination and do conversions within the code.
Right, I understand what you are trying to achieve
The aggregated view is fine, BUT you are not interested in the information related to the layout, only the individual media contained on those layouts.
Consider the following example:
Layout A contains Media X and Media Y. Media X runs for 60 seconds, Media Y for 120 seconds. Assume the Layout was the only thing running on the Display and it had been running for 24 hours.
You would expect to see the following:
| RecordId | Type | Layout | Media | Duration |
|----------|--------|--------|-------|----------|
| 1 | Layout | A | | 86400 |
| 2 | Media | A | X | 28800 |
| 3 | Media | A | Y | 57600 |
The times might be slightly reduced due to the time it takes to load a Layout - but you get the idea.
If you filtered the table by type you would have what you want. However, the thing to be aware of is what would happen if Layout B also ran Media X. Lets assume that it only runs Media X for 60 seconds and that Layout A and B were running in cycle.
| RecordId | Type | Layout | Media | Duration |
|----------|--------|--------|-------|----------|
| 1 | Layout | A | | 43200 |
| 2 | Media | A | X | 14400 |
| 3 | Media | A | Y | 28800 |
| 4 | Layout | B | | 43200 |
| 5 | Media | B | X | 43200 |
Filter that to type=media only:
| RecordId | Type | Layout | Media | Duration |
|----------|--------|--------|-------|----------|
| 2 | Media | A | X | 14400 |
| 3 | Media | A | Y | 28800 |
| 5 | Media | B | X | 43200 |
Notice you have 2 X’s ?
Is this the result you want?
Would it be better to get each individual playback of X so that you could work it out for yourself?
Note the Swagger documentation show capitals on the options for “type”. The API will not return the desired results unless the options are given in all lowercase.
Also would be handy to know the format the API wants “fromDt” and “toDt” in is, 2017-05-31 00:00:00 . And knowing how to get more than 10 results with “start” and “length” params is good too. start=0, length=1000
I’ve made an adjustment so that upper/lower case types will be accepted (seemed more flexible).
Dates are always expected to be Y:m:d H:i:s - this should be mentioned in the Manual I think, rather than on every request in the API doc - the same is also true for Paging, Link Headers and X-Total-Count.
