Basic error reporting

[defagos]

As a user I want to be informed when playback failed for some reason.

Acceptance criteria

• Playing an unknown URN ends with a failure.
• Attempting to play a content without network available fails with an error.
• The user is presented with a basic message informing them about the error.

Tasks

• Ensure media player errors are correctly reported.
• Ensure network errors are correctly and consistently reported (URN and URL examples).
• Ensure resource loader errors are correctly identified (e.g. 404).
• Identify IL blocking reasons.
• Ensure network errors are correctly localized.
• Ensure resource loader errors are correctly forwarded to the player.
• Use CFNetwork bundle for error localization if helpful.
• Display basic error message.
• Deal with the empty player case.
• Ensure nice error messages are displayed to the user.
• Ensure all medias are playable (e.g. MP3 and HLS). Not possible without a new approach, see Resource loading overhaul #106

[defagos]

Correct resource loading error propagation requires several conditions which need to be investigated. Until I have more information I updated the current knowledge we have on an existing SRG Content Protection issue.

[defagos]

Resource loading error propagation is surprising (and really poorly documented 😭). It appears we need:

• Integer errors with code different from 0.
• A resource with an m3u8 or m3u extension to be loaded (list likely not exhaustive). No extension or other playback-related extensions like mp3 do not work.

The first requirement means that we cannot use Swift enums with associated values to model HTTP errors (e.g. using an associated value to store the status code). We also need to be able to associate a description message, so the simplest is likely to use NSError instead and forget about Swift types for errors reported by asset resource loader delegates.

Note that when errors are forwarded to the player item correctly the description is still not associated with the localized description NSLocalizedDescription but with a simple description NSDescription (for which no user info key constant is available AFAIK):

Error Domain=ResourceLoaderErrors.PlaybackError Code=1012 "The custom error message" UserInfo={NSDescription=The custom error message}

So another error conversion step is required to deliver a localized error in the end.

[defagos]

There is still an issue with adding an arbitrary extension: Attempting to play an MP3-backed URN with the m3u8 extension does not work. So we likely need to be a bit smarter.

[defagos]

The resource loading issue cannot be fixed, at least not if we want to have correct error propagation. The extension appended to any asset URL namely secretly determines how resource loading will work. The result differs whether this extension is missing, m3u8 or mp3, for example:

• No extension: HLS and MP3 URLs play fine, but errors are not propagated.
• m3u8: HLS URLs play and errors are propagated but MP3 URLs do not play.
• mp3: MP3 URLs play but errors are not propagated and HLS streams do not play.

If we provide no extension we can obtain the same effect by providing the MIME type with a private option:

let asset = AVURLAsset(url: URLCoding.encodeUrl(fromUrn: urn), options: [
    "AVURLAssetOutOfBandMIMETypeKey": "application/x-mpegURL"  // or "audio/mpeg"
])

but this only confirms that the behavior of the AVURLAsset is determined at creation time and cannot be changed afterwards when redirecting to a stream URL in the resource loader.

Since we never know the extension associated with a URN (and we could also have different ones) this proves the current approach is sadly doomed to fail.

The current work is not lost, though, as error management is still improved. But we need to completely implement playlist management in a new way so that media compositions are loaded before item creation.

[defagos]

I'll still merge the changes made in this issue since they are needed to properly load resources and handle errors, but a new approach is required to load assets, otherwise we cannot have at the same time reliable playback and correct error reporting (see #106).