Matching the Queue.CurrentEntry.Item.ID with a Song's ID. Can't tell if it's a bug

I'm trying to match the id of the song currently playing with the id of the song I added to the queue, but they never match.

musicPlayer.queue = [mySongVar]
print(mySongVar)

This will print out:

Song(id: "i.eoqMkIkPJ9Ea", title: "À peu près", artistName: "Pomme")

then I tell the musicPlayer to play what's in the queue and print:

print(musicPlayer.queue.currentEntry!.item!.description)

And I´ll get this:

MusicPlayer.Queue.Entry.Item.song(Song(id: "1440887303", title: "À peu près", artistName: "Pomme"))

I don't understand why the Song.id for the Item for the queue's current entry is a a certain string, but the if for my original Song object I sent to the queue is something else entirely.

I'm not sure if I'm going about this the wrong way. I'd really appreciate some help/guidance! Thanks"

By the way: let musicPlayer = ApplicationMusicPlayer.shared

An Answer:

The ID of the item in the QUEUE is different to the actual SONG because this allows for songs to appear more than once in the queue.

To get the SONG:

if let currentEntry = self.musicPlayer.queue.currentEntry {
    print("CURRENT - \(currentEntry)")
    if case let .song(song) = currentEntry.item {
        print("SONG - \(song)")
    }
}

IGNORE BELOW UNLESS YOU WANT A RANT

I found that the IDs change A LOT too. I've had to rewrite my stuff a few times now trying to make it all work. My app plays music AND sound effects at the same time. Think, ocean sounds layered with music. It's nearly impossible to keep it all in sync and know when BOTH are playing at once, and managing all the different states. SwiftUI is perfect for this, but the MusicKit just isn't there yet. currentEntry is an ObservableObject, but I've had to hide it away in my model, and listen to the updates using Combine so I can keep things in sync.

So for playback you need to listen to both currentEntry AND the playbackState property. I THINK. Pretty sure currentEntry can still have a value even if the playbackState is something other than .playing. It amazing that such a simple thing as showing a play/pause image on a song in your UI is so complicated now.

I'm attempting to open things up a bit more in my app (support other services like Spotify), so rather than rely on the song ids that Apple has, instead I'll be looking at the ISRC value for comparison. These can then be used to load up music from another service. You could also try matching the song name AND artist, but this also leaves you open to edges cases (though unlikely) but you could also throw in the song length to the check just to be sure.

Hopefully you'll get an official answer soon. My guess is that they actually fix the issues with MusicKit come WWDC23. The new APIs are slightly improved in some areas, but completely broken in others.

Of course someone will come in and be like "Can you please give us an example". It's very obvious Apple don't use the new APIs in their own products otherwise they would understand this. For example, we only JUST got the ability to even use currentEntry, which is such a huge oversight. Zero indication that this was broken as per the docs. So you go ahead and spend hours implementing something only to realize it can't do what you need it to do. Lots is missing and there's zero guides online besides the basics on how to use this framework. My guess is very few devs are making apps that need music, so feedback has been low.

In saying all this, it's fine. I'm glad they're making these improvements, especially around the work they're now doing with their webinars where devs can get help and ask questions about these topics. It'll only improve from here. It's this transition where we find ourselves struggling.

Matching the Queue.CurrentEntry.Item.ID with a Song's ID. Can't tell if it's a bug
 
 
Q