Post by Ben BuckschSee http://wiki.xmltv.org/index.php/LineupProposal
Personally I think that wasn't a good spec. My proposal
http://wiki.xmltv.org/index.php/LineupProposal2
http://www.bucksch.org/1/projects/various/xmltv/lineup.de.xml
unfortunately was ignored.
The purpose behind mine was that a PVR can set itself up completely
automatically in a way that end users expect. It would run a channel
scan to find all technically receivable channels, and then use the
lineup to set
* the correct RFC2838 / XMLTV ID for a technical channel
* the right presets (which in some countries like Germany and France
are just a common convention, nowhere defined, so this lineup wants
to do that)
* icons, long and short names etc.
Without this information, the channel scanner find a DVB channel "RTL
Television" from the DVB stream, but has no way to match it with any of
the channels from XMLTV. This isn't a trivial problem, you can't just
match names from DVB and XMLTV, because it's a 1:n match. What XMLTV
calls a "channel" is actually a station, and a station can be
distributed via many channels, in different distribution systems, and in
SD and HD, and they'll all have different technical names.
Likewise, when you set up a PVR with Astra sat feed, you'll get 1000
channels. This is totally useless for an end user, unless you sort them
in a way the user expects. In Germany, we expect ARD on 1, ZDF on 2
etc., but there isn't any source that would give this information, yet
it's critical for a PVR to be useable in practice. The provider can't
give that information, because there isn't any single provider, but
about 50 different, and of course each (esp. the pr0n channels) want the
best slots.
Rather than re-critiquing the original proposal from Mattias from
several years ago (which the current implementation does *not*
follow), could you please take a look at the actual lineup schema
(xmltv-lineups.xsd) and provide details of how it fails to fit your
requirements above.
In the current schema, a lineup-entry element comprises:
i) sub-elements providing details of an EPG preset number,
geographical availability, EPG section, subscription package
ii) a station sub-element (which carries the XMLTV ID as an attribute,
and contains sub-elements providing details pertinent to the TV
station and its content (name, shortname, commercial free status,
icon, SD/HD);
iii) unlimited *-channel sub-elements which contain the relevant
tuning/logical channel numbering for a number of different
transmission methodologies/platforms where the station (not channel)
is available.
The organisation of elements is slightly different to your proposal
above, but seems to follow its ideas closely. I've been using lineups
generated for uk_rt (with one lineup per platform) to not only manage
channel availability in the grabber on a
platform/geographic/subscription package basis for all users of the
grabber, but also to locally manage DVB-T/DVB-S and analogue cable TV
video sources (in my case with MythTV) to map XMLTV configuration data
to tuning data (which seems to be what you want) from DVB-T/S scans in
MythTV, and it works as intended.
Cheers,
Nick