How to Judge Whether Program Guide Data Is Current
A guide freshness ledger separates when data was retrieved, how far it covers, whether boundaries transition, and what the source currently reports.
In short: Check when the guide was retrieved, how far its schedule extends, whether a recent event boundary transitioned correctly, and whether the source still returns newer data. Compare a known control service and record the affected scope. A title that looks plausible is not proof of freshness; recurring schedules can make stale data look current.
Freshness describes whether displayed guide data reflects the latest usable schedule available from its source. It is different from correctness: newly fetched data can contain a bad title, while older data may coincidentally remain accurate.
Build the guide freshness ledger
| Signal | Observation | Time checked | Scope | Confidence |
|---|---|---|---|---|
| Last retrieval or refresh | App / source / service | |||
| Coverage start | ||||
| Coverage horizon | ||||
| Last boundary transition | ||||
| Source response | ||||
| Control service | ||||
| Device comparison |
Use exact timestamps and zones. “Updated recently” cannot be audited.
Separate five freshness signals
Retrieval time
When did the client last request or receive guide data? A recent request does not guarantee a changed response, but an old retrieval is a clear warning.
Coverage horizon
How far into the future does the schedule extend? A guide may be fresh for the current hour but incomplete for tomorrow. Record both start and end coverage.
Boundary transition
Did the scheduled next event become current at its boundary? Use the now-and-next checksum and note whether the transition occurred without a manual reload.
Source state
Does the compatible source currently return a schedule, an error, partial data, or no data for that service? Source availability and client cache state are separate.
Comparison control
Choose another service or device known to update reliably. If only one row is stale, the scope differs from an entire guide failure.
Run a controlled freshness test
- Record current time and zone.
- Capture the current and next event identities and boundaries.
- Wait for the next natural boundary while keeping the test short.
- Observe whether labels and progress update.
- Perform one documented refresh.
- Compare source response and a control row.
- Reopen the guide on another supported device if needed.
Do not repeatedly refresh without recording outcomes; that can erase the evidence needed to distinguish cache, source, and display problems.
Classify the result
- Current: coverage includes now, the recent transition is correct, and no newer source state is known.
- Stale: the display remains on superseded data despite a newer verified response.
- Partial: some services or time ranges update while others do not.
- Conflicting: devices or source layers disagree and the cause is unresolved.
- Unknown: timestamps or comparison evidence are insufficient.
The DVB-I specification distinguishes published schedule timing and optional actual timing. A late operational update may legitimately change what “latest” means, so record which timing fields are present.
Diagnose by scope
If one service is affected, inspect its identifier, regional variant, and schedule feed. If every service on one device is affected, inspect clock, connectivity, cache, and refresh behavior. If all devices show the same old horizon, investigate the source rather than clearing every local state.
For gaps after an otherwise current window, use the blank-schedule evidence ladder. For duplicated or conflicting intervals, use the overlap diagnostic.
Communicate the status clearly
W3C notification guidance favors clear status and recovery. Report “Guide coverage ended at 22:00; refresh returned no later events for this service” rather than “Guide broken.” Include source, service, device, zone, and check time.
Norva can display guide information supplied by compatible sources a user is authorized to access. The source controls schedule coverage and update quality; Norva support can help interpret product behavior, but no interface can invent authoritative events absent from the feed.
Avoid destructive troubleshooting
Preserve a screenshot or small ledger before clearing caches or reconnecting sources. Change one factor at a time. Do not reset unrelated progress, favorites, or library data to solve a schedule-only symptom.
Common mistakes and limitations
- Equating a recent fetch with correct current data.
- Using a recurring title as freshness proof.
- Ignoring the schedule coverage horizon.
- Refreshing repeatedly without a baseline.
- Treating one stale service as a system-wide failure.
- Reporting “live” without a timestamp and zone.
Frequently asked questions
How recent must guide data be?
There is no universal age threshold. It must cover the relevant time and reflect available updates for the intended service.
Can a guide be partly current?
Yes. Coverage can vary by service, date range, metadata field, or device cache.
Does a correct progress bar prove freshness?
No. It may be calculated from old boundaries that happen to align with the current clock.