mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #157] Played song in mobile client not updated #109
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#109
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 @kaibenn on GitHub (Feb 18, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/157
I played around a while with librespotd on kodi and with the current state on my linux machine. It is great stuff, but still one question. If I control it from my mobile the songs displayed on the mobile are fast out of sync with the actually played ones. E.g. start one song from an album, choose librespotd for audio output, than choose another song (from another album). The other song is playing, but the old song/album is still shown on the mobile. Jumping to the next song, the next song from the other album is playing, but the mobile is displaying the next song from the first album. Am I doing something wrong or is this as it is currently?
@kaibenn commented on GitHub (Feb 18, 2018):
It seems not to be dependent on where the songs are from. The currently playing song in the client app is just not updated.
After I saw this behaviour on kodi/android, I confirmed it on linux pc/android
The android mobile is a quite recent one, the w-lan router was 1m away, so network should not be the problem.
Another test. Started on the Linux PC librespotd and the original Spotify application, angain Android mobile as client. The connection works fine if I choose the original Spotify application as the target. Choosing librespotd again as the target, I have the problem again.
@kingosticks commented on GitHub (Feb 18, 2018):
Are these two albums within the same playlist or two totally different albums? Please provide the exact steps to reproduce this.
Also we need the versions of both the android client (it's under settings) and librespot.
@kaibenn commented on GitHub (Feb 18, 2018):
./target/release/librespot -cache ~/tmp --name librespot
It seems to work instead, if I always pause the currently playing song, before selecting another one from the library.
@kaibenn commented on GitHub (Feb 18, 2018):
Spotify client version (Android) 8.4.39.673
@kingosticks commented on GitHub (Feb 18, 2018):
Yep OK I now have the same version of the Spotify client as you and I can reproduce this. I've tried older versions of librespot that definitely used to work properly in regards to this but they all now behave like this. So it looks like Spotify changed something and the official clients are no longer picking up the librespot status messages. I guess it might be interesting to see how old Connect hardware behaves with this these updated clients.
@kaibenn commented on GitHub (Feb 18, 2018):
Thank you for your investigations. Do you know a version number still working?
@kingosticks commented on GitHub (Feb 18, 2018):
No, I can't find a working one anymore
@kingosticks commented on GitHub (Feb 18, 2018):
OK, now I am really confused, I restarted my phone and it's now started working properly again.... (with the latest code)
@bebehei commented on GitHub (Feb 22, 2018):
@kingosticks The fix you have pushed in your recent PR (#156) does fix this issue. I had the same problem, but now after recompiling it, it's gone.
@kingosticks commented on GitHub (Feb 22, 2018):
There is no fix in that PR for this. I'd say it's more likely the recompiling that's fixed it.
@kingosticks commented on GitHub (Feb 22, 2018):
And hopefully we can close this now.
@bebehei commented on GitHub (Feb 22, 2018):
I bet, this is the fixing line: https://github.com/librespot-org/librespot/pull/156/files#diff-fb4606287b6e129f05bf85e440522421R635
That's mainly what's missing. Spotify never knew, in which playlist the current song had been located. But, it knew, which song had been playing.
This resulted also in the mobile app, not updating the tracks, because the mobile view actually does not show the current track. In fact it's showing you the current track of the playlist in context.
This resulted in weird issues like this: On your laptop client, you play
TRACK1, then open the Android APP, there it showsTRACK1. Then you skip toTRACK2on the computer.TRACK2will play, but on Android it still showsTRACK1.And on the mobile, the really weird behavior starts here: If you go on and skip to a certain timepoint on Android e.g.
TRACK1_01:00, it'll actually play thenTRACK2_01:00, if you've already skipped toTRACK2on another device.Recompiling doesn't fix anything. Of course, I pulled from
4f3a594to685fb4ebefore recompiling.@sashahilton00 commented on GitHub (Feb 22, 2018):
@bebehei I just tried to reproduce that wierd behaviour on my devices, but was unable to reproduce. I also tried with an iOS device, with Android and OS X app open, and was similarly unable to reproduce. Have you tried resetting to the master HEAD, deleting the
target/folder and recompiling?@kaibenn commented on GitHub (Feb 22, 2018):
I can confirm that this issue is fixed, now. After updating my repository and rebuilding it worked as expected. Additionally switching between and older build and this one confirms it (old one has the issue, new build don't).
Thank you!
I think I should close it now.
@kingosticks commented on GitHub (Feb 22, 2018):
For my own sanity I just tried again. I do not see this issue on
github.com/librespot-org/librespot@3ce22113cfwith a clean build (i.e. before my unrelated PR was merged ingithub.com/librespot-org/librespot@685fb4e345). Whatever the problem was, it's nothing to do with setting thecontext_uristate.@michaelherger commented on GitHub (Feb 23, 2018):
I've had reports of users claiming that they started to see this or a similar issue suddenly one day after updating their Android app. But not right after the update, only a few additional days later. Reverting to an older app version "fixed" it. IMHO this looks like a temporary issue on Spotify's end. Like they changed a few things in the app as well as the back-end which caused problems. And at some point they figured it out and fixed the server side again.
@kaibenn commented on GitHub (Feb 23, 2018):
If it has nothing to with the latest changes, it must be some kind of side effect, or dependent on the build.
I overwrote my previous build on compiling anew. But I checked it with an earlier build from plietars repository. With the same spotify app. With the old one I have this issue immediately and it did not occur with the new one so far.
I will inform you, if the issue reapears in the future.
@sashahilton00 commented on GitHub (Feb 23, 2018):
How odd. Anyway, looks like it's quashed for now.
@kaibenn commented on GitHub (Feb 24, 2018):
With the build from @awiouy the problem is solved now on my Wetek Play2 (Kodi,LibreElec) as well
@TonioRoffo commented on GitHub (Feb 25, 2018):
I've tried a Panasonic All-1C versus the mentioned spotify client and higher - same problem. A lot of customers will be unhappy!