Metadata not loading on Startup (Spotify)

[Batwam]

as discussed in #28 , the metadata is not loading with some apps until the player is stopped/restarted or there is a switch to the next song.

This has been noticed with Spotify and VLC. For info, the current stable version doesn't have this Spotify startup loading issue.

Steps to reproduce:

• Check that setting is set to Switch Automatically and Spotify closed
• Launch Spotify
• Start Song

Based on investigations so far, Spotify is selected as active playe but the metadata info is empty which leads to a blank label

[Batwam]

I have put some logs in various places to see what is running and what isn't and I'm almost more confused now. The nubmers correspond to the row/line in the code. I have also included a log to show if update() is being called.

We can see that the playbackstatus is getting updated when I press play/pause. However, the metadata remains empty. Even though update()` runs because of play/pause, it's still not reading the medata info. However, as soon as the song switches, the metadata appears. also, the whole time, Spotify is selected as active player so it's not that:

Any idea? we could force an update if metadata['xesam:title'].get_string()[0] was empty but even if I call update() on every refresh, it won't load the metadata. I'm just not clear on what extra step occurs when the song switches to force a metadata reload. Also, looking at d-feet, this data is definitely available. Seems like some sort of timing issue again.

[Batwam]

By the way, metadata isn't null. It contains 11 keys with xesam:title,... but their value is empty.

[Moon-0xff]

Reminds me of this https://github.com/Moon-0xff/gnome-mpris-label/pull/3#issuecomment-1303906453

[Batwam]

Wow, completely forgot, that's a good memory! I tested stable again though and it's working fine. I just can't figure out what is done differently to make it fail now...

[Batwam]

Are you able to reproduce it on your end or it's only me? It's not like it's happening once once in a while, it's literally each time I start Spotify if using main and never with stable. This helps with troubleshooting but I'm kind of running out of ideas...

is there anything fundamentally different between stable and main when it comes to metadata loading?

[Moon-0xff]

is there anything fundamentally different between stable and main when it comes to metadata loading?

2402390de43ee1455eb17a7f79769022f7ee7a3e and 9b2a1fb3faa42dfbfbe881d3b10720f62076a1ed

you can test if the bug was introduced in any of those commits by loading the previous one

git checkout 461965830e1f0dc3b0ecc5ac497bddb67d167a75 for 2402390de43ee1455eb17a7f79769022f7ee7a3e

git checkout ee79793ef76578e1e43310aa94e422d491388bda for 9b2a1fb3faa42dfbfbe881d3b10720f62076a1ed

git checkout main to reset HEAD position

[Batwam]

results so far:

• git checkout 461965830e1f0dc3b0ecc5ac497bddb67d167a75: same issue
• git checkout ee79793ef76578e1e43310aa94e422d491388bda: same issue

I'm working through the older versions to seen when the issue started.

note also that I've been seing this issue preventing the extension from reloading: this.container.get_parent() is null. This goes away if I comment out this.container.get_parent().remove_child(this.container); so we need to include a check in _updateTrayPosition() for this if not already done.

[Batwam]

ok, the issue seems to appear from 7bd59fae434fa17ff5528032dc942cee14e7528a which kind of makes sense as it included a lot of changes across the code. But I can't figure out exactly what is causing it...

[Moon-0xff]

The changes of https://github.com/Moon-0xff/gnome-mpris-label/commit/7bd59fae434fa17ff5528032dc942cee14e7528a shouldn't create this issue. The only lines that might create this problem is the check against undefined or perhaps creating the entry proxy interferes with the metadata retrieval for some reason.

[Batwam]

I thought it might be the undefined check at first too but it's not. It goes past it, the returns due to data.length being 0. The field (key) exists but there doesn't appear to be any info in it.

[Moon-0xff]

I didn't mention that the VLC issue is a bug on VLC itself.

VLC starts with a playbackStatus of Stopped until it's changed by the user, regardless if VLC automatically starts something.
Not our bug and there's nothing we can do about it except fill a ticket i suppose.

[Cry4775]

Not sure if it's related to this issue, nor if you are already aware but I have a similar problem.

I have the extension to allow only Spotify as player and the label shows Artist - Track - Album. When I first open Spotify it will only print the album name for some reason, until it goes to the next song.

[Batwam]

@Cry4775 Yes, it's the same issue, Spotify and VLC don't seem to behave properly unfortunately.