Played song in mobile client not updated

[kaibenn]

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]

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]

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]

1. Start librespot on Linux PC (build from yesterday cloned GitHub repository)
   ./target/release/librespot -cache ~/tmp --name librespot
2. Start Spotify App on Android mobile (Oneplus 3)
3. Select one song from an album of my Spotify library
4. Press play
5. Select librespot as Spotify client. Song is played on librespot, Android app shows song. OK
6. While the song is playing, choose another song from my library
7. librespot plays the other song, Android app shows still the previous song WRONG

It seems to work instead, if I always pause the currently playing song, before selecting another one from the library.

[kaibenn]

Spotify client version (Android) 8.4.39.673

[kingosticks]

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]

Thank you for your investigations. Do you know a version number still working?

[kingosticks]

No, I can't find a working one anymore

[kingosticks]

OK, now I am really confused, I restarted my phone and it's now started working properly again.... (with the latest code)

[bebehei]

@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]

There is no fix in that PR for this. I'd say it's more likely the recompiling that's fixed it.

[kingosticks]

And hopefully we can close this now.

[bebehei]

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 shows TRACK1. Then you skip to TRACK2 on the computer. TRACK2 will play, but on Android it still shows TRACK1.

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 then TRACK2_01:00, if you've already skipped to TRACK2 on another device.

---

more likely the recompiling that's fixed it.

Recompiling doesn't fix anything. Of course, I pulled from 4f3a594 to 685fb4e before recompiling.

[sashahilton00]

@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]

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]

For my own sanity I just tried again. I do not see this issue on 3ce2211 with a clean build (i.e. before my unrelated PR was merged in 685fb4e). Whatever the problem was, it's nothing to do with setting the context_uri state.

[michaelherger]

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]

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]

How odd. Anyway, looks like it's quashed for now.

[kaibenn]

With the build from @awiouy the problem is solved now on my Wetek Play2 (Kodi,LibreElec) as well

[TonioRoffo]

I guess it might be interesting to see how old Connect hardware behaves with this these updated clients.

I've tried a Panasonic All-1C versus the mentioned spotify client and higher - same problem. A lot of customers will be unhappy!