@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.

Fixed in iOS 18.1 beta 5.

@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?

@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

I'm having the same issue :(

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

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.

I got a reply for my Feedback. Basically MediaPlayer as a legacy framework is unlikely to get patched for things like these and they suggested I switch to MusicKit. Which I did! A lot of work though.

This is solved in mac OS 14.5.

It seems I was mistaken regarding cross-device ids for non Apple Music items. I'm able to see matching ids on different devices for the same tracks. The question remains, why is it not possible to query tracks by title?

I don't have a solution for you, I'll just mention that I managed to have an AppIntent to play audio without bringing the app to the foreground. It's audio the app knows and doesn't need to be given media information. The app gets launched if needed, and not brought to foreground (this by not implementing openAppWhenRun in my intent). In the shortcuts app I see my app intents, I tap the audio playing one there and it works fine. The problem is I cannot get to use this intent from an interactive widget because the intent depends on stuff in the main app target that isn't decoupled and I cannot bring it all to the widget extension. Edit: even if I decoupled my audio playing code, I'd still probably be unable to play audio from the widget, based on your test and considering any code that runs is in the widget extension, not the main app. Having shared code between app and extension will be of no use if I can't get the actual app to be running just like when I tap the intent in the shortcuts app.

Here is my backtrace @eskimo, thanks for taking a look. vf-backtrace.txt

Here's one complete thread. I tried posting the whole thing but it's beyond the post size limit.   thread #4, queue = 'com.apple.root.user-initiated-qos.cooperative'   frame #0: 0x00000002106bf5e0 libsystem_kernel.dylib`__ulock_wait + 8   frame #1: 0x000000010441abdc libdispatch.dylib`_dlock_wait + 56   frame #2: 0x000000010441a990 libdispatch.dylib`_dispatch_thread_event_wait_slow + 56   frame #3: 0x000000010442bc54 libdispatch.dylib`__DISPATCH_WAIT_FOR_QUEUE__ + 384   frame #4: 0x000000010442b594 libdispatch.dylib`_dispatch_sync_f_slow + 180   frame #5: 0x00000001f6ee6940 MusicLibrary`-[ML3ArtworkConfiguration supportedSizesForMediaType:artworkType:] + 248   frame #6: 0x00000001e37c64ec MediaPlayer`-[MPArtworkConfiguration supportedSizesForMediaType:artworkType:] + 68   frame #7: 0x00000001e3704290 MediaPlayer`-[MPMediaLibraryArtwork validSizes] + 120   frame #8: 0x00000001e379c814 MediaPlayer`-[MPMediaLibraryArtworkDataSource _existingRepresentationForArtworkCatalog:fromCacheOnly:] + 208   frame #9: 0x00000001e379c9c0 MediaPlayer`-[MPMediaLibraryArtworkDataSource existingRepresentationForArtworkCatalog:] + 48   frame #10: 0x00000001e363ac50 MediaPlayer`-[MPArtworkCatalog bestImageFromDisk] + 40   frame #11: 0x00000001e368e6a8 MediaPlayer`__70-[MPConcreteMediaItemArtwork initWithArtworkCatalog:allowsNetworking:]_block_invoke + 296   frame #12: 0x00000001025a7d28 VinylFetish`@nonobjc MPMediaItemArtwork.image(at:) at <compiler-generated>:0   frame #13: 0x00000001025a7cd4 VinylFetish`protocol witness for MediaArtwork.image(at:) in conformance MPMediaItemArtwork at <compiler-generated>:0   frame #14: 0x00000001026671bc VinylFetish`MKHelper.fetchArtwork(item=0x0000000280e331b0, imageSize=80, self=VinylFetish.MKHelper @ scalar) at MKHelper.swift:166:43   frame #15: 0x000000010244bd18 VinylFetish`closure #1 in AlbumCell.updateFromItem(self=0x000000011e9d4800, item=0x0000000280e331b0) at AlbumCell.swift:154   frame #16: 0x000000010244da54 VinylFetish`partial apply for closure #1 in AlbumCell.updateFromItem() at <compiler-generated>:0   frame #17: 0x0000000102312eac VinylFetish`thunk for @escaping @callee_guaranteed @Sendable @async () -> (@out A) at <compiler-generated>:0   frame #18: 0x0000000102312ffc VinylFetish`partial apply for thunk for @escaping @callee_guaranteed @Sendable @async () -> (@out A) at <compiler-generated>:0

All right! I seem to have fixed it with your help! I had an async function to get image artwork to display in table view cells. Each cell would start a Task to call this function. The function would first attempt to get the media item's embedded artwork as UIImage by calling MPMediaItemArtwork.image(at:). If this returned nil for some reason, it would then attempt to fetch it via MusicKit using a MusicCatalogResourceRequest. This is why the function is async and why the cell makes the call in a Task. I split this function in two, one for the embedded artwork (sync) and one for MusicKit artwork (async). The cell calls the first one and only if that fails uses a Task to call the other one. Now it works and when I pause the app I find no 'com.apple.root.user-initiated-qos.cooperative' threads. I guess the takeaway is that that API is not thread safe but maybe you can provide some other insight given the above backtrace? Thank you!!