ccextractor XMLTV output for ATSC TS does not include mapping of friendly channel names to channel_ID values

[TPeterson94070]

The recent #1773 fix has enabled XMLTV output for ATSC inputs, but it leaves out channel ID matching between ID numbers and friendly names, such as virtual channel numbers and call signs.

[x15sr71]

Thanks for opening this, @TPeterson94070

This is a natural follow-up to #1773. I’ll take this up next and work on mapping TVCT channel metadata (virtual channel numbers / short names) into the XMLTV output.

I’ll post a PR here once it’s ready.

[x15sr71]

Hi @TPeterson94070,

I’ve now updated the XMLTV output to propagate ATSC VCT metadata into the entries.

ATSC XMLTV output now includes both virtual channel numbers and VCT call signs:

<channel id="1">
  <display-name>5.1</display-name>
  <display-name>KPIX-TV</display-name>
</channel>

Specifically:

• Friendly channel names from the VCT short_name are included.

• Virtual channel numbers (major.minor, e.g. 5.1) are also emitted.

• Both are linked to the existing channel IDs using multiple elements, in a spec-compliant way.

I’ve attached a sample XMLTV file generated after this change so you can verify the output on your end.
Please take a look and let me know if this matches your expectations, or if you’d like the channel naming/mapping adjusted further.

20251206ch29FullTS_epg.xml for 20251206ch29FullTS.ts.

[TPeterson94070]

@x15sr71 , thanks for such quick action! I'm not sure how it would work to have two elements with the same name, though. If there's not another choice for "virtual channel" in the XMLTV spec, perhaps it would be better to put both of the names in a single tag, say, <display-name>5.1, KPIX-TV</display-name>?

EDIT: Hmm. I've just looked at the sample on the XMLTV website and I see that you did the same thing with multiple tags using the same ID. That seems odd to me still. I'll review that site more and post an update.

[TPeterson94070]

@x15sr71 , I've read through the XMLTV DTD sample description and see that it explicitly says that there can be more than one <display-name> defined. But I'm unclear on how the parser is supposed to handle such. Furthermore, it leaves up to us how to define these and IMO it would be better to have one tag defining both virtual channel and call sign. OK?

[x15sr71]

@TPeterson94070, that’s a fair concern, especially from a parser perspective.

I spent some time reading through the XMLTV DTD comments and examples. As you noted, the DTD explicitly allows more than one <display-name> per <channel> (display-name+). It also makes an important distinction: while the ordering of <channel> elements themselves is not semantically significant (channels are looked up by ID), the DTD comment for <display-name> states that names should be listed with the most canonical/common first and more obscure ones later, which indicates that the ordering of <display-name> elements is meaningful by design.

Relevant source ( around line 216 - 236 )

---

On parser behavior: this suggests an intended model where XMLTV-consuming applications or EPG importers may treat the first <display-name> as the primary label and any additional entries as alternates. This interpretation is reflected in the official XMLTV examples and is also seen in real-world consumer implementations — for example, the O’Reilly/xml.com XMLTV article maps channel IDs to the first <display-name> element (getElementsByTagName("display-name").item(0)), aligning with the DTD’s “more canonical first” guidance.

---

I agree that the spec intentionally leaves this open to interpretation, so choosing a single combined display name is also a reasonable design preference.

From an implementation standpoint, keeping the virtual channel number and call sign as separate display-name entries preserves them as atomic values and avoids requiring parsers to split or interpret a combined string like 5.1, KPIX-TV, while still allowing different UIs to choose which identifier to display.

That said, if a single combined display name would be preferable for your workflow, I’m happy to adjust the output (or make it optional). Let me know what you’d prefer — and if the maintainers agree on a direction, I’ll be happy to implement it.

[Rahul-2k4]

Thanks for the detailed explanation and spec references — this makes sense.
I reviewed the XMLTV DTD as well, and the allowance for multiple entries with canonical-first ordering seems intentional.
Keeping virtual channel and call sign as separate display-name elements feels cleaner and avoids downstream string parsing.

[TPeterson94070]

I still like having a single <display-name> element with both VC and call sign included but, since that seems not generally the custom, I can deal with the multiplicity.

[x15sr71]

Thanks for the feedback, @TPeterson94070.
I’ll go ahead and open a PR with this approach.

[TPeterson94070]

@x15sr71 , thanks for finishing this so thoroughly! I can now implement a PSIP-based EPG for my free PVR app in the Windows Store. It should also work with DVB sources, I think, but I'll have to look more into that since i don't have any such files to test at hand.

[x15sr71]

@TPeterson94070, Thanks for the clear report and constructive discussions. Really glad this helps with your PSIP-based EPG work, If you end up testing it with DVB sources later and notice anything interesting, I’d be happy to take a look when time permits.

[TPeterson94070]

@x15sr71, if you have time perhaps you'd like to look into another EIT issue. I've made good progress on integrating an ATSC PSIP-derived EPG into my PVR app and now want to check that it also works on DVB streams. @cfsmp3 kindly posted for me this link to a Spanish station's full-ts file. I've run that file through both

tstables channel41.ts --dvb --xml-output analysis_channel41.xml

and

'.\CCExtractor Windows Release build-96\ccextractorwinfull.exe' --ts --null --xmltv 1 .\channel41.ts

The former reports only 12 EIT events (occurrences of start_time=). The latter reports 986 occurrences of start= but 679 of them are not valid time strings. E.g., the first one is in <programme start="202601311184512+0000" stop="20260131122400 +0000" channel="40001">. All of the stop= time strings, however, are valid UTC times.

My question is: Does ccextractor have a bug in its DVB-T start time encoding or does the posted file actually have incorrect EIT data (as the tstables result seems to suggest)?

Here are the results of my analyses: analysis_channel41.xml and channel41_epg.xml

[x15sr71]

Hi @TPeterson94070,

I spent some time digging into this and comparing the outputs with CCExtractor's DVB EIT parsing code.

From what I can see, CCExtractor currently doesn't fully decode or validate the 24-bit BCD time field in EIT events. In EPG_DVB_calc_start_time() it formats time & 0xffffff directly as a number, without splitting the BCD nibbles or checking that the resulting HH/MM/SS values are in range. The code also doesn’t appear to perform range checks or validation on the decoded time fields. Because of this, when the stream contains schedule EIT sections with malformed or unexpected time fields, CCExtractor seems to accept them and ends up producing timestamps like 202601311184512+0000, instead of discarding those events.

In this sample, tstables reports only 12 valid events, mostly from present/following EIT data, while most schedule EIT sections seem to be filtered out. CCExtractor, on the other hand, appears to process those sections without validating the decoded time fields, which likely explains the large number of invalid start= values.

To answer your question directly: It's actually both. The stream does appear to contain malformed schedule EIT data (as the tstables result suggests), but CCExtractor has a bug in how it handles this, - it should properly decode BCD time fields and validate/reject invalid events rather than outputting impossible timestamps.

Regarding why stop times look valid: I traced this in the code and it turns out start and stop are handled through different paths. Start times are formatted directly from the raw BCD field, while stop times are re-decoded, added to the duration, and passed through mktime() for normalization. That normalization step hides overflows and invalid values, which is why stop times can look reasonable even when the original start time was malformed.

So my impression is that adding proper BCD decoding and range checks to CCExtractor would avoid generating these invalid timestamps and bring its behavior more in line with tstables.

I'll try to raise a PR for this when I get a chance. In the meantime, let me know if I've missed anything, happy to look further if needed.

[TPeterson94070]

@x15sr71 , thank you for another great analysis. If the valid stop= values are computed from start + duration (as you found and I suspected, but didn't know for sure) then clearly the start values must have been correct to begin with. Therefore, both tstables and CCExtractor are incorrectly handling those start values, just in different ways!

If you can raise a PR to fix CCExtractor's handling of DVB EIT start values, that will enable me to support DVB EPG generation as well as the existing ATSC EPG via CCExtractor.