Announcements

Help Wizard

Step 1

NEXT STEP

IFrame API truncates milliseconds when using seek()

IFrame API truncates milliseconds when using seek()

Plan

Premium

Country

United States

Device

2023 Macbook Pro

Operating System

MacOS 26.3.1

 

My Question or Issue

 

We use the Spotify Embed to play podcasts alongside synchronized, timestamped transcripts. Our sync data has millisecond precision (e.g., a lyric line starting at 56.773s). When a user clicks a sentence to jump to that point in the podcast, we call seek(56.773), but the player jumps to 56.000 instead — nearly 800ms too early.                                                                                                

This causes the playback cursor to land in the middle of the previous line's words, resulting in cut-off audio and a confusing experience for users trying to follow along.

 

The EmbedController.seek(seconds) method currently only accepts an integer parameter, truncating any sub-second precision. This makes it impossible to seek to a specific millisecond offset within a track.

 

The current 1-second granularity is too coarse for any transcript use case. This is a fully completely artificial limitation—the internal APIs accept milliseconds parameters, and there's no reason that the seek(seconds) method can't accept a floating-point parameter. Even 100ms precision would be a significant improvement. 

 

This is caused by using "parseInt(event.data?.timestamp, 10)" when handling the timestamp data. This can be fixed very easily by changing the `SEEK` handler to use `Number` instead when handling the message from the iFrame API.

 

```js

case MessageType.SEEK: {
  // previously: 
  const timestamp = Number(event.data?.timestamp);
  const timestampMs = 1000 * timestamp;
  dispatch(seek(timestampMs * 1000));
  ...
}
```
Reply
1 Reply

Hi there,

​This is a very solid technical analysis. You are correct that one second precision is not enough for synced transcripts.

​The issue with the seek method ignoring milliseconds is a known pain point for many developers. Since the internal system already uses milliseconds, it would make sense for the controller to support floating point numbers instead of rounding them down.

​Because you found the specific logic issue, you should definitely report this in the official Spotify Developer Issue Tracker. High quality reports like yours are the ones that actually get fixed by the engineering team.

​In the meantime, is it possible for you to use the Web Playback SDK instead of the Embed for your project? That might give you the precision you need.

Suggested posts

Let's introduce ourselves!

Hey there you,   Yeah, you! 😁   Welcome - we're glad you joined the Spotify Community!   While you here, let's have a fun game and get…

ModeratorStaff / Moderator/ 4 years ago  in Social & Random