A live player is healthy only while the viewer session keeps moving. A poster frame and a successful manifest request can both exist while the audience is staring at a frozen picture.
Test the browser path that Callaba publishes
Start with a source you have already checked in Multiview. Add it to a Web Player, then open the generated viewer URL or embed on the phone and browser your audience will use. Multiview confirms that the source reached the operator. The Web Player tests the separate browser path.
The Web Player user guide shows where to create the player and copy its viewer link. External CDN regions, identity providers and real-user devices still need their own checks.
Follow one session from click to moving video
Begin before the page receives media. Record whether the viewer was admitted, which URL the player selected and when loading began. Then watch for metadata, a decodable frame, audible sound and continued motion. They belong to one session, but one does not prove the next.
The browser exposes useful events. loadedmetadata means basic media information is available, loadeddata means the current frame has loaded, playing means playback can proceed, and waiting means it has paused for more data. Keep their timestamps instead of reducing all four to “the player worked.”
Keep a session receipt, not a green badge
Measure the first real frame
Start at the viewer’s click or admission. Stop when the current programme is visible and playback time begins to advance. A poster, spinner or decoded black frame is not the result.
- 00.000
- Viewer opens the exact public URL
- 00.340
- Access granted; intended source selected
- 01.820
- First current frame and intended audio
- 31.820
- Playback still moving after representative motion
- 42.600
- Short network interruption recovered without reload
Repeat this on the devices and browsers that matter. A desktop result cannot certify a phone, an embedded webview or a television. One slower supported device often exposes an ambitious rendition ladder or heavy page before a new laptop does.
Read a pause in context
waitingPlayback needs more data. Compare the time with buffer level, manifest advancement and network requests.
stalledThe browser is trying to fetch media but data is not arriving as expected. It describes a symptom, not the cause.
errorLoading or decoding cannot continue. Preserve the media error code and the failed request beside it.
One brief wait during startup may be harmless. Repeated waits after playback begins are different. Count them, record their duration and compare them with the current playback time. A five-second freeze still matters even when it resumes silently.
Identify which part failed
- Access: the viewer lacks a valid token, is outside the allowed audience or receives a forbidden response. Retrying media will not repair authorization.
- Media: the page opens, but the manifest, segment, codec or audio track fails. Preserve request status, content type and media error.
- Interface: video plays, but controls, captions, keyboard focus, full screen or responsive layout block the real task. That is still a failed viewer session.
Close the test with facts someone else can reproduce
Keep the viewer URL, device, browser and operating-system version, access mode, selected rendition, time to first picture, selected audio, freezes, media errors and recovery after a short network interruption. Add one screenshot after playback has visibly advanced.
A useful result sounds like this: “An authorized viewer on this phone opened this URL, saw current video and heard English audio in 1.8 seconds, played for ten minutes and recovered after a five-second network interruption without reloading.”
Primary references: MDN HTML video element and media events and MDN stalled event reference.
