Hi all,
I am trying to start the playback of the current queue in the system music player using:
let player = SystemMusicPlayer.shared
try await player.play()
But there is no playback, what am I doing wrong? Please keep in mind that there are already songs in the queue. I am simply unable start the playback.
Hello @ashinthetray,
Oh, I see. This behaves as designed actually.
If SystemMusicPlayer allowed another app to begin playing without setting the queue, then that other app would have access to the currentEntry that was set by the user elsewhere. This would be a serious privacy concern, as it would allow any third-party app to see what the user was playing.
Imagine if a user were listening to a religious song, or maybe some kind of revolutionary song; allowing a third party app to programmatically get that information might put such a user in great jeopardy.
So in order for SystemMusicPlayer's play() method to work, you first absolutely need to set the queue from within your app.
I hope this helps.
Best regards,
Thanks @JoeKun! You're a life saver as usual. Wait till you see what I've been working on. ;)
Hello @ashinthetray,
There is not enough information here for us to be able to offer any guidance or suggestion.
Could you please file a ticket on Feedback Assistant, including a sysdiagnose?
Thanks,
@JoeKun here is the ticket: FB9621750. I am able to insert a song into the queue, skiptoNextEntry and so on. But simple unable to start the player. Here is the error in the console:
[SDKPlayback] prepareToPlay failed [no target descriptor]
P.S: Even the .pause() works when the player is already playing. But if I call SystemMusicPlayer.shared.pause() then SystemMusicPlayer.shared.play(), it will only pause and won't play after.
I am sure my question is pretty boneheaded, but here is basic assumption: Calling the .play() method will resume playback.
Hello @ashinthetray,
Oh, I see. This behaves as designed actually.
If SystemMusicPlayer allowed another app to begin playing without setting the queue, then that other app would have access to the currentEntry that was set by the user elsewhere. This would be a serious privacy concern, as it would allow any third-party app to see what the user was playing.
Imagine if a user were listening to a religious song, or maybe some kind of revolutionary song; allowing a third party app to programmatically get that information might put such a user in great jeopardy.
So in order for SystemMusicPlayer's play() method to work, you first absolutely need to set the queue from within your app.
I hope this helps.
Best regards,
Thanks @JoeKun! You're a life saver as usual. Wait till you see what I've been working on. ;)
Hello @ashinthetray,
I just brought up this topic with my colleagues who work a lot on our playback engine, and they just told me that I was actually wrong in my initial assessment, and that this was meant to work, as long as your app has been granted authorization to use MusicKit using MusicAuthorization.request().
I apologize for misleading you with that initial response a few weeks ago.
We will investigate this issue and try to resolve it in a future version of iOS. As it turns out, a very similar Feedback Assistant ticket has already been filed; its number is FB9674648.
Best regards,
Hello @JoeKun,
We will investigate this issue and try to resolve it in a future version of iOS. As it turns out, a very similar Feedback Assistant ticket has already been filed; its number is FB9674648.
I am the one who submitted the FB9674648. I have asked about the current status in the feedback above but have not received a response.
Do you know what the current status is regarding the above?
iOS 15.2 seems to have the same behavior.
Best regards,
Hello @birnimal,
We do not communicate status of any Feedback Assistant ticket other than to say that we are either investigating, or that we have released a correction for it.
This is intentional because we don't want to make any false promises about a work-in-progress fix; you never know what could happen in the convergence period for any release; there's always a slight possibility that a fix might need to be reverted if it happened to cause a bigger issue somewhere else.
In this particular case, all I can say at this point is that we are investigating FB9674648.
Best regards,
Hello @ashinthetray and @birnimal,
We have included a fix for this issue in iOS 15.5 Beta 1.
I hope this helps.
Best regards,
