FOCUS Investigate playback problems

Find sudden incidents and persistent issues across players, devices, content and delivery. FOCUS identifies affected session groups, investigates what connects them, and sends the responsible team an alert with the results and supporting evidence.

Book a demo · See an investigation result

5M+ playback sessions processed daily in production.

No proprietary player SDK required

Start with CDN logs and reconstructed sessions. Add CMCD v1 or v2 player context where available.

Find the affected cohort

Machine learning looks for changes and unusual patterns, including deteriorating QoE or indirect signals such as unusually short sessions. Shared attributes help narrow the investigation, for example to an app version, device, content item, delivery path or combination of these.

An app regression or a device incompatibility can remain hidden in a service-wide average. FOCUS examines the group that is affected.

FOCUS in motionDelivery example

Reconstructed playback sessions

FOCUS finds related signals within the session population

FOCUS

Agent investigation
Simultaneous rebufferingSame CDN PoP
  • Check CDN status API
  • Pull per-segment CDN session logs
  • Check domain and customer knowledge
Investigation finding

Slow segment delivery at one CDN PoP

Affected cohort
Simultaneous rebuffering · Same CDN PoP
Supporting evidence
Slow transfers in affected sessions’ CDN logs
Proposed follow-up
CDN operations: investigate the affected PoP
  • DeliveryCDN operations
  • MediaEncoding / packaging / CMS
  • AppsWeb / TV / mobile

Illustrative sequence, not live data or measured proportions · Routing follows your team ownership

Investigate the context Explain the likely cause

Agents use streaming expertise, specialist tools and your service context to examine the affected sessions. They connect the signal with available evidence, assess playback impact and explain likely causes and what remains uncertain.

Evidence may include CDN requests, player-reported errors or additional service logs. Supported CMCD v2 events can supply player context that a delivery log alone does not contain.

What happened after the 404?

An HTTP error needs session context. A successful retry and a player failure call for different follow-up.

HTTP 404 in a request log

Playback continues

  1. Request fails
  2. Retry succeeds or buffered media remains available
  3. Playback continues

This can include a player requesting a live segment before it is available.

Errors may not warrant an incident.

Playback is affected

  1. Request fails
  2. Playback stalls, quality changes or the session ends abnormally
  3. FOCUS investigates context and supporting evidence

A candidate signal; timing alone does not prove causation.

Illustrative scenarios. Conclusions depend on the collected evidence.

The finding And the evidence behind it

The investigation result brings together the affected cohort, playback impact, likely explanation and proposed follow-up. Supporting records help the team trace the issue and decide what to change.

The excerpt is from a device-related investigation. Its remaining uncertainty is explicit, so the team knows where further evidence is needed.

Use the FOCUS interface to review discovery signals, inspect investigations and manage feeds. Dashboards remain available for further playback and delivery analysis.

Anonymised extract from a generated FOCUS ticket

Short playback sessions on legacy TV devices

Problem
Playback ended unusually early within a specific on-demand TV-device cohort.
Investigation
Sampled sessions entered playback, reported an error and stopped progressing shortly afterwards.
Assessment
The evidence points to a failure along the legacy playback path. The available telemetry does not establish whether the player, device or backend is responsible; server-side logs and HTTP status codes were unavailable in this case.
Evidence
Affected-cohort and playback-path analysis linked from the ticket.
Generalised from an actual investigation. Customer and incident identifiers have been removed.

Put findings in the right hands

Describe which findings belong with which team. FOCUS delivers relevant alerts and investigation results through configured Slack, Teams, Jira or email feeds, with the available supporting evidence.

For a delivery issue, the owner may be your CDN or cache operations team. With a third-party CDN, route through your distribution team or, with your authorization, directly to the provider. Application and media issues follow their own agreed owners.

Notifications follow investigation and a relevance assessment. Routing reflects your responsibilities and escalation agreements.

Sudden incidents Persistent issues

Examples from customer deployments show the range of playback problems. Available telemetry and investigation methods varied by case.

Player and content failures

Missing live subtitle assets interrupted playback in a web player. In another investigation, unusually short sessions led to additional diagnostics that identified a problem with protected subtitles; corrected packaging restored playback.

Device and application issues

Device cohorts remained in SD when HD was expected. Repeated restart attempts also exposed the wrong programme opening around a broadcast transition. Shared session properties helped define which playback paths to examine.

Delivery problems

Slow segment delivery was linked to rebuffering in affected sessions. Matching CDN request records supported targeted provider-side changes and follow-up on playback behaviour. Other investigations found content missing on a specific delivery route.

A delivery example From rebuffering to a CDN PoP

FOCUS isolates the affected cohort to a PoP within one CDN and connects playback impact to slow segment transfers. Matching CDN-log samples give the responsible team specific requests to inspect.

The illustrative finding below shows the handoff. Open the supporting evidence to see how playback and delivery records connect.

FOCUS isolates a rebuffering cohort to one PoP of one CDN. Playback impact is connected to slow segment transfers and matching session and request records. A prepared handoff gives the CDN team request-level evidence to investigate the delivery path and verify recovery.
See what FOCUS detected
Aligned playback-buffer and CDN-request timelines for one session. A slow segment transfer starts before the buffer drains. Rebuffering starts when the buffer is empty. After the segment is received, the buffer refills and playback resumes. The request returns HTTP 200.
Illustrative product view.

Check what changed after the fix

After the responsible team applies a change, compare new sessions with the earlier affected cohort. For a delivery fix, check transfer behaviour and playback quality. For a player or content fix, examine the relevant errors and playback outcomes.

The available data determines what can be validated. Investigation results and supporting evidence give the team a starting point for that comparison.

Start with a focused investigation scope

Choose an operational question and evaluate the findings with your team. Optional professional services support incident follow-up, technical coordination and longer-term improvements.

Book a demoGetting started