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!!

Whoa very interesting. I have 6 of such threads and they all seem to be at the MPMediaItemArtwork.image(at:) call for different table cells. They are like this: thread #9, queue = 'com.apple.root.user-initiated-qos.cooperative'   frame #0: 0x00000002106bf5e0 libsystem_kernel.dylib`__ulock_wait + 8   frame #1: 0x000000010307abdc libdispatch.dylib`_dlock_wait + 56   frame #2: 0x000000010307a990 libdispatch.dylib`_dispatch_thread_event_wait_slow + 56   frame #3: 0x000000010308bc54 libdispatch.dylib`__DISPATCH_WAIT_FOR_QUEUE__ + 384   frame #4: 0x000000010308b594 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 (...) That ulock_wait at the top seems to suggest there is a concurrency issue with this API, right? Or I might be using the wrong kind of queue! I will definitely watch that session. Thanks for the insight!!!!

Kind of. I can run it in the simulator but the music library is not available in the simulator, so I mock some library items. In this scenario the bit that uses MPMediaItemArtwork is not run at all. I'm not seeing issues with Tasks there.

Nope, it works fine there.

New report: Started failing again Made minimal app with a Task and works fine Problematic app: I saw that Tasks initially work but eventually stop working. I pinned it down to the use of this API: https://developer.apple.com/documentation/mediaplayer/mpmediaitemartwork/1621736-image Attempting to get a UIImage out of a MPMediaItemArtwork object is enough to break it (!!!) Again, not all devices and possibly not all OS versions, even not every time I launch the app on the same device. But when it fails systematically, I comment out the above API usage and the issue is gone. Is this something you can investigate further?

It is working now :-/ I've seen the issue before and eventually it fixed itself, I presumed from updating to a new OS beta. Now I see it works, it's the same app, same device and same OS version. I will report back if I see the issue again and do the minimal app test, thanks for replying!

Well this may well be a bug in the beta release so I just sent feedback to Apple.

Hey. One year later, I'm curious about what you ended up doing. What I understand from DMG's answer regarding the master object with an NSOrderedSet, it seems to be exactly what iCloud sync WON'T allow, thus requiring some sort of manual ordering, perhaps keeping an index yourself somewhere. This is what I think I have to do now for my project :-/