DRM licence acquisition failures: tokens, certificates and networks
The most common playback failure on protected catalogues. The message the viewer sees is generic; the causes are four distinct things, each with a different owner.
What the viewer sees
An authorisation error or a "content not available" message, playback that starts and stops within a second, or licence requests that succeed on one attempt and fail on the next. Unprotected streams play normally. The behaviour differs between device manufacturers using the same DRM system, which is what makes it look random.
The four causes
The licence request carries two things that can be wrong - the device's identity and your authorisation token - and travels over a network that can fail to a server that can be slow. Almost every licence failure is one of those four.
- Token problems: a token that expired between sign-in and pressing play, was issued for a different asset, or is not refreshed for the licence request specifically.
- Device certificate problems: a device whose DRM certificate is revoked - typically rooted or tampered hardware - or one that never completed provisioning because it had no connectivity or a wrong clock at first launch.
- Licence server problems: a server that is unreachable from the device network, or responds too slowly for a timeout tuned for a fast connection.
- Network interference: corporate proxies, hotel Wi-Fi and some security appliances that block or rewrite licence traffic.
Build so failures are rare
Validate the token before starting playback rather than discovering it is stale from the licence server's response. Where the platform allows, fetch the licence before the viewer presses play - during the detail screen, for instance - so the request has already succeeded when playback starts and a slow server never shows up as a startup delay. Set licence request timeouts realistically for television networks and retry with exponential backoff, because a licence server under load is a transient condition, not a permanent one.
Licence policy should be designed with fallbacks: if the device cannot satisfy the requirements for HD, the sensible outcome is standard-definition playback under a policy the device can meet, not an error. Whether that is permissible is a rights question to settle with the content owner in advance.
Build so failures are diagnosable
Map each failure class to a distinct message. A viewer with an expired session can sign in again; a viewer on a rooted device cannot fix anything, and telling them the content is unavailable is both accurate and kinder than a retry loop. Log the failure class, the device model, the DRM security level and the licence server response on every failure, and keep a device quirks list - the models with known certificate problems, the firmware versions that mishandle a particular licence response - because the same devices come up again and again.