I just encountered the same problem in my code. It seems like the “get_activity_stream” changed its default behavior: I am pretty sure that it returned data with the full resolution (i.e. 1 data point per second) the last time I used it (about half a year ago). Now, max.10000 points seems to be the default.
When your activity is longer than 10000 seconds, there will be jumps. 

I now have the problem that i need a vector for the “moving time”. In the past, this was just [1,2,3,4,…,N]. 

Interesting. Thanks for confirming the ~10,000 limit and the gaps.

I’m not sure how this API function can be considered useable now. Large chunks of data -- even sections with movement and power values -- are just missing; I don’t see a way to do anything reliable with the data that’s left.

​@Emily_A Is the team responsible for the API aware of this regression? I can confirm that the api/v3/activities/{id}/streams endpoint returns only a subset of under 10.000 data points per type with irregular gaps in it. In example an activity with a moving time of 12880 seconds formerly returned 

0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20

for the first 21 data points in the time stream. Now the same activity returns

0,2,4,6,7,9,10,12,14,15,16,18,19,20

thus making it more or less unusable for any serious analyzing.

​@Jan_Mantau thanks for the flag. We’re aware and taking a look. 

Hi all, this should be resolved!