How to handle buffering process

Hi there!
I make a player for a stream so I would like to make the player be able to reflect that it’s buffering the stream now. I don’t see this type of callbacks in the documentation.

1 Like

Hi @alexeevdev,

For buffering, I believe you could listen to the waiting and canplaythrough to determine if the audio is playable using one of the HTML 5 callback options:

AmplitudeJS supports any of the native HTML5 audio element callbacks. It even exposes the actual Javascript representation of the audio element using Amplitude.getAudio() which you could bind to and run special commands if that works.

Let me know if that helps!

Hi @danpastori,

Thank you, it works indeed!

I’ve got one more question. How do I drop the buffer after pause? If a user press “pause” and then they press “play” again they expect to listen actual stream but not the buffered stream. Or maybe it’d better to move the progress to 100% or 99%, what do you think?

Ok, I see that if I add live: true to song params it automatically reconnects to a stream on play() but I lose all callbacks then :smiley:

Hi @alexeevdev

Definitely use live for re-connecting to the live stream after play/pause. It’s also good if you are live streaming to save on memory that way.

As for losing the callbacks, which ones are you losing? Some of the native HTML5 callbacks wouldn’t trigger on a live stream. I can take a look and see what the issue is.

Hi @danpastori
Yeah, I see that Core.reconnectStream() does not invoke Callbacks.initialize after re-defining of so I loose all native html5 callbacks. I still need waiting and playing callbacks which are native html5 callbacks.

Ah @alexeevdev you are right! I need to fix that in the upcoming release. We tried to optimize memory and this is one place we need to do that as well. Thanks for pointing that out. I’ll create an issue to track the progress and hopefully get an update pushed soon.

Thanks! I’ve checked that the issue still doesn’t exist so I’ve created the issue not to forget that:

1 Like

Thanks @alexeevdev! We have this on our radar and we’ll have this addressed in v5.3 :+1: