Boosting this. I'm using MusicKit and need to detect the end of the queue. Trying to find a pattern to work around it, I'm observing changes in ApplicationMusicPlayer's state and I see that when the queue ends, queue.currentEntry matches the last entry in the queue and playbackTime is nearly zero, say less than 0.01. But it gets more complicated, because when first playing the queue it also for a moment gets into paused state for the first track with playbackTime 0, and it could happen that I have a 1-track queue so that is also the last track in the queue. Which means by the pattern described above I'd wrongfully assume the queue has ended. Looking for a solution to that, I found that this initial paused state is a transition from a stopped state, so if I only apply the logic above when the transition is from playing to paused, I should be good. I'm not sure yet this is going to work OK in different platforms, right now I'm testing on Mac OS 14.5. But we shouldn't have to deal with this. We simply need to be notified somehow that the queue has ended.

Hi! did you get any news or have you found any workaround for the first issue you described here?

I'm having the same issue :(

@DTS Engineer resurfacing this conversation since I didn't hear from you again since I posted my backtrace. I pretty much assumed there was a concurrency issue in MediaPlayer's MPMediaItemArtwork and worked around it by not calling it from an async context. Since then I have migrated a lot of my MediaPlayer code to MusicKit. I'm seeing the same issue every now and then: the cooperative threads seem to get locked. See new attached backtrace. It seems to get into the same underlying code as in the MediaPlayer scenario. This is how I get artwork now: let (imageData, _) = try await URLSession.shared.data(for: urlRequest) where urlRequest points to the URL that I obtained from MusicKit's Artwork.url(width:height:) method. Would you be able to take a look at the new backtrace to see if you can provide further insight? vf-backtrace2.txt

@pk_ I'm experiencing the exact same thing. I cannot reproduce it myself but in my reports it shows as happening on an iPhone 12 mini with iOS 18 beta 2.

@DTS Engineer from my crash reports it seems my app is having this crash in the wild on an iPhone 12 mini with iOS 18.0 beta 2. I got the crash when debugging on my mac (in line with your comment above), at "withCheckedThrowingContinuation", while using Xcode 16.0 official. For the released build I used Xcode 16.0 RC. Can you confirm if a higher iOS beta (or official release) is required to see this fixed?

Fixed in iOS 18.1 beta 5.

@talkingsmall Just bumping this thread to note that FB10581868 has been resolved as of beta 4 and I no longer see failures for negative MPMediaItemPropertyAlbumPersistentID values. Hooray! Thanks for that. If this was indeed resolved, there is a regression as of iOS 18.0.1 (Xcode 15.* and 16.1). I've had a user report an issue in my app that turned out to be the negative ID thing. I don't have any such IDs across my library in my devices but this user has a number of those in his. I was able to pinpoint the cause and provided the Int64(bitPattern:) workaround, and everything works now.

Hi, I tried that example project and indeed the bar is not displayed. The tab definition needs at least this to make it display the bar: Tab(value: .search, role: .search) { NavigationStack { Text("This view is intentionally blank") .searchable(text: $text) // <- your @State var } }