Open ghost opened 9 years ago
This can happen if you are consuming the audio data from the stream faster than you should be.. Do you have any example code where this is happening?
@IainCole Here's a gist of what I'm doing. I'm piping this out to a response. https://gist.github.com/sciencepro/4481545fe5099b363ef3
So you are returning audio data to some web app then playing it? I think what's happening is the audio data is being returned to the app effectively as fast as it can encode/download, so you're getting the track-end message when it's finished being downloaded rather than being played.
Ah, that makes sense. That's what I'm trying to do. Any suggestions on how I can control this better? Thanks for your help.
Depends how you're playing it and what you're using the track-end message for. I think it would have to be handled in the app, perhaps by buffering the audio data and checking when it's empty or something.
Hi @Floby - awesome work on this project, it's perfect for what I'm doing. I know you haven't touched this in a long while, but I was wondering if you had any thoughts on what might cause the
track-end
event to be sent early, before the track has played all the way through. From how I understand it, this comes directly fromsp_session_callbacks::end_of_track
in libspotify. I suppose there could be a bug in libspotify, but it happens probably around a third of the time in my experience.