"end" event never fired when playing a stream

[tbessie]

When I'm playing a stream, the "end" event is never fired:

var player = new $wnd.Howl({
    src: url,
    html5: true, // A live stream can only be played through HTML5 Audio.
    format: ['webm', 'opus', 'mp3', 'aac'],
    autoplay: false
});

player.on('end', function(id) {
    console.log('ended!');
});

player.play();

I never get the "end" event. The URL provided points to a servlet on my server; the servlet is properly closing the output stream when it's done streaming content, so Howler should be noticing the stream has been closed.

[tbessie]

I found out what the issue is; if the file (webm/opus in this case) doesn't contain any duration information, I never get the "end" event. If it does, I do.

This leads me to believe that Howler is using the duration information in the audio file header to determine when the audio ends, as opposed to when it reaches the end of file/buffers. This isn't the best way of determining this - Howler should notice when there is no more data to stream (socket is closed, for instance, or last buffer is played) in order to know when the playback has ended, instead of using a timer set to the duration that the file SAYS it is.

Any chance you can fix this? It's a bit tricky to do, from what I've found - I was trying to do this myself, by allocating a set of buffers as the data is streamed, and then decoding them one at a time whenever a given buffer is done playing, and directing the browser to play the next buffer, until the last buffer is done. It's non-trival to do this, so I can understand why this wasn't done in Howler. However, it seems to me to be a better method rather than depending on the duration in the audio file header.

What do you think, @goldfire ?

[tbessie]

Just curious, but why did you close this one? There were two tickets – one with getting 2 “play” events, and this one with never getting a “close” event on a stream without a duration in its header. You didn’t make any comments on this ticket, but just closed it – what’s that about?

[goldfire]

@tbessie This was closed automatically because I marked it was fixed in commit 51508c8.

[tbessie]

Ah, thanks for explaining. I didn't realize you'd fixed it.

[goldfire]

It may not handle your specific scenario, so let me know if you are still seeing the issue and I'll reopen.