Current song not displayed right after Spotify launch about sp-tray HOT 19 CLOSED

I have finally found the time to investigate this, and managed to find a solution, which is admittedly a bit hacky, but seems to work okay.

The problem seems to be that, at the moment Spotify launches, the extension picks up Spotify's DBus properties faster than Spotify can populate them. I don't know how that works, but that's the only explanation I can give. If you query that information the moment Spotify's name appears on DBus, you get incomplete values. But if you wait just a little bit, you get everything.

So that's what I did. I've added a couple hundred milliseconds of delay to the instantiation of the spotify dbus proxy. It now has all the correct values when Spotify is launched. I don't love the solution, as arbitrary time delays like that are not very reliable or portable, but that's the only thing that has worked so far.

I'll probably push a new version with the fix today, tomorrow at the latest.

from sp-tray.

It's out and approved now.

I made it so the song title isn't actually displayed until you start playback for the first time after launching Spotify. That was a conscious decision on my part, to make compatibility with 3rd party clients simpler. The data should be correctly shown once playback starts, though.

from sp-tray.

Yeah I know about this one, though I'm not sure what's causing it. For some reason, until you change the song, the metadata variable you get from the proxy only has the album information. artist and title aren't there. It's weird.

I thought I'd broken it with a commit, but I don't think I touched that part of the code. I'm still getting the metadata the same way I always have, but now it works different somehow. Could be related to the latest Spotify version. I know for a fact that they did make some changes to their Dbus interface (see #22), this could be a side effect of those.

from sp-tray.

Hey @esenliyim,

Great news!

Another idea though, maybe silly, you tell me: you may also requery every x ms the DBus, as long as the information is not complete. The delay between this queries will also be arbitrary, but at least, you can make sure it ends up with the information, will it come after 200ms or 7s.
It should obviously behave that way only on start, and never again after.
If you want, you can also implement a max retry counter, to avoid an infinite loop in the case the information would never show up for whatever reason.

If you prefer, i can wait for your branch, PR or commit to show up and give myself a try when i have the time.

What you did is a win in any case! Spotting the reason of an issue is often the most complicated! ^^

from sp-tray.

Yeah that's actually what I'm doing. If the artist-title-album trio is all set or is all unset, I go ahead and create the proxy. The reason I accept their all being unset is because that's a normal state for Spotify to be in. Happens when you first launch the application after installing it, or sometimes updating it, for example. If the trio is partially set, I retry 4 more times before breaking the loop and just creating the proxy with incomplete values.

from sp-tray.

Pushed it, finally.

Now at the very start it displays the ⏹️ icon, but the correct metadata is there under the hood. When you start playing it should show the correct stuff.

I've done my own testing on two different computers and it seems to be working fine. Let me know if there are issues.

from sp-tray.

Great! I'll test that on my side soon and let you know if it fixed it too.
Thanks for the fix. ☺️

from sp-tray.

Hi @esenliyim,

I had a chance to test it today, and globally it works great.

I have two concerns though.

1. I had on scenario where I ended up with the variables {{artist}} and {{track}} not populated, but my Spotify was not running properly at the time, even if that happens regularly. I think it happens when i switch from an audio interface from another (Bluetooth to speakers in this case) while the computer is halted. In this case : I was running my laptop on my Bluetooth headset until I sent it to sleep, but it was disconnected when I woke it up later. I think then Spotify looses the proper audio sink.
   When that scenario happens, Spotify can still be played/pause and you see the progress bar advancing, but here is no audio output until I manually go to the next song.
   That's why I would say it's not at all an issue on your side.

2. I'm personally not a fan of the ⏹️ emoji, especially since it cannot be configured in the settings. As a fervent adept of maximum interface sobriety on my interfaces, I set up the rest of spotify-tray options to never display any icon. But I can not act on this specific ⏹️ icon:
   

from sp-tray.

I'm not sure I understand the problem with 1). As in, I don't understand the situation that causes it. The label fails to replace the placeholders during playback after switching audio interfaces? That's weird. I'd love to see what the gnome-shell logs show when that happens, if anything.

And I agree with the stopped icon. Good news is, that's just a stopgap measure for the time being. I won't be updating the extension on the website without an option to change it. The loop/shuffle icons too.

from sp-tray.

@esenliyim I managed to reproduce 1) just now, staying on speakers, just by launching/exiting Spotify multiple times in a row.
Here is a video : https://youtu.be/GHtsy6HxvFM
Edit: sadly my video capture is corrupted; I'll try to make another one.

I'm not sure where I can find the gnome-shell logs you are asking me about. I'd be glad to capture them for you.

from sp-tray.

I'll try doing that on my end.

To watch the logs I use the command journalctl -f | grep gnome-shell and then look for any JS errors that have the extension's name in them. Bit crowded in there, though.

from sp-tray.

This one looks better: https://youtu.be/uuaeoWelcYg

from sp-tray.

Right. I managed to recreate it by restarting Spotify over and over. Sometimes it does fail to display correct information, but it goes back to normal after restarting again. I think my way of deciding when I've got "good" metadata from DBus is flawed, and sometimes the extension thinks it got it when it didn't, in fact, got it. Must investigate.

edit: Yes, I have confirmed that is indeed the case.

from sp-tray.

I am still encountering this issue, was it supposed to be fixed?

from sp-tray.

Oh right. I did fix it and then uploaded the fixed version. It got rejected because of a dumb mistake on my part but I couldn't get on it right away and then things happened in real life and I kinda forgot about it, which is kinda embarrassing. Thanks for reminding me. I'll upload it as soon as I can, an update should be available soon.

from sp-tray.

Haha no worries, all good, it's not a deal breaker!

Great gnome extension no matter what ;)

from sp-tray.

For some reason, it seems this is still not fixed, using v17. 🤔

from sp-tray.

Interesting. I'm gonna need you to help me help you then, because it's working fine for me on two different systems. There's no fixed local version that I haven't pushed either.

Does it fail after every launch, or just sometimes? What do the gnome-shell logs say when it does fail?

from sp-tray.

@Batwam fixed this.
Moon-0xff/gnome-mpris-label#3 (comment)
Moon-0xff/gnome-mpris-label@dce09d3

from sp-tray.