bielfrontera
commented
1 year ago Thanks @gwaihir8!! I understand the problem, and it will fix some scenarios.
But if we want to be precise, the buffer should be the minimum among the desired buffer size and the number of available indexes ahead of the player (that its more complex to compute, as it depends on steps, loop and upper and lower limit options).
I think that another option could be to change the method getNumberNextTimesReady. It's neither precise, as I'm checking right now. In some cases, it does not return the number of next times ready (as its name says). Instead, it returns the howmany parameter, as it finds that it has arrived to the end of the loop (to the upperLimit or to the lowerLimit). But if loop option is true, it does not check if it has done a full loop (the method prepareNextTimes has this check).
Could you try if adding the check of arriving to the same initial index at getNumberNextTimesReady solves the problem?
I'm not comfortable that it returns an unprecise value, and it could be converted return a boolean to get if all the desired next times are ready... but we need the number to show the percentage of loading when waiting.
…ble times
I hit a small bug when the configured buffer size was larger then length of the actual available times array. Some times when preloading the steps, the plugin keeps on firing the "waiting" event. Setting a Math.min on the buffer size , comparing with the _getMaxIndex() should fix it.