MPMusicPlayerController does not work on iOS 11.3 Beta

Apple music does not work on iOS 11.3 Beta. It was working on iOS 11.2.5 though.


I am playing Apple music in my application using two ways using setQueueWithMPMediaItemCollection and setQueueWithStoreIds. First one is working fine but second method is not working at all and there is no error occurrs but music is not playing.


// Code snippet

let appleMusicPlayer : MPMusicPlayerController = MPMusicPlayerController.applicationMusicPlayer()

// Method 1

self.appleMusicPlayer.setQueue(with: MPMediaItemCollection(items:[appleMediaItem]))

// Method 2

self.appleMusicPlayer.setQueueWithStoreIDs([trackId])



any help will be highly appreciated.

Replies

I am still seeing the same problems with "prepareToPlay" and "currentPlaybackrate" that you mentioned above. I also do have an app on the app store that is being impacted by this bug (at least for those that have updated to 11.3).


I did submit a bug report back in the beginning of March but have never gotten any response. Is that to be expected? Does anyone ever get any responses from Apple on bug reports? Should I just submit them again with each new Beta or release? Also, I noticed that you referenced your bug report numbers. It's not like I can see them or "comment" on them so are you sharing them so that I would I reference them in my bug report? If so, where in the report should I include them (like what section)?


By the way, I've verified that it's still not fixed in 11.4 beta 1, but I just saw that 11.4 beta 2 was released yesterday so I'll test it on that shortly.

I've tested on iOS 11.4 beta 2 and still see these issues:

  • MPMusicPlayer autoplays when calling prepareToPlay (bug#37786167)
  • No action when setting currentPlaybackRate (bug#38126022)
  • nowPlayingItem reported is not the actual currently playing track (bug#39412140)


Even though we can't see each other's bug reports, I've been told that it could be helpful in case the Apple folks are trying to match issues reported here with those submitted via the bug report system.


I have no insider knowledge on how/when the bug reports get reviewed or prioritized. For my own satisfaction, I imagine that a whole team of Apple pros read, reread & discuss every word I type here or in a bug report. It's possible that it doesn't really happen that way.


I've posted this position before: I hope you'll submit the bug report. Sometimes it seems no one is working on the issue. But I'm sure there are many moving parts, with most outside my field of observation. And even though I don't understand how Santa gets down the chimney with presents, I still write my wish list ;-) So file that bug report and let's keep our hopes high!

Yes, seeing the problems with 11.3. Went through problems with 11.1, which required 11.2 to fix. My app was out if the store for months because of it and I cannot believe that I have to go through this again. I had 4 radars open about different facets of the problems. I have better things to spend my time on than making bug demo app for Apple.


Apple, get your act together on the media player.

And for the record, 2 more radars opened. One for starting playing on prepareToPlay, one for no stopped notification being sent (this could be a result of the player being in a goofy state in the first place).

FYI, my prepareToPlay bug reports were all marked as duplicates today, so at least there's confirmation that they're being looked at?


Also, I was spending a little more time yesterday looking into work-arounds and found that my problems with setting "currentPlaybackTime" only occurred after calling the "setQueue" method. A normal sequence of calls for me would be:

  1. Call "setQueue"
  2. Call "prepareToPlay"
  3. In the completion handler (among other things) set "currentPlaybackTime"
  4. Call "play"

If I don't set the queue each time before "prepareToPlay" is called, previous versions would throw an error. So if I were to pause playback and attempt to resume, in previous versions it would be acceptable to re-set the queue, call "prepareToPlay" and set the currentPlaybackTime to where playback was stopped and begin playback.


Now, with 11.3 and 11.4, setting currentPlaybackTime in this scenario often has no effect and playback will start at the beginning of the song. If I change it to set the queue only once (like when the selection changes) prepareToPlay will not throw and error and setting currentPlaybackTime will work. Playback will start at the moment that the completion handler is called (which is wrong), but it still gives me a chance to stop spinners and start counters, etc.


It's not perfect but it provides a solution to those using my app with version 11.3 that was released with this bug.

These bugs still present in iOS 11.4 beta 3 (sigh)

  • MPMusicPlayer autoplays when calling prepareToPlay (bug#37786167)
  • No action when setting currentPlaybackRate (bug#38126022)
  • nowPlayingItem reported is not the actual currently playing track (bug#39412140)

These bugs still present in iOS 11.4 beta 5

  • MPMusicPlayer autoplays when calling prepareToPlay (bug#37786167) (has been identified as duplicated)
  • No action when setting currentPlaybackRate (bug#38126022)
  • nowPlayingItem reported is not the actual currently playing track (bug#39412140)

These bugs are still present in iOS 11.4.1 beta 1 (15G5054c)

  • MPMusicPlayer autoplays when calling prepareToPlay (bug#37786167) (has been identified as duplicated)
  • No action when setting currentPlaybackRate (bug#38126022)
  • nowPlayingItem reported is not the actual currently playing track (bug#39412140)

{crackle, crackle... sound of a broken record... blowing into mic... "anyone here??"}


These bugs are still present in iOS 11.4.1 beta 2 (15G5063b) & iOS 12 beta (16A5288q).


  • MPMusicPlayer autoplays when calling prepareToPlay (bug#37786167) (has been identified as duplicated)
  • No action when setting currentPlaybackRate (bug#38126022)
  • nowPlayingItem reported is not the actual currently playing track (bug#39412140)

Still present in iOS 11.4.1 Beta 3 as well. To add to the list, I also see that the MPMusicPlayerController will initiate Track 1 after setQueue no matter what if the Music.app is not currently playing an item. Obviously, that's almost always the case for every user upon entering the app, so it's as bad as it gets.


I also don't understand why Apple have chosen to use an identifier (startItemID) rather than an index for the starting item in the queue through the MPMusicPlayerStoreQueueDescriptor. Essentially, each track in the queue has to be entirely unique, else you'll also experience bugs, as the MPMusicPlayerController doesn't know the difference between identical tracks provided through only storeIDs.

For info... I had previosuly raised two bug reports similar to your 'No action when setting currentPlaybackRate' bug - one back in March for iOS 11.3 (39031652) and a new one this month specifically for iOS 12 (40809985). I also raised a DTS support incident which confirmed there is no workaround but the engineering team are aware of the issue. Both my bugs have been closed recently as a duplicate of yours (38126022).

I'm thrilled to see that MPMusicPlayer now responds to currentPlaybackRate in iOS 12 beta 3. One down!

MPMusicPlayer autoplays when calling prepareToPlay (bug#37786167) is still not fixed in iOS 12 Beta 8. Hoping that this is fixed by release as this bug produces quality of service issues for my app and others.

Still not fixed in 12.0. I went so far to rewrite my app to mostly use AVPlayer for everything but DRM files but as MPMusicPlayerController is the only way to play DRM music really need a fix.
As a developer I can't believe Apple is allowing something this fundamentally broken to continue in this state. But I have to, because it is.

And still does not work properly in 12.1 beta 5