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.
For buffering, I believe you could listen to the
canplaythrough to determine if the audio is playable using one of the HTML 5 callback options: https://521dimensions.com/open-source/amplitudejs/docs/configuration/callbacks.html.
Amplitude.getAudio() which you could bind to and run special commands if that works.
Let me know if that helps!
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
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.
Yeah, I see that
Core.reconnectStream() does not invoke
Callbacks.initialize after re-defining of
config.audio so I loose all native html5 callbacks. I still need
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: https://github.com/521dimensions/amplitudejs/issues/451
Thanks @alexeevdev! We have this on our radar and we’ll have this addressed in v5.3