mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #54] Last ~10 seconds of each track not played #43
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#43
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sashahilton00 on GitHub (Jan 29, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/54
Tuesday Apr 18, 2017 at 16:59 GMT
Originally opened as https://github.com/plietar/librespot/issues/175
Right before the end of each track, the controlling device is sending Load command which makes the player jump right to the next track without waiting for the current track to finish. This happens when controlling from both Android and Windows.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Thursday Apr 20, 2017 at 11:10 GMT
Looks like the issue is caused by librespot sending Notify response without waiting for the track to Load. It is less noticable when the track is already cached.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Friday May 12, 2017 at 05:29 GMT
@jsopenrb - have you found a solution to this issue?
@sashahilton00 commented on GitHub (Jan 29, 2018):
Friday May 12, 2017 at 06:21 GMT
@michaelherger, no yet and I'm not sure where to look as well. I thought it might be caused by rpi3 not having an exact 44.1 clock, but for 5 minute track the time difference is less than 0.5 seconds. I need to check again, but I think this was working normally under x86 VM.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Friday May 12, 2017 at 07:13 GMT
I think it depends on the backend, rather than the platform. My guess is that as soon as librespot has finished receiving a track, it tells the controller "done". Which triggers the controller to start playback of the next song.
Eg. I used the stdio backend to pipe all data to a file. It only takes about 10-15s to complete the download of a single track. Therefore the Spotify application would jumpt to the next track after only this duration. The effect is less obvious of course if you're using a backend with a smaller buffer. The file to which I've piped the output would have the full track, though.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Friday May 12, 2017 at 07:48 GMT
Yes, there's also an end_of_track event which notifies Spotify that track has finished playing, but in my case it's not triggered, the server sends Load command before end_of_track happens.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Thursday May 25, 2017 at 07:16 GMT
From what I can tell from spirc communication - Windows client sends two notification events: one to ack the load command, another when loading is complete. I've added an additional track_loaded event, but I'm still not 100% sure that it is needed.
The thing that helped was to set custom period and buffer settings in Alsa backend setup (it also helped with massive lag of skip commands). This leads to requirement of a config file instead of command line options so backends and mixers can have their own specific configuration options.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Tuesday Jun 13, 2017 at 10:14 GMT
@jsopenrb - did you adjust the buffer size in Alsa itself, or in librespot's Alsa backend?
@sashahilton00 commented on GitHub (Jan 29, 2018):
Tuesday Jun 13, 2017 at 11:10 GMT
@michaelherger, I've made changes in alsa backend. It's not compatible with current librespot version as I'm using alsa-sys crate which has required functions to implement hardware volume control.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Thursday Jun 15, 2017 at 15:44 GMT
Ok, I've tried to better understand what is going on here. Here are two log snippets I collected. The first one is of a session where I let the tracks play without interaction:
After the kMessageTypePlay message we'd get no other message from Spirc. Yet the player would switch to the next track as soon as the first one had been fully loaded. As I piped the output to /dev/null, this happened within seconds.
The second log is from when I pressed the Next button in the controlling Spotify app on my phone:
Now this one's different. We would get a kMessageTypeNext message before the player loads the new track. In this case it's ok that the player does stop playback of the currently playing track, and start playback of the new one.
I was wondering whether it would be possible to modify the player to only end playback if there had been a spirc event. Otherwise just let the track end before starting playback of the new one?
@ComlOnline commented on GitHub (Jan 29, 2018):
@jsopenrb @michaelherger is this still an issue? Was any progress made?
@ComlOnline commented on GitHub (Feb 5, 2018):
As there are no other reports of this and there is no one with the bug to troubleshoot with, I'm closing this issue/ Feel free to open a new one if its still there.