seek() returning howler object unexpectedly

[matt-way]

If the seek() function is called while audio is loaded, except the play lock is true, it will return the howler object instead of the current time.

howler.js/src/howler.core.js

Line 1579 in 030db91

if (self._state !== 'loaded' || self._playLock) {

[martinratinaud]

This happens to me also

[JetDu0319]

How to deal with this problem

[lamasfoker]

Me too

[soend]

Need help with this also.

[inear]

Same here. Plus, is it useful to add it to the _queue array if the seek call has no arguments? I have a problem where I read the time with seek() each frame to display the time, and the array keeps filling up if playLock is true. No reason to run a seek() later when playLock is false. Could even fix so any seek(time) that exists earlier in the queue for a specific sound is removed to avoid jumping all over the file later.

[inear]

My workaround since long time ago is:

let time = Number(mySound.seek())
if (isNaN(time)) {
  time = mySound._sounds[0]._seek
}

[TrevorHinesley]

Definitely still an issue, but @inear's workaround works great.

[DurinMusicspear]

I also have this issue, took me a while to find out what was happening!

[Rem486]

I had the same problem, especially .wav

[madStitcher]

This is an issue we are running up against as well. Next month this issue will be a year old!

[s16h]

@goldfire, what are your thoughts on this?

[abrehamgezahegn]

Same problem here. I have a feeling that it's somehow related to this issue too. @goldfire can you investigate.

[blmage]

Shouldn't the _playLock flag be considered only when seek is a number?

[fritzfr]

Still an issue...

[andybloch]

Still seems to be an issue. (This plus a couple of other issues make me regret ever using howler.)