Norva

The Complete Guide to Reading Live Program Information

A four-layer reading model separates the service, program event, published schedule, and viewer clock before any guide conclusion is made.

In short: Read a live guide in four layers: identify the service, identify the program event, interpret its published schedule, and compare it with the correct current clock. Then check data freshness and uncertainty. A highlighted row is an interface interpretation of those inputs—not independent proof that the listed program is airing exactly as scheduled.

A program guide compresses several kinds of data into one grid. The channel name, show title, start time, progress bar, and “next” label may look like one fact, but they come from different records and calculations. Reading them separately makes errors easier to spot.

Use the four-layer reading model

LayerCore questionTypical fieldsMain failure mode
ServiceWhere is the event listed?Name, logo, service identifierWrong or duplicate channel
Program eventWhat is listed?Title, episode, synopsis, ratingWrong or incomplete metadata
ScheduleWhen is it published to occur?Start, duration, actual times if providedStale or changed schedule
Current clockWhat time is “now” for this view?Zone, offset, date, device clockTime-zone or clock mismatch

Do not move to “what is on now?” until all four questions have plausible answers.

Layer 1: identify the service

The service record describes the channel or stream being scheduled. Confirm its name, region or variant, logo, and stable identifier when exposed. Similar branding does not prove two rows carry the same schedule. A time-shifted, regional, or duplicate service can legitimately show different events.

Use the channel-versus-program metadata guide to keep service identity from being confused with the current show title.

Layer 2: identify the program event

The event record can include title, episode, synopsis, genre, parental information, images, and identifiers. Some fields may be missing or localized. Treat an event as “the listed program,” not automatically “the program confirmed on air.”

If the same title repeats, compare episode data, description, start time, duration, and identifiers. The recurring-program fingerprint helps distinguish a recurring slot from a duplicate or repeat.

DVB’s metadata work covers program information as well as service and recording description, illustrating that these are related but distinct data domains.

Layer 3: interpret the schedule

A schedule entry needs at least a start boundary and a duration or end boundary. The DVB-I specification distinguishes published start and duration from optional actual start and actual duration. That distinction matters because schedules can change.

Calculate a provisional end as start plus duration, then keep it qualified as published unless actual timing is supplied. Follow the start-time and duration workflow for exact boundary checks.

Overlaps, gaps, and changed events are signals to investigate. They are not permission to rewrite the schedule by intuition.

Layer 4: anchor the current clock

Determine which time zone the guide uses and whether the interface displays local device time. A schedule timestamp may be supplied in Coordinated Universal Time and presented after local conversion. The IANA Time Zone Database tracks political and daylight-saving changes used by many systems; a fixed offset alone may not describe future or historical local time correctly.

Use the guide time-zone worksheet when events appear shifted or cross midnight.

Read now-and-next as a calculation

“Now” is normally the event whose interval contains the current guide clock. “Next” is the following valid event for the same service. Verify service identity, current zone, event boundaries, and freshness before trusting the labels. The now-and-next checksum provides a quick repeatable test.

A progress bar is generally derived from elapsed time divided by scheduled duration. It can look precise while the underlying schedule is stale. Read it as a visual estimate based on guide data.

Check freshness before drawing conclusions

Record when the schedule was fetched or refreshed, the coverage window, and whether a recent event boundary transitioned correctly. A guide that still shows yesterday’s event as current may have a clock, zone, cache, or source update problem.

Use the program-guide freshness audit to classify current, stale, partial, or unknown data. A blank block is similarly ambiguous; it does not by itself prove that the service is off air.

Apply an uncertainty label

Use four outcomes:

State the specific uncertainty. “Current program unknown because the schedule ended at 20:00 and no refreshed event is available” enables recovery.

Norva can present live program information from compatible sources a user is authorized to access. The completeness and accuracy of service and event metadata depend on those source feeds; the interface cannot guarantee that a broadcaster has not changed its schedule.

Common mistakes and limitations

Frequently asked questions

Is the highlighted program always live now?

It is usually the guide’s calculation from schedule and clock data. Verify freshness and actual-time fields when available.

Why can two devices show different current programs?

They may use different service variants, time zones, clocks, caches, or schedule refresh states.

Does an empty guide mean the service is unavailable?

No. It establishes only that usable schedule data is not shown for that block; service status requires separate evidence.

Your next step

See How Norva Works

Sources

See How Norva Works

Sources