mirror of
https://github.com/CCExtractor/ccextractor.git
synced 2026-02-03 21:23:48 +00:00
ccextractor XMLTV output for ATSC TS does not include mapping of friendly channel names to channel_ID values #858
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @TPeterson94070 on GitHub (Dec 15, 2025).
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 commented on GitHub (Dec 15, 2025):
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 commented on GitHub (Dec 15, 2025):
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:
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 commented on GitHub (Dec 15, 2025):
@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 commented on GitHub (Dec 16, 2025):
@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 commented on GitHub (Dec 16, 2025):
@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 commented on GitHub (Dec 16, 2025):
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 commented on GitHub (Dec 16, 2025):
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 commented on GitHub (Dec 17, 2025):
Thanks for the feedback, @TPeterson94070.
I’ll go ahead and open a PR with this approach.
@TPeterson94070 commented on GitHub (Dec 18, 2025):
@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 commented on GitHub (Dec 18, 2025):
@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.