Media diagnostics · Primary-source explanation; no UK IPTV implementation or account test. Instructions are based on publisher guidance; a UK IPTV account was not tested on this platform.
Read the two headers separately
An HTTP response can identify a media type and also describe a content coding such as gzip. RFC 9110 defines Content-Encoding as coding applied beyond that inherent in the media type. These are different layers. A compressed guide document, for example, is still guide data after its HTTP content coding is removed; it has not become a video codec.
Use a hypothetical diagnostic comparison
Suppose a player receives a gzip-compressed text playlist and then requests video segments referenced by it. The successful decompression of that text does not establish that the device supports the video codec in the later segments. Conversely, an audiovisual decoder error should not automatically be blamed on the text response’s gzip setting. Preserve the exact request and stage rather than merging several responses into one format description.
Avoid misleading quality conclusions
A smaller transferred text response does not imply a lower video bitrate, a new resolution or a lossy re-encode of the programme. If the question concerns picture quality, inspect the actual media representation and the selected variant. If it concerns whether the response can be interpreted, inspect its declared coding and the application’s handling. The same word compression can describe very different operations.
Make the support record explicit
Record Content-Type, Content-Encoding and relevant media-format details in separate fields, without exposing private URLs or authentication data. State whether failure happened before the playlist was understood or after a media resource was requested. This gives the publisher a reproducible boundary to examine and avoids a generic recommendation to change every compression setting. No UK IPTV response headers or delivery design are asserted by this explanation.