Add logic in Player to handle issue when media services are reset

[ceciliasaraiva]

We've got reports of an issue where the media services are reset. This causes for the player to stop working. By following Apple documentation, in this situation, we must reset (I've added this inside the sdk) and set up again the audio session (I've delegated this to client of the sdk since this is set up outside currently). Apart from that, from my testing, it seems sometimes we also could get "mediaServicesWereLost", so I've added logging for both and we can monitor what actually is happening with our users.

• add new logging for this issue in PlayerLoggable
• add new func mediaServicesWereReset in PlayerListener and updated in NotificationsHandler so client of the sdk can perform necessary configurations and changes
• add a new monitor AudioSessionMediaServicesWereResetMonitor to handle when media services are reset and lost
• add a new func resetPlayerAndSetUpAudioSessionAfterMediaServiceWereReset which is called from when media services were reset
• add logic to handle this new media error in AVQueuePlayerWrapper and AVQueuePlayerWrapperLegacy

---

This pull request introduces several new features and improvements to the player engine, particularly handling media services reset scenarios. The changes include adding new error types, logging enhancements, and a new monitor for media services reset notifications.

Handling Media Services Reset:

• Sources/Player/PlaybackEngine/Internal/AVQueuePlayer/AVQueuePlayerWrapper.swift: Added specific handling for errors related to media services being reset, creating a specific internal error for recoverable scenarios. [1] [2]
• Sources/Player/PlaybackEngine/Internal/AVQueuePlayer/Legacy/AVQueuePlayerWrapperLegacy.swift: Similar handling for legacy AVQueuePlayerWrapper. [1] [2]
• Sources/Player/PlaybackEngine/Internal/AudioSessionMonitors/AudioSessionMediaServicesWereResetMonitor.swift: Introduced a new monitor to handle mediaServicesWereReset and mediaServicesWereLost notifications.
• Sources/Player/PlaybackEngine/PlayerEngine.swift: Integrated the new monitor into PlayerEngine and added a method to reset the player and set up the audio session again after media services reset. [1] [2] [3]

Error Handling:

• Sources/Player/Common/Errors/PlayerInternalError.swift: Added a new error type mediaServicesWereReset.
• Sources/Player/PlaybackEngine/Internal/Errors/ErrorConstants.swift: Defined constants for AVFoundation error domain and media services reset error code.

Logging Enhancements:

• Sources/Player/Common/Logging/PlayerLoggable.swift: Added new log cases for handling media services reset and updated existing logs to include audio mode. [1] [2] [3] [4] [5] [6]
• Sources/Player/Common/Data/AudioCodec.swift: Updated logging for audioCodecInitWithNilQuality to include audio mode.

Listener Updates:

• Sources/Player/Common/Event/PlayerListener.swift: Added a new method mediaServicesWereReset to the PlayerListener protocol.
• Sources/Player/Mocks/PlaybackEngine/PlayerListenerMock.swift: Implemented the new mediaServicesWereReset method in the mock listener.

Notification Handling:

• Sources/Player/Common/Event/NotificationsHandler.swift: Added a method to handle media services reset notifications.

These changes collectively improve the robustness of the player engine in handling media service interruptions and provide better logging and error handling for such scenarios.

[ziad-halabi9]

we must reset (I've added this inside the sdk) and set up again the audio session (I've delegated this to client of the sdk since this is set up outside currently)

Have you considered applying this solution in the client instead of the sdk since that's where the audio session setup lives currently? (i.e. the app should listen to the mediaServicesWereReset notification and act by calling reset on the player and resetting up the audio session). Or is the plan eventually to move the audio session handling to inside the sdk?

it seems sometimes we also could get "mediaServicesWereLost"

According to the documentation, we don't really need to listen to this notification. It can only serve as a cue before the server restarts. We can log it and see the number of occurrences of media services lost and compare them to when it resets. Do you see any other benefits?

[ceciliasaraiva]

we must reset (I've added this inside the sdk) and set up again the audio session (I've delegated this to client of the sdk since this is set up outside currently)

Have you considered applying this solution in the client instead of the sdk since that's where the audio session setup lives currently? (i.e. the app should listen to the mediaServicesWereReset notification and act by calling reset on the player and resetting up the audio session). Or is the plan eventually to move the audio session handling to inside the sdk?

My initial idea was to perform the reset immediately in the sdk and not delay it any further. And since we don't set up the audio session in the sdk, I figured it made sense to delegate that to the listener, so they can be set it up as desired. I'm fine if we decide to move all to one place. I'm not aware if we want to move the audio session setup to the sdk.

it seems sometimes we also could get "mediaServicesWereLost"

According to the documentation, we don't really need to listen to this notification. It can only serve as a cue before the server restarts. We can log it and see the number of occurrences of media services lost and compare them to when it resets. Do you see any other benefits?

Yes, I've only added the "lost" because I noticed some inconsistent behavior sometimes when testing (for example, I received lost but not reset notification a few times - could be issue with simulating the reset, not sure), so would like to observe this in the wild, it's just for logging and my intention would be to remove it completely after we get (hopefully) positive insights; otherwise, it could possibly help with further investigations.