Start with what the player received
A live presentation and an ended presentation can use similar-looking playlist text. When diagnosing an event that stops progressing, record the request status, the received playlist and the relevant time privately. Do not interpret a spinner alone as proof that the event has ended. The player may have failed to fetch information, received an unchanged representation or encountered a later media problem.
Read the explicit end marker
RFC 8216 defines EXT-X-ENDLIST as indicating that no more media segments will be added to that media playlist. It is a statement in the received presentation metadata. The RFC also describes EVENT and VOD playlist mutability. These terms are not account-expiry messages or a count of programmes available. Their meaning belongs to the HLS presentation being examined, not the viewer’s wider service catalogue.
Keep failure and completion separate
Consider a hypothetical event whose final playlist contains an end marker. That differs from a still-running event where the next playlist request fails. In the first investigation, the question concerns the supplied ending and the player’s handling of it. In the second, retain the request failure and any useful publisher status. Repeatedly treating both as a subscription renewal problem would skip the evidence that distinguishes them.
Report a sequence of observations
A developer-facing report should describe the last successful media position, whether the playlist changed and whether the end marker was actually present. Avoid inventing its presence from an on-screen message. Review private captures before sharing them. This is a standards-based diagnostic distinction, not a claim that UK IPTV’s live events were monitored or that every stopped programme has the same cause.