apresolve type dealer-g2

[kingosticks]

I've no idea when this changed, and I couldn't find anything about this here already, but has anyone (including @devgianlu) noticed the Spotify desktop app is now requesting https://apresolve.spotify.com/?type=dealer-g2 and getting back some different dealer-g2 endpoints?

{
    "dealer-g2": ["gew1-dealer.g2.spotify.com:443", "guc3-dealer.g2.spotify.com:443", ... etc ],
    "spclient": ["gew1-spclient.spotify.com:443", "guc3-spclient.spotify.com:443", ... etc ],                                                                                                                                                                 }  

Also in my case, everything is on port 443. That's also different compared to when you omit type=dealer-g2. EDIT: I was mistaken about this aspect. The accesspoints still use a mix of ports, and everything else uses port 443.

I don't know if there is any actual difference with these APs, just interesting.

[devgianlu]

The dealer isn't the one having issues right now, but I guess it's something to keep an eye on.

I am on a quest to find where the new clients get the audio file ID, it doesn't seem like they use the /metadata/4/ endpoints anymore and I don't see anything obvious. 1.2.52.442.g01893f92 (that's what I have decompiled and instrumented) seemed to work already during the brief /metadata/4/ downtime.

[kingosticks]

Yes, I just considered it interesting.

What new clients are you referring to? My Spotify windows desktop app uses /metadata/4, at least I assumed so because they use the id from that response with /storage-resolve/v2

[devgianlu]

What new clients are you referring to? My Spotify windows desktop app uses /metadata/4, at least I assumed so because they use the id from that response with /storage-resolve/v2

🤔 🤔

When /metadata/4/ was down, my client at 1.2.52.442.g01893f92 was still working even though responses didn't have the list of audio files so I assumed that they had something new going on and were trying to deprecate the old one.

[SuisChan]

I am on a quest to find where the new clients get the audio file ID

Either using ExtensionKind::AUDIO_FILES via /extended-metadata/, or from the primary db when the data has already been cached. I can't find any other options

[devgianlu]

It looks like it's doing extended-metadata requests with ExtensionKind::TRACK_V4 and that contains audio files. I guess this is preferred over the old metadata/4/? Might be worth switching to it already?