Problem with AnalyticsVideo and range selection

Hi Doug,

I found out another problem with NodeJS SDK and client.analyticsVideo.get(videoId, period); method.

If a range interval syntax is used for the period parameter as 2020/2021 or 2021-01/2021-02 or 2021-W01/2021-W10, then no analytic is returned (when exists in fact), and even an extra error (status: 500) / message is printed on a console, like below.

If the range interval syntax is used for the period parameter as 2021-02-10/2021-02-13, then no analytic is returned (when exists in fact), but the extra error message doesn’t show on a console.

If the range interval syntax is not used, and the period is an exact year, year-month, year-week, year-month-day, then the method works as expected.

PS: The GET URL shows that query params currentPage=1&pageSize=100 are sent to a server by default. It’s unclear because the official API docs of client.analyticsVideo.get(videoId, period); doesn’t mention any possibilities for passing of currentPage or pageSize.

GET https://sandbox.api.video/analytics/videos/vi1YR8HyNZZu2qkS9ASxhWRi?currentPage=1&pageSize=100&period=2021-W01%2F2021-W10
Headers: {
  'user-agent': 'api.video SDK (nodejs; v:1.9.8)',
  accept: 'application/json',
  authorization: 'Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6IjZhN.........mXxcl5X59h5u5R8bw',
  'accept-encoding': 'gzip, deflate, br'
}
Response:
Headers: {
  server: 'nginx',
  'content-type': 'application/problem+json',
  'transfer-encoding': 'chunked',
  connection: 'close',
  'cache-control': 'no-cache, private',
  date: 'Sat, 13 Feb 2021 15:16:08 GMT',
  'api-version': '1.0',
  'x-whom': 'ovh-gra-api-web-app-001-api',
  'timing-allow-origin': '*',
  'access-control-allow-origin': '*',
  'access-control-expose-headers': 'Content-Length,Content-Range'
}
Body: {
  status: 500,
  type: 'https://docs.api.video/5.1/problems/internal_server_error',
  title: 'A server error occurred.',
  name: ''
}

Can you look at it?

Milos

Milos,

Since the period parameter will end up as a URL param - can you try URL encoding it, and seeing if you still get a 500 error?

Doug

Doug,

I tried it, but the result is exactly the same (error 500: A server error occurred). So it looks that the server-side doesn’t understand the encoded separator = doesn’t do the decoding first probably.

Milos

Milos,

I just gave it a go:

client = new apiVideo.Client({ apiKey: apiVideoKey});	
	let result =client.analyticsVideo.get('vi4blUQJFrYWbaG44NChkH27','2021-02-01/2021-02-10');
	
	result.then(function(video) {
		console.log(video);
	});

and I got a response:

AnalyticVideo {
  videoId: 'vi4blUQJFrYWbaG44NChkH27',
  title: null,
  metadata: [],
  period: '2021-02-01/2021-02-10',
  data: [
    AnalyticData {
      session: [AnalyticSession],
      location: [AnalyticLocation],
      referer: [AnalyticReferer],
      device: [AnalyticDevice],
      os: [AnalyticOs],
      client: [AnalyticClient]
    },
<snip>

are you sending the dates as a string? For pagination - currently our SDKs do not support the pagination - but this is in our backlog to improve.

Doug,

no, it’s not possible (as you can see in the GET query string in fact). It’s definitely a string. But I tried it again with the following trivial code, using a pure promise. My real code uses async/await syntax. There has to be something else that affects the operation. Do you think it’s possible to trace what is happening on your server-side when I make that call? We can even use for that test the same videoId: vi7FCJsMrLQ6HvQG3bGkaEo.

let result = this.client.analyticsVideo.get(videoId, '2020/2021');
result.then(function(video) {
   console.log('... 2020/2021:', video);
});

but the result is still the 500 error:

GET https://sandbox.api.video/analytics/videos/vi7FCJsMrLQ6HvQG3bGkaEo?currentPage=1&pageSize=100&period=2020%2F2021
Headers: {
  'user-agent': 'api.video SDK (nodejs; v:1.9.8)',
  accept: 'application/json',
  authorization: 'Bearer eyJ0eXAiOiJKV1QiLCJhbGc...................rZ7IqN0caIT5BIz9fkKME8VPvNQ',
  'accept-encoding': 'gzip, deflate, br'
}
Response:
Headers: {
  server: 'nginx',
  'content-type': 'application/problem+json',
  'transfer-encoding': 'chunked',
  connection: 'close',
  'cache-control': 'no-cache, private',
  date: 'Wed, 17 Feb 2021 14:36:05 GMT',
  'api-version': '1.0',
  'x-whom': 'ovh-gra-api-web-app-001-api',
  'timing-allow-origin': '*',
  'access-control-allow-origin': '*',
  'access-control-expose-headers': 'Content-Length,Content-Range'
}
Body: {
  status: 500,
  type: 'https://docs.api.video/docs/internal_server_error',
  title: 'A server error occurred.',
  name: ''
}

When used the same video without interval period, like:

let result = this.client.analyticsVideo.get(videoId, '2021');
result.then(function(video) {
   console.log('... 2021:', video);
});
... 2021: AnalyticVideo {
  videoId: 'vi7FCJsMrLQ6HvQG3bGkaEo',
  title: null,
  metadata: [],
  period: '2021',
  data: [
    AnalyticData {
      session: [AnalyticSession],
      location: [AnalyticLocation],
      referer: [AnalyticReferer],
      device: [AnalyticDevice],
      os: [AnalyticOs],
      client: [AnalyticClient]
    },
    AnalyticData {
      session: [AnalyticSession],
      location: [AnalyticLocation],
      referer: [AnalyticReferer],
      device: [AnalyticDevice],
      os: [AnalyticOs],
      client: [AnalyticClient]
    }
  ]
}

Milos

Ok, I can replicate what you are seeing.

If I am to read the docs literally:

Period must have one of the following formats:

*For a day : 2018-01-01,
*For a week: 2018-W01,
*For a month: 2018-01
*For a year: 2018

For a range period:

*Date range: 2018-01-01/2018-01-15

You have to use YYYY-MM-DD/YYYY-MM-DD for the range, and the other periods (YYYY/YYYY, etc) do not work.

In my tests, I can verify: 2020-01-01/2021-01-01 works, but other period ranges fail in the same way as you have seen.

Thank you for pointing this out, and I’ll edit the docs to make them clearer.

Doug

Doug,

remember to update also docs (I used originally as the source of possible syntax) on:

Milos

Doug,

now it’s a bit clearer. The previously described case (the beginning of this issue) was the example, where I used 2021-02-10/2021-02-13 as the interval period and reported that NO ANALYTICS was returned (but expected, because of the real existence) and also NO 500 error.

Now I tried again the same case (as you did successfully also) and found out that in this specific case, there is another factor on the table, and this is the fact, that if the required interval period is for example:

period: '2021-02-14/2021-02-17'

an when the analytics and events are recorded on 2021-02-17', then NO ANALYTICS is returned. But when the interval period is set as period: '2021-02-14/2021-02-18' for the same data, the correct result set is returned.

So this is the explanation of my initial wrong understanding of the real source of problems. It was not the separator between days (while it was a wrong syntax mentioned in the docs for years and weeks), but the fact, that when the interval days period is used, then no data for the ending date is included. This is a bug, I suppose because it’s not possible to expect such a behavior. The actual behavior can be expressed like period: '2021-02-14/2021-02-17T00:00:00' if time could be used, which is not possible.

AnalyticData {
    session: AnalyticSession {
      sessionId: 'ps28lasFUdyzQ0D4nCOsiVzr',
      loadedAt: 2021-02-17T16:18:31.000Z,
      endedAt: 2021-02-17T16:18:55.000Z,
      metadata: [Array]
    }
  },
AnalyticData {
    session: AnalyticSession {
      sessionId: 'ps7XPGw4a7TSwEly3C3wv2KA',
      loadedAt: 2021-02-17T16:22:39.000Z,
      endedAt: 2021-02-17T16:22:59.000Z,
      metadata: [Array]
    }
AnalyticSessionEvent {
  session: AnalyticSession {
    sessionId: 'ps28lasFUdyzQ0D4nCOsiVzr',
    loadedAt: null,
    endedAt: null
  },
  resource: AnalyticResource { type: null, id: null },
  events: [
    AnalyticEvent {
      type: 'ready',
      emittedAt: 2021-02-17T16:18:31.000Z,
      at: 0,
      from: null,
      to: null
    },
    AnalyticEvent {
      type: 'play',
      emittedAt: 2021-02-17T16:18:34.000Z,
      at: 0,
      from: null,
      to: null
    },
    AnalyticEvent {
      type: 'pause',
      emittedAt: 2021-02-17T16:18:46.000Z,
      at: 12,
      from: null,
      to: null
    },
    AnalyticEvent {
      type: 'resume',
      emittedAt: 2021-02-17T16:18:48.000Z,
      at: 12,
      from: null,
      to: null
    },
    AnalyticEvent {
      type: 'pause',
      emittedAt: 2021-02-17T16:18:52.000Z,
      at: 67,
      from: null,
      to: null
    },
    AnalyticEvent {
      type: 'seek.forward',
      emittedAt: 2021-02-17T16:18:52.000Z,
      at: null,
      from: 15,
      to: 67
    },
    AnalyticEvent {
      type: 'resume',
      emittedAt: 2021-02-17T16:18:52.000Z,
      at: 67,
      from: null,
      to: null
    },
    AnalyticEvent {
      type: 'end',
      emittedAt: 2021-02-17T16:18:55.000Z,
      at: 70,
      from: null,
      to: null
    }
  ]
}
AnalyticSessionEvent {
  session: AnalyticSession {
    sessionId: 'ps7XPGw4a7TSwEly3C3wv2KA',
    loadedAt: null,
    endedAt: null
  },
  resource: AnalyticResource { type: null, id: null },
  events: [
    AnalyticEvent {
      type: 'ready',
      emittedAt: 2021-02-17T16:22:39.000Z,
      at: 0,
      from: null,
      to: null
    },
    AnalyticEvent {
      type: 'play',
      emittedAt: 2021-02-17T16:22:41.000Z,
      at: 0,
      from: null,
      to: null
    },
    AnalyticEvent {
      type: 'pause',
      emittedAt: 2021-02-17T16:22:59.000Z,
      at: 18,
      from: null,
      to: null
    }
  ]
}

Milos

Hey @mlapis,

@anon89371750 updated the docs on Github and it’s now published on npm as well.

First, I read through this whole thread, and I agree the 500 error isn’t clear enough for an API user.
I posted a ticket asking for a clearer error response from the API, something like 400 “Invalid period parameter”.

As for your 2nd notice, I agree that asking for analytics on 2021-02-14/2021-02-17 period should return analytics of 2021-02-17.
This doesn’t appear to be a NodeJs SDK, rather an issue with the API itself, but still is an issue nonetheless. Thanks for reporting, I’ll submit a ticket regarding this.

1 Like

Thanks for confirming the facts and submitting tickets.

Milos