search

XMLTV / xmltv

Utilities to obtain, generate, and post-process TV listings data in XMLTV format
GNU General Public License v2.0
266 stars 93 forks source link

Lineup proposal: The XMLTV dtd (and grabbers) need to support stations and channels #184

Open garybuhrmaster opened 2 years ago

garybuhrmaster commented 2 years ago

A couple of issues have reinforced the need for the XMLTV project to define and support the difference between a channel (which is a delivery/transport mechanism), and a station (which is a supplier of content).

XMLTV uses the term \<channel> where they should likely use the term \<station> because they deal with programming, not transport.

This also results in a failing of the configuration capability which treats the selecting of content as being "station" based, which is not always the same thing as a "channel" (for example, for cable providers, a "station" may be transmitted on many "channels" (perhaps in different resolutions), but an individual may only be authorized to receive some of the "channels"). One may want the "station" schedules and programs, but not to see the "channel" returned because they cannot tune it.

This has previously been understood (starting back in 2008), and a couple of proposals were made ( http://wiki.xmltv.org/index.php/NoLineupProposal and http://wiki.xmltv.org/index.php/LineupProposal and http://wiki.xmltv.org/index.php/LineupProposal2 ). The --get-lineup option to a grabber provides a different output format that separates the station from the channel, and at least one grabber has implemented it.

misar1 commented 2 years ago

A couple of issues have reinforced the need for the XMLTV project to define and support the difference between a channel (which is a delivery/transport mechanism), and a station (which is a supplier of content).

XMLTV uses the term where they should likely use the term because they deal with programming, not transport.

I am not entirely convinced of the need to make this distinction but if it is important your terminology will not suffice.

For example in the UK we have BBC and ITV which might be referred to as "stations" but we tend to use the term "broadcasters". Both broadcast a range of programming streams: BBC1, BBC2, BBC3, BBC4, etc and ITV(1), ITV2, ITV3, ITV4, etc. Each stream has distinct programming but we always refer to all of them as "channels", not "stations". Many of these programming streams are also broadcast in both SD and HD versions with identical programming. We also regard those as channels which is the only point where your terminology would fit. However, many EPGs list both such channels separately with different names and channel numbers regardless of their identical programming, e.g. "BBC1" and "BBC1 HD".

rmeden commented 10 months ago

While I agree could be , it would break all existing XMLTV applications, which would be bad. :)

garybuhrmaster commented 9 months ago

While I agree could be , it would break all existing XMLTV applications, which would be bad. :)

The output of any internal XMLTV changes (which can be transparent) would need to continue to support existing applications with their incorrect definitions, even as the internals fix the brokenness. There is even a protocol in the grabbers to "upgrade" configure files (load_old_config) that could be used for an upgrade path.

I do not expect anyone to invest the effort to do so any time soon.