AVPlayer Invalidates Media Stream on Pause

Starting with iOS 10 beta 4 I am seeing AVPlayer fail with the following error when a pause is issued to it and it begins to receive the same manifest over multiple time periods. This seems to be occuring after the player receives the same manifest 3-4 times.


I have validated the manifests, there are no changes, and this code works fine on iOS 9 with no errors at all and has been in place for several years in production.


The sequence of events are:


1) Receive an AVAssetResourceLoaderDelegate request for the manifest.

2) Return a current version of the manifest.

3) iOS 9 returns to the first step at a frequency of 1/2 the target duration of the media content, iOS 10 beta 4+ creates the error below after a few tries.


This is a Live playlist which consists of 5 media segments that roll off of the manifest as each new media segment is produced. The manifest version is 4 and a sample manifest is included below.


Any suggestions for why this would start failing as of beat 4 and what areas to search, in light of the fact this works on iOS versions earlier than beta 4 and iOS 10.


2016-08-18 16:30:16.655633 Testing[575:208902] ++++ General Notification Received: __CFNotification 0x170841d40 {name = FailedToPlayToEnd; object = <CMBaseObject: instance<0x1701fdd00> storage<0x1701fdd20> class<0x1a9456830> allocator<0x1ae5efbb8>>{}; userInfo = {

CFError = "Error Domain=CoreMediaErrorDomain Code=-12880 \"Can not proceed after removing variant\" UserInfo={NSDescription=Can not proceed after removing variant}";

Result = "-12880";

}}


#EXTM3U

#EXT-X-VERSION:4

#EXT-X-TARGETDURATION:1

#EXT-X-MEDIA-SEQUENCE:1

#EXTINF:1.019,

http://localhost:49585/f1471551876.ts

#EXTINF:0.989,

http://localhost:49585/f1471551878.ts

#EXTINF:0.964,

http://localhost:49585/f1471551881.ts

#EXTINF:0.972,

http://localhost:49585/f1471551885.ts

#EXTINF:0.979,

http://localhost:49585/f1471551890.ts

Replies

Further research and testing using Safari and manipulating my solution has revealed the following:


1) If Safari or AVPlayer sees a manifest unchanged for 3-4s when it is a live streaming event, the media stream is declared corrupt and the playeritem is failed.

2) If Safari is paused but the stream continues provide new media segments, then it will cache about 30s of live content. Over this threshold when playback is resumed, it will jump to the current live position. AVPlayer seems to follow this same behavior pattern.


iOS 9 handles this event with no problem - it remains paused, asks for the manifest on a 1/2 target duration cycle, and once a new manifest arrives publishing a new media segment, it resumes playback.


This seems to represent a major change in playback behavior, indicating that Safari and AVPlayer will fail a media stream more rapidly in iOS 10 if it appears the stream has stalled.


Has anyone else seen this, including Apple, and if so, how are you handling it? I have a potential workaround but I would like to see if there are any alternative approaches being tried.

Hi, we had the same problem. However, the real issue was server-side: an incorrect setting in our webserver. The maxAge for the playlist was set to 20 seconds whereas chunks are 5 seconds long, thus the playlist was cached for too long time. That’s why 3/4 requests in 15 seconds time were returning always the same playlist.

@robvandy55 Have your (or has anyone else) found an app-side solution to this yet? We're experiencing the same behavior. Changing server settings hasn't helped.

Im having the same issue, with changing server settings not helping in the app.

I have checked other forums with my error code and message mentioned separately.

My error message is "Cannot proceed after removing the variant," while the code is 12645, Which is seemingly associated with another error.

That's highly confusing, and especially since I'm not using a HLS player, instead one the app uses.

Has there been any update on this? We are having the same issue where AVPlayer stalls out if multiple duplicate manifests are sent in a row. We have legitmate use cases and a signifcant amount of segments listed per manifest so it is not due to the player simply running out of segments to play.