A redirect tells an HTTP client to make a request at another location. A playlist that redirects is not necessarily broken, but the player must handle the response appropriately. Keep the issued URL intact and report loops or unexpected destinations privately.
Know when this reference applies
Start when the application mentions a redirect, support confirms one, or a documented player diagnostic identifies the changed destination. Do not open a private media address in multiple public checking sites to discover its route. For most viewers, the exact wording and the time are enough to begin. A browser opening an unrelated public homepage says little about the player’s authenticated request.
Describe the transition safely
A fictional report could read: "The list request starts at invalid.example and the player reports a redirect to media.invalid.example; it then repeats the same error." These invented hosts are examples, not settings. For a real report, share only the minimum host-level detail requested through the verified support route; paths and queries may contain private account information.
HTTP defines redirection behaviour, and authentication information requires care when the request target changes. Do not work around an unexpected host by copying an Authorization header, a password or a token into another application. URI syntax also means that changing a path or query can change the resource rather than repair it.
Keep the comparison narrow
Note whether the failure occurs when importing the catalogue or when playing an item from an already loaded list. Include the app edition and whether this began after an update. If the provider gives a replacement address, treat it as a new authorised instruction and retain the old record privately until the new one is verified. Avoid maintaining several guessed variants whose history is unclear.
- Preserve the original supplied value.
- Record the visible redirect or loop message and time zone.
- Ask whether the destination and input method are expected.
- Use only the replacement route confirmed by the authorised provider.
Confirm the intended destination
Support should be able to confirm whether the route is intentional and whether the chosen player supports it. A successful follow-up request establishes that route at that moment, not that every item or future redirect will succeed. If the app never exposes redirect information, do not label an ordinary timeout a loop. Provide the observed behaviour and let the party operating the endpoint inspect its own logs. This reference gives no account access or server-management instructions.
Sources and review
- RFC 9110: HTTP Semantics — RFC Editor / IETF
- RFC 3986: Uniform Resource Identifier (URI): Generic Syntax — RFC Editor / IETF