Save a sequence of observations
If a live playlist appears stuck, keep at least two response bodies with fetch times and response headers. Compare the media entries and sequence state. A screenshot of a playback clock cannot establish whether the origin stopped generating media or a delivery layer served an older manifest.
RFC 9111 defines Age as an estimate related to response generation or validation. It is not a direct measurement of how far a viewer is behind the event. Encoding delay, publication timing, buffering and playback position belong to a different timeline.
Use the headers as evidence
Record Age, Date, cache directives and validators where present. An increasing age alongside an unchanged body suggests a different investigation from a freshly validated unchanged body. Neither observation alone identifies the faulty component.
Lack of an Age header does not prove a request reached the origin. Compare available release logs and cache information rather than making that assumption. Also check clock consistency before subtracting wall-clock timestamps from different systems.
Check the resource's intended behaviour
An accumulating event, a rolling live window and a completed presentation have different reasons to change or remain stable. Confirm the publication state before calling an unchanged response a cache failure. A completed playlist may correctly stay unchanged.
If freshness policy is revised, check manifest delivery separately from stable media segments. One blanket lifetime rarely expresses both publication needs accurately. This is an observation plan, with no claim that a real IPTV Europe manifest was fetched.
Questions answered
Does Age 20 mean the player is exactly 20 seconds behind live?
No. Response age and playback latency describe different things.
Does a missing Age header prove there was no cache?
No. Preserve other response and publication evidence before deciding.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.