starred/librespot

Fork 0

mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 08:15:50 +03:00

[GH-ISSUE #310] Time offset in playback position #207

New issue

Closed

opened 2026-02-27 19:29:24 +03:00 by kerem · 8 comments

kerem commented

2026-02-27 19:29:24 +03:00

Owner

Originally created by @D54 on GitHub (Mar 17, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/310

The connect-client's playback position is approximately 50s behind the real one.
So when the playback is at 3m 0s, the player shows 2:10.
When the playback is paused, the offset is gone.

Additional symptoms:

When the client gets negative position, it shows the seekbar and time as the track would be ending right now (position = duration) until the end of the current song.
Songs end when the seekbar shows 50s remaining.

Librespot version: ef28df6
built with: --no-default-features --features alsa-backend --release
Client version:
1.0.98.78 (Linux)
Webclient is also affected.

Originally created by @D54 on GitHub (Mar 17, 2019). Original GitHub issue: https://github.com/librespot-org/librespot/issues/310 The connect-client's playback position is approximately 50s behind the real one. So when the playback is at 3m 0s, the player shows 2:10. When the playback is paused, the offset is gone. Additional symptoms: - When the client gets negative position, it shows the seekbar and time as the track would be ending right now (position = duration) until the end of the current song. - Songs end when the seekbar shows 50s remaining. **Librespot version**: ef28df6 built with: `--no-default-features --features alsa-backend --release` **Client version:** 1.0.98.78 (Linux) Webclient is also affected.

kerem closed this issue

2026-02-27 19:29:24 +03:00

kerem commented

2026-02-27 19:29:25 +03:00

Author

Owner

@devgianlu commented on GitHub (Mar 17, 2019):

Check that your device time is aligned with any NTP server.

@sashahilton00 and I discovered recently that it could be a problem.

@devgianlu commented on GitHub (Mar 17, 2019): Check that your device time is aligned with any NTP server. @sashahilton00 and I discovered recently that it could be a problem.

kerem commented

2026-02-27 19:29:25 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Mar 17, 2019):

@devgianlu there is almost certainly some time sync going on between clients. I found a core.clock_delta variable earlier in the client, I imagine they are keeping time synced across instances.

@sashahilton00 commented on GitHub (Mar 17, 2019): @devgianlu there is almost certainly some time sync going on between clients. I found a `core.clock_delta` variable earlier in the client, I imagine they are keeping time synced across instances.

kerem commented

2026-02-27 19:29:25 +03:00

Author

Owner

@devgianlu commented on GitHub (Mar 17, 2019):

That makes sense since the original client isn't effected by this issue, but I think that synchronizing with an NTP server by shifting the system time is enough for our purpose.

Implementing it in librespot shouldn't be very difficult as it's already relaying on custom function to get the time.

@devgianlu commented on GitHub (Mar 17, 2019): That makes sense since the original client isn't effected by this issue, but I think that synchronizing with an NTP server by shifting the system time is enough for our purpose. Implementing it in `librespot` shouldn't be very difficult as it's already relaying on [custom function](https://github.com/librespot-org/librespot/blob/ef28df63018eeb4bae6bb8ea5d4eb14ed36a962a/connect/src/spirc.rs#L60) to get the time.

kerem commented

2026-02-27 19:29:25 +03:00

Author

Owner

@plietar commented on GitHub (Mar 17, 2019):

Packet 0x4 (https://github.com/librespot-org/librespot/blob/master/core/src/session.rs#L170) contains a timestamp as the payload.
Client replies with a 0x49 packet, and finally the server sends a 0x4a back.

I suspect this sequence of packets is used for time synchronization

@plietar commented on GitHub (Mar 17, 2019): Packet 0x4 (https://github.com/librespot-org/librespot/blob/master/core/src/session.rs#L170) contains a timestamp as the payload. Client replies with a 0x49 packet, and finally the server sends a 0x4a back. I suspect this sequence of packets is used for time synchronization

kerem commented

2026-02-27 19:29:25 +03:00

Author

Owner

@devgianlu commented on GitHub (Mar 17, 2019):

The Ping (0x4) packet seems to have the server timestamp as a payload. PongAck (0x4a) will reply with anything that is sent with Pong (0x49).

~~So I guess the server timestamp can be used to synchronize the client.~~ You can indeed synchronize the client using the timestamp provided with Ping (0x4). (github.com/librespot-org/librespot-java@e105815931)

@devgianlu commented on GitHub (Mar 17, 2019): The `Ping (0x4)` packet seems to have the server timestamp as a payload. `PongAck (0x4a)` will reply with anything that is sent with `Pong (0x49)`. <s>So I guess the server timestamp can be used to synchronize the client.</s> You can indeed synchronize the client using the timestamp provided with `Ping (0x4)`. (https://github.com/librespot-org/librespot-java/commit/e105815931b2b0fafe3f06407a47d79ce17a5aac)

kerem commented

2026-02-27 19:29:25 +03:00

Author

Owner

@D54 commented on GitHub (Mar 23, 2019):

I can confirm time-synchronization solved the problem, but I think this is not the optimal solution.
There should be some info about this requirement until the official protocol is implemented.
Anyway, thanks for the help and the possible future implementation!

@D54 commented on GitHub (Mar 23, 2019): I can confirm time-synchronization solved the problem, but I think this is not the optimal solution. There should be some info about this requirement until the official protocol is implemented. Anyway, thanks for the help and the possible future implementation!

kerem commented

2026-02-27 19:29:25 +03:00

Author

Owner

@mfeif commented on GitHub (Mar 23, 2019):

It doesn't seem to be the same behavior, though it could be the same bug. For example, my clients don't stop paying before the song ends, or based on erroneous UI settings.

But I dug in and looked into the clocks...

The device and my laptop (where the clients are) were within 1 second of one another; close enough that I can't tell without running some kind of sync script between them. When I sync'd them both to the same ntp server, one was off by -0.011 seconds, the other by +0.041 ... so a total mismatch of 5 one hundredths of a second. Neither was off from "real" time (where presumably the spotify servers live) by even that much.

The device also does an ntp sync every day, at midnight or some such, so a manual force shouldn't be required.

But indeed, forcing a resync to ntp on the device where librespot was playing, then killing librespot and starting again did make these problems go away.

Seems like 0.05s is a little tight for tolerance :-[

@mfeif commented on GitHub (Mar 23, 2019): It doesn't seem to be the same behavior, though it could be the same bug. For example, my clients don't stop paying before the song ends, or based on erroneous UI settings. But I dug in and looked into the clocks... The device and my laptop (where the clients are) were within 1 second of one another; close enough that I can't tell without running some kind of sync script between them. When I sync'd them both to the same ntp server, one was off by -0.011 seconds, the other by +0.041 ... so a total mismatch of 5 one hundredths of a second. Neither was off from "real" time (where presumably the spotify servers live) by even that much. The device also does an ntp sync every day, at midnight or some such, so a manual force shouldn't be required. But indeed, forcing a resync to ntp on the device where librespot was playing, then killing librespot and starting again did make these problems go away. Seems like 0.05s is a little tight for tolerance :-[

kerem commented

2026-02-27 19:29:25 +03:00

Author

Owner

@sashahilton00 commented on GitHub (Mar 25, 2019):

#321 should fix this.

@sashahilton00 commented on GitHub (Mar 25, 2019): #321 should fix this.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/librespot#207

No description provided.

Rows
Columns