Erratic playback start when AirPlay is already enabled

[defagos]

When AirPlay has already been enabled, attempting to start playing a media might succeed or not. This is a regression, as this was working correctly until version 1.5.2.

Issue overview

• [X] Incorrect behavior
• [ ] Feature request
• [ ] Crash
• [ ] Help / documentation
• [ ] Other: classification

Environment information

• Library version: 1.6
• iOS version: Any
• Device: Any

Reproducibility

• [X] Always reproducible
• [ ] Difficult to reproduce

Steps to reproduce

1. Open Letterbox demo
2. Enable AirPlay from the control center
3. Play different medias from the list in a row. More often than not, playback will not correctly start.

[defagos]

This is probably a side-effect of iOS 11. The fact that the issue can be discovered by comparing versions 1.5.2 and 1.6 of the demo is probably related to the fact that the first was built with the iOS 10 SDK.

[defagos]

Playback interruption is triggered by the code we use to stop livestreams (instead of pausing them).

This is not a regression, as the code itself has not changed.

What has changed is the fact that the rate of the player somehow gets set to 0, inducing a change to the paused state. Moreover, as is the case for a long time, the stream type can be briefly incorrect when using AirPlay (and incorrectly reported to be live, even for on-demand medias). Both conditions being fulfilled, playback is stopped.

[defagos]

What is really strange is that the same media (19h30 example from Letterbox demo, whose type is incorrectly detected as livestream or unknown when played over AirPlay), behaves just fine in the SRG MediaPlayer demo (the type is immediately detected as on-demand stream).

What is different with Letterbox demo or Letterbox controller / service?

[defagos]

I tried creating a small project example with only SRG MediaPlayer 2.2 as dependency (integrated with Carthage). In the playback state did change method, I log the stream type and perform the same kind of test we perform in Letterbox for livestreams (stop if a stream is live and paused).

The stream type is incorrect and the player stops playing the 19h30 media.

The problem is therefore related to release builds of SRG Media Player. The behavior is different for some reason.

The problem is therefore not in Letterbox.

[defagos]

@vpdn reported an issue when playing http://download-audio.srf.ch/delivery/world/d3c4f2e5-b10f-40ae-bc80-2659e4603781.mp3.

In the SRG MediaPlayer demo, the stream plays fine, but in the small example I created based on SRGMediaPlayer.framework, I get the following error:

2017-12-14 15:37:51.030714+0100 SimplePlayer[1706:679413] [Controller] Playback did fail with error: Error Domain=ch.srgssr.mediaplayer Code=0 "The media cannot be played" UserInfo={NSLocalizedDescription=The media cannot be played, NSUnderlyingError=0x1c0446c90 {Error Domain=AVFoundationErrorDomain Code=-11800 "The operation could not be completed" UserInfo={NSLocalizedFailureReason=An unknown error occurred (-1022), NSLocalizedDescription=The operation could not be completed, NSUnderlyingError=0x1c04452b0 {Error Domain=NSOSStatusErrorDomain Code=-1022 "(null)"}}}}

Both issues are probably related somehow.

[vpdn]

Cool, thanks for looking into it! We would like to release the Sport App with Letterbox support, and this is the last blocking issue.

[defagos]

We want to release a new version of our Play apps tomorrow. If everything goes well the fix will be available tomorrow (though it will probably be quite hard to find).

[defagos]

The problem we have with AirPlay is not even related to AirPlay: Without enabling AirPlay, the stream type is incorrect.

Probably that the incorrect AirPlay behavior we have is just a consequence of a deeper problem about tracks, time ranges, etc. in framework builds.

I tried adding a debug version of SRGMediaPlayer.framework, the problem is the same. It seems that we are not facing a debug vs. release inconsistency.

[defagos]

@vpdn I understood why I couldn't play your mp3 with my simple demo: This is an HTTP URL and App Transport Security prevented me from playing it.

What are your ATS settings? Do you allow all HTTP content to be accessed?

[defagos]

Well, first intuition wasn't entirely right: I simply added the basic player implementation I created initially to the media player demo. The behavior is the same.

When playing the 19h30 stream with this player, the player initially thinks the stream is a live one. When playing it with the SRGMediaPlayerViewController, the stream type is correctly guessed from the start.

The issue might therefore be related in how the controller is instantiated (in code for SRGMediaPlayerViewController, as a storyboard object in my simple implementation). The view and the associated layers are for example not created in the same way, which could be the cause of the issue.

[defagos]

I understood what is different: In my implementation, I catch the preparing playback state change notification, where the stream is found to be live. This is by construction not the case with the SRGMediaPlayerViewController player, which appears after its controller is being prepared. Thus the different behavior.

The problem is therefore probably just related to an incorrectly reported stream type when preparing the player (should probably be unknown).

This issue must be fixed and covered with a unit test. It is probably not related to the AirPlay instabilities we have.

[defagos]

The problem is with our trick to detect when AirPlay is being enabled. It was valid before iOS 11 but is now broken.

Such tricks are stupid anyway. We'll find something better.

[vpdn]

@defagos Aaahh I think you're right with the SSL. 🙈 Crap, haven't checked that since taking over the app from the agency, maybe it has always been a problem. Thanks for debugging!!