Check that the disagreement is a consistent time difference
Begin with a guide that identifies the intended station. Compare several known programme boundaries rather than a single current label. If only one channel has another station’s schedule, use channel mapping. If the guide has no data, inspect its import. A time correction is useful only after the identity and data are established.
For an original arithmetic example, suppose programmes expected at 19:00 and 20:00 are both displayed one hour earlier. That is a consistent displacement worth testing. If the differences vary independently, one global correction would hide one mismatch while creating another.
Apply the documented display correction
Desktop Settings, EPG, EPG time offset accepts a minute correction: positive for programmes shown too early and negative for too late. Keep the original value before editing and inspect the exact field in the installed build.
In the example above, test positive 60 and inspect the same two programme boundaries. Do not also change the operating system clock or edit the XMLTV file. Those simultaneous changes would remove the clear relationship between the adjustment and the displayed result.
Check the global scope and archive boundary
This changes display globally, while stored guide, catch-up and recording times remain provider-owned values. Treat a corrected on-screen schedule and a working archive request as separate acceptance checks. Keep the unchanged source reference with the comparison.
Inspect another source that previously looked correct before leaving a global offset in place. If one feed needs correction and another does not, record that conflict and ask the source owner about the underlying timestamps. A single global field cannot express arbitrary independent corrections for every feed.
Revisit the decision when the source changes
Keep the accepted offset with the date and a known programme comparison. After a feed correction or seasonal clock change, compare again before accumulating another adjustment. A previously useful correction can become an additional error after the underlying source is repaired.
The outcome should be a readable guide whose timing has been checked across the relevant views. It should not be a promise that the display setting fixes account authorization, source archive duration or recording availability. Those are different parts of a service.
Questions answered
How should I choose a small timing comparison?
Keep the same station and compare two known programme boundaries before and after one change. Retain the original field value.
Why inspect another source after the correction?
A global display choice can affect more than the feed being investigated. Check a previously correct source before accepting the setting.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.