Erratically missing Control Center integration

[defagos]

As an SRF news app user I would like to be able to consistently steer playback from the Control Center. With the current Pillarbox integration, though, it happens that sometimes no integration in the Control Center is available, even though it is enabled in code.

Context:

• Pillarbox 2.0.0
• iOS version: 17.5.1

Acceptance criteria

• The issue reported by SRF has been investigated and solved if possible.

Tasks

• [x] Investigate.
• [x] Solve:
  • [x] Restore remote command center commands, at least after returning from mix with other audio session.
  • [x] Update documentation to warn about this behavior.

[defagos]

We could find a way to easily reproduce the issue in the SRF app. It seems to be related to the fact that two players simultaneously play with all players at some point wanting to be active.

Here is how to reproduce the issue reliably:

1. Enable the Stage server in the settings. This makes some content available that seems really well suited to reproduce the issue.
2. Under Videos, scroll so that the first S-teaser item is visible and that the last item above the S-teaser section starts playing automatically.
3. Once it is playing automatically, tap on the first S-teaser item. Check the Control Center, which does not display the opened item information.

[defagos]

Possible reasons but need further investigation:

• Issue with our implementation.
• Become active might sometimes fail.
• Issue with how becomeActive() / resignActive() are called. Since the last call wins maybe the player in the background (see above video) steals the session.
• Issue with MPNowPlayingSession management by the system (quite unlikely here).

Some ideas for further investigation:

• Check how active player management is implemented in SRF app.
• Try to reproduce in a smaller demo.

If the issue is related to our becomeActive() API we might also provide optional force / unforce behavior, so that the method does not always make the instance it is called on active, but first checks if another one is already active, returning information in this case (e.g. a Bool, an exception., whatever).

Maybe we should also implement the becomeActiveIfPossible completion handler to see if the request was fulfilled successfully.

[defagos]

@walid found out that the reason for the bug is that the SRF app switches back and forth between mixable and non-mixable audio session category options.

The fact that a non-mixable category option is required for Control Center integration is well explained in a WWDC session. What we did not know until now, though, is that the process of switching from a non-mixable to a mixable option, with Control Center visible, is not reversible. Registered remote commands are namely removed and must be restored after the switch to a non-mixable option.

Now playing info attached to the now playing session, on the other hand, remains attached.

We therefore have to figure out a way to restore remote commands after an audio session option change. This requires a fix to our implementation since this process is entirely managed by Player. There is sadly no corresponding notification we can subscribe. We can of course swizzle audio session option updates to post our own notification, but maybe there is another more elegant approach to be found.

[defagos]

After more investigations:

• There is no bug on iOS 18 and tvOS 18. No fix is required for these versions. The bug existed on iOS 16 (don't have access to a tvOS 16 device anymore), though.
• There is no need to re-install remote commands. It suffices to force a pause / play transition to have the system consider its heuristics again and update the Control Center if needed. What is nice is that this transition does not lead to any playback interruption or changes which would be reflected in additional analytics event pairs.
• If we want to cover all potential changes to audio session settings we need to all methods having an options parameter, as the implementation on iOS / tvOS 16 / 17 has no single designated implementation we could swizzle.
• The behavior is similar on tvOS. If enabling a mixing session the Control Center integration disappears and must be fixed after restsoring a non-mixing session, but only on tvOS 17 (and likely tvOS 16, though I didn't have access to a test device).

[defagos]

We fixed the bug. I will soon open the dedicated PR.

I tested all the use cases thoroughly on our side. The issue we had was really only affecting iOS and tvOS 16 and 17. The rest of the problem is at the SRF app level, which needs to carefully setup the audio session category so that inline muted playback mixes with other apps.

[defagos]

I had completely forgotten I filed this issue a while ago under FB11416789: Control center integration not automatically enabled when switching audio session options from .mixWithOthers to .default . I closed the FB accordingly.