The containing address is part of a relative reference
An HLS playlist may contain relative resource references. RFC 8216 defines them relative to the playlist that contains them. Moving the same text to another directory or host can therefore change the addresses a client requests. A playlist file loading successfully is not proof that its segments, alternate audio or captions still resolve to the intended locations.
Use this check when publishing a presentation you own or are authorised to relocate. Keep the original arrangement and a small nonprivate test version. Identify every resource class, not only the visible video segment lines. A child playlist can contain further relative references, so the actual delivery path may have several levels.
A hypothetical directory move
Suppose a lesson playlist originally lives under /course-a/ and refers to a segment as part01.ts. Moving the playlist under /archive/ while leaving that reference unchanged directs the client toward a segment relative to the new location. The bytes of the playlist can be identical while its effective resource graph changes. This is a publishing relationship, not a viewer's codec preference.
Resolve a few representative references with a standards-based URL tool and compare them with the intended deployed resources. Include an alternate track if one exists. Do not concatenate strings by eye or assume that a leading slash and a relative filename mean the same location. Confirm the actual requests through the authorised test client.
Review access parameters deliberately
URI resolution also has defined rules for paths and queries. A query attached to a parent playlist should not be assumed to grant or appear on every child resource automatically. The issuer's signed-link or cookie design must cover the actual requests. Do not append a private token to every URI as an improvised repair; that can be incorrect and can spread credentials into logs and unrelated destinations.
If the presentation uses redirects, inspect the real resolved path through the supported client and delivery configuration. A successful old bookmark may not represent the new published route. Keep account-bearing addresses private and use test credentials only within their authorised environment. The publisher should document the access design rather than making viewers edit resource URLs.
Validate the full presentation after relocation
Start through the new normal entry point, play across several segments, seek where supported and select required audio and captions. Verify that requests reach the intended resources and that the old location is handled according to the migration plan. Checking only the first manifest response leaves most of the relocation untested.
Record the old and new base locations, representative resolved references and tested functions without publishing live tokens. The useful result is a relocated authorised presentation whose dependency addresses and access rules remain coherent. A file move is complete when the actual viewing tasks work, not merely when the top-level playlist exists at a new URL.
Questions answered
Can an unchanged playlist request different segments after a move?
Yes. Relative references depend on the containing playlist address, so changing its location can change their resolved destinations.
Will a token in the playlist URL automatically cover every segment?
Do not assume that. URI resolution and the issuer's access design determine the actual requests. Use the documented authorised configuration.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.