A playback failure can produce several messages at once. Start with a request you can identify rather than choosing a fix from the wording of a player alert.
Keep the two observations separate
An HTTP 403 response means the server refused to process the request. CORS governs whether a browser may expose a cross-origin response to script. They describe different parts of a request, and a response can involve both.
A URL opening in another tab is therefore a different observation from a player reading that resource through a browser script. Neither observation, on its own, establishes what happened to every request needed for playback.
Capture a useful request record
- Open the browser Network panel before reproducing the failure. Keep the original test conditions for this pass.
- Identify the failed resource: entry playlist, child playlist, media, or another dependency. Record its response status and the nearby console message separately.
- Write down the page origin and the resource host. Preserve the request timing so that a site operator can locate the corresponding server-side record.
- Redact access tokens, cookies and private query values before sending the report. See the support privacy checklist.
Choose the next action from what you observed
| Observation | Useful next check |
|---|---|
| An identifiable request received 403 | Ask the resource owner to explain the refusal using its access rules and logs. |
| The console reports a CORS problem | Inspect the matching request and response headers; avoid drawing conclusions from an unrelated successful request. |
| The request never reached an observable response | Record it as incomplete evidence and investigate the connection or earlier failure first. |
After one authorized change, repeat the same test and compare the same resource. A useful outcome is a narrower, supported explanation, even if playback still needs another check.
Use the Browser Stream Test for a browser-oriented check, and keep your findings with a reproducible playback report.