Shaka-player: buffering event not triggered with throttled

[mdownplane]

• What version of Shaka Player are you using?
  2.0.0
  
  
  
  • Can you reproduce the issue with our latest release version?
    
    yes
  
  
  • Can you reproduce the issue with the latest code from master?
    
    yes
  
  
• Are you using the demo app or your own custom app?
  demo
  
  
  
  • If custom app, can you reproduce the issue using our demo app?
  
  
• What did you do?
  Repro steps:
• Find yourself a nice long video and hit play
• Open developer tools in chrome
• Go to networking tab and throttle down to GPRS
  
  
  
  • What content did you load?
  
  
  • If standard demo asset, which one?
    
    Sintel 4k
  
  
  • If custom asset, what manifest and license server URIs?
  
  
  • How did you interact with the content, if at all?
    
    Play, then throttle network
  
  
• What did you expect to happen?
  Buffering animation should display. Playback should resume when throttle is removed
• What actually happened?
  Result:
• Video will stop playing but buffering event will not be triggered. Playback does not always resume when removing throttle

[ismena]

Hi Michael, thanks for reporting.
Here's what's happening there: playback starts at high speed and then we significantly drop it by throttling the network. The player checks if it has content buffered and at that point it does, so it proceeds to fetch a new segment. A request for video starts, but takes a long time to finish because the network is slow. While the request is in that state, we run of of buffered video content, but not of audio/text which got buffered earlier when the network was faster (since they're more lightweight).
The request for video is eventually finished and buffering event gets invoked.

The reason I'm boring you with two days of my investigative work is to say that this scenario is caused by a significant drop of network speed and thus is fairly artificial and not very likely to happen in real world. (If you enter throttling mode before loading the video, there won't be a delay in the buffering state).

That being said, current behavior is definitely a bug on our part, and we'll put it on road map for fixing.

Thanks again, let me know if you have any questions!
-Sandra

[Feenposhleen]

Just wanted to say that this is an issue for us as well. If the video freezes during playback because it lacks data, then a "buffering" event should be emitted immediately. Any other behaviour seems sketchy. For us the main problem is to be able to track buffering times that our customers have. For this we want precision that is not possible if the the event emissions are offset by the time it takes to resolve the final segment.

I would consider this to be a fairly major issue.

[joeyparrish]

Understood. It's a design flaw we didn't spot before it was reported, and we have been working on a fix ever since. We will release an update as soon as a well-tested fix is available.

[ismena]

@mdownplane @Feenposhleen
I just pushed a fix that changes our approach to buffering and should resolve any issues related to not triggering the buffering event.

Please let us know how that works for you and thanks again for reporting.