XMLTV / applied guide-data decisions · 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.
Keep the request and import outcomes separate
An application can receive a successful HTTP response and then fail to use its body as guide data. The response status describes the request result; it does not certify every later parser or mapping operation. Record both the request status and the actual application message rather than saying the feed works merely because a download returned bytes.
Compare a hypothetical unexpected document
Imagine an address expected to return an XMLTV document instead returns an HTML account notice with a successful response status. That body can be readable text and still be the wrong input for the guide parser. The correct next question concerns the supplied document and legitimate access state, not the programme timezone or the television’s video decoder.
Check the expected structure privately
XMLTV defines its tv document and programme structure. An authorised importer should verify the actual returned type and expected document content, using the publisher’s supported route. Do not paste an entire private response into a public validator. A source can also contain channel information without programme entries, so a successful XML parse is another distinct milestone rather than proof of a populated schedule.
Report the precise boundary
State that the request succeeded, the response was an unexpected document, or the expected XMLTV data parsed but did not populate the guide, as applicable. These cases need different follow-up questions. This example explains a diagnostic boundary and asserts no observed UK IPTV endpoint, sign-in behaviour or performed guide import.