Playing a song from non-zero starting position

Question

Created Mar ’21

Replies 2

Boosts 0

Views 1.7k

Participants 4

Summary

I am trying to play a song starting at a non-zero starting position. For example, I would like to play a song starting at 10 seconds instead of at 0 seconds.

Approach

setQueue
play
seekToTime

Code Block let music = window.MusicKit.getInstance();
// 1: setQueue
music.setQueue({ song: "validSongID" })
  .then(() => {
    // 2: play
    music.player.play()
      .then(() => {
        // 3: seekToTime
        const position = 10;
        music.player.seekToTime(position);
      });
  });

Expected results

The song should start playing at 10 seconds.

Actual results

~4 out of every 5 times it works as expected.

~1 out of every 5 times I get the following error:

Code Block Uncaught (in promise) TypeError: Failed to execute 'remove' on 'SourceBuffer': The end value provided (0) must be greater than the start value provided (0).

See also the full error log attached:

Error log

Further Impact

The error that is being thrown does not create an mediaPlaybackError event, so I can't even handle the error properly in my application logic.

Answer 1

t3dotgg OP

Apr ’21

I suffered with this one for awhile and managed to make a custom seek helper that works by waiting for the currentBufferedProgress to be far enough to safely seek. Sadly it seems like MusicKit crashes outright if you haven't buffered enough pre-seek. (also notable this happened a lot more for our non-US users, I had to use a VPN in Belgium to replicate reliably)

I would kill for a proper play(time: number) option to start playback at a specific timestamp. This solution provides a pretty rough UX since all of the track data before your timestamp has to load as well

I would hate for my suffering to go to waste, so here's our solution over at TTFM. Note that it is ugly and relies on playing while muted to force buffering:

https://github.com/TTFM-Labs/public/issues/1#issuecomment-812764697

Answer 2

weijiezhao OP

Nov ’22

As I tested, check the MusicKit.getInstance().player.currentBufferedProgress is not safe enough.

The seekToTime function provided by MusicKit is not safe in case of concurrency. The safest way is to modify MusicKit.getInstance().player._currentPlayer.audio.currentTime directly. Don't use seekToTime!