You inspect a stream, return later, and the playlist no longer contains the same entries. Before calling that a player fault, record what changed and when. A moving source needs a different test record from a fixed file.
Read the end marker with care
In HLS, EXT-X-ENDLIST declares that no further media segments will be added to that media playlist. Live playlists can change over time. The absence of the end marker alone is not evidence that a stream is healthy or actively updating.
Label your observation narrowly: “end marker present”, “end marker absent”, or “not checked”. Avoid turning that one label into a conclusion about the whole viewing experience.
Make a two-observation worksheet
- Keep the original entry address and identify the media playlist being compared. Do not switch variants between observations without noting the change.
- Record the first observation time, the visible first and last entries, any media sequence value you observed, and whether an end marker is present.
- Take a second observation after a reasonable interval for that service. Record the actual elapsed time rather than claiming a universal reload interval.
- Compare the two records and separately note what the player displayed: continuing playback, a stall, an error, or a completed presentation.
Keep uncertainty in the conclusion
If the visible entries changed while playback continued, record both facts. If they stayed the same, do not immediately label the cause as caching, an encoder failure, or a player bug. Your comparison describes the observation; it does not identify a cause by itself.
For a reported stall, retain the time and the request closest to the event. Ask the source operator to compare that evidence with its own records. Repeating a test later can be useful, but it is a new observation rather than proof that the earlier report was wrong.
Inspect the current source in the Playlist Checker, then observe it in the M3U8 Player. Add the times and limitations to your playback report.
Reference
RFC 8216: HTTP Live Streaming, sections 4.3.3.4 and 6.2.2. This article proposes a recording method; it does not infer a source failure from a single playlist snapshot.