Difference between revisions of "NoLineupProposal"

From XMLTV
Jump to: navigation, search
m (start fleshing out proposal)
 
(This proposal is in the making: add structure and example)
Line 1: Line 1:
 
=== This proposal is in the making ===
 
=== This proposal is in the making ===
 
This proposal by [[User:Dekarl|Karl Dietz]] on how to match channels from a channel scan to channels in the guide without lineups is an alternative to [[LineupProposal]] and [[LineupProposal2]].
 
This proposal by [[User:Dekarl|Karl Dietz]] on how to match channels from a channel scan to channels in the guide without lineups is an alternative to [[LineupProposal]] and [[LineupProposal2]].
 +
 +
= sketch of the process =
 
The process of configuring a consuming application should be like.
 
The process of configuring a consuming application should be like.
 
* install application and hardware
 
* install application and hardware
Line 7: Line 9:
 
* the application shall connect the available channels to the guide channels
 
* the application shall connect the available channels to the guide channels
  
 +
= additional metadata =
 +
To allow automagic mapping of guide data to received channels then channel list should be extended to carry channel identifiers that are useful to machines (aka DVB/ETSI/etc. IDs) in addition to channel identifiers destined for human consumption (aka the channel name).
 +
Identifiers with use for machines:
 +
* the combination of DVB original_network_id and service_id is defined to be globally unique. One channel will usually have a bunch of them. E.g. one for transmission via DVB-S and one for DVB-T. DVB-C might carry the satelite channel or one crafted for cable, so you can find satelite IDs on cable.
 +
* the combination of DVB bouquet name (what's with Bouquet_ID?) and service name could be useful to suggest a preferred candidate in case the DVB identifiers don't match up. (e.g. missing data for a region/provider)
 +
* for redigitalization via the analog hole the old ETSI country and network identification might be useful as it is carried in teletext and VPS. (not sure if there are distinct IDs for regional variants of channels)
 +
 +
= example of extended --channel-list =
 +
<channel id="3sat.de">
 +
  <display-name lang="de">3sat</display-name>
 +
  <icon src="ht tp://xmltv.spaetfruehstuecken.org/chanlogos/3sat.de.png"/>
 +
 +
3sat on Astra (and many cable operators that use the Astra feed)
 +
  <dvb-service>
 +
    <original_network_id>1</original_network_id>
 +
    <service_id>28007</service_id>
 +
  </dvb-service>
 +
 +
on austrian DVB-T
 +
  <dvb-service>
 +
    <original_network_id>8232</original_network_id>
 +
    <service_id>11302</service_id>
 +
  </dvb-service>
 +
 +
on german DVB-T
 +
  <dvb-service>
 +
    <original_network_id>8468</original_network_id>
 +
    <service_id>515</service_id>
 +
  </dvb-service>
 +
 +
on all transmissions (even analog)
 +
  <etsi-vps-cni>dc7</etsi-vps-cni>
 +
</channel>
 +
 +
= interactions =
 
The API for the consuming application:
 
The API for the consuming application:
 
* "tv_find_grabbers" will offer all installed xmltv grabbers
 
* "tv_find_grabbers" will offer all installed xmltv grabbers
* "tv_grab_xxx --configure-api --stage start" will optionally collect configuration data until it says "next stage is channel selection"
+
* "tv_grab_xx --configure-api --stage start" will optionally collect configuration data until it says "next stage is channel selection"
* "tv_grab_xxx --list-channels" will list all available channels
+
* "tv_grab_xx --list-channels" will list all available channels
 
(note that the list might be a subset of all theoretically available channels due to being restricted to  
 
(note that the list might be a subset of all theoretically available channels due to being restricted to  
 
# a lineup
 
# a lineup
Line 16: Line 53:
 
# upstream channel selection
 
# upstream channel selection
 
in the earlier configuration stages)
 
in the earlier configuration stages)
* "tv_grab_xxx --configure-api --stage select-channels"
+
* "tv_grab_xx --configure-api --stage select-channels"
 +
 
 +
= unsure, needs clarification =
 +
* --list-channels shall list all channels that are available on the select-channels stage, allowing to go back and find new channels programatically. E.g. the consumer has a list of all received channels and can compare that to the list of channels provided by the grabber. If a channel without guide data suddenly appears in the --list-channels list the consumer can rerun the select-channels stage and "order" the additional channel.
 +
 
 +
= sources =
 +
* [http://www.dvbservices.com/identifiers/index.php Registry of DVB identifiers]
 +
* [http://www.eutelsat.com/satellites/pdf/Diseqc/Reference%20docs/recom_trans_para_broadcasters&operators_DVB_multiplexes_using_EUTELSAT_syst.pdf EUTELSAT technical guide for DVB operators] talks about which combination of DVB identifiers must be unique
 +
* [http://www.etsi.org/deliver/etsi_tr/101200_101299/101231/01.02.03_60/tr_101231v010203p.pdf ETSI Register of Country and Network Identification]

Revision as of 08:39, 17 July 2011

This proposal is in the making

This proposal by Karl Dietz on how to match channels from a channel scan to channels in the guide without lineups is an alternative to LineupProposal and LineupProposal2.

sketch of the process

The process of configuring a consuming application should be like.

  • install application and hardware
  • pick a guide source (and do the basic configuration, everything but selecting the channels)
  • perform a scan to find all available channels
  • the application shall connect the available channels to the guide channels

additional metadata

To allow automagic mapping of guide data to received channels then channel list should be extended to carry channel identifiers that are useful to machines (aka DVB/ETSI/etc. IDs) in addition to channel identifiers destined for human consumption (aka the channel name). Identifiers with use for machines:

  • the combination of DVB original_network_id and service_id is defined to be globally unique. One channel will usually have a bunch of them. E.g. one for transmission via DVB-S and one for DVB-T. DVB-C might carry the satelite channel or one crafted for cable, so you can find satelite IDs on cable.
  • the combination of DVB bouquet name (what's with Bouquet_ID?) and service name could be useful to suggest a preferred candidate in case the DVB identifiers don't match up. (e.g. missing data for a region/provider)
  • for redigitalization via the analog hole the old ETSI country and network identification might be useful as it is carried in teletext and VPS. (not sure if there are distinct IDs for regional variants of channels)

example of extended --channel-list

<channel id="3sat.de">
  <display-name lang="de">3sat</display-name>
  <icon src="ht tp://xmltv.spaetfruehstuecken.org/chanlogos/3sat.de.png"/>

3sat on Astra (and many cable operators that use the Astra feed)

  <dvb-service>
    <original_network_id>1</original_network_id>
    <service_id>28007</service_id>
  </dvb-service>

on austrian DVB-T

  <dvb-service>
    <original_network_id>8232</original_network_id>
    <service_id>11302</service_id>
  </dvb-service>

on german DVB-T

  <dvb-service>
    <original_network_id>8468</original_network_id>
    <service_id>515</service_id>
  </dvb-service>

on all transmissions (even analog)

  <etsi-vps-cni>dc7</etsi-vps-cni>
</channel>

interactions

The API for the consuming application:

  • "tv_find_grabbers" will offer all installed xmltv grabbers
  • "tv_grab_xx --configure-api --stage start" will optionally collect configuration data until it says "next stage is channel selection"
  • "tv_grab_xx --list-channels" will list all available channels

(note that the list might be a subset of all theoretically available channels due to being restricted to

  1. a lineup
  2. the country for which you bought the guide
  3. upstream channel selection

in the earlier configuration stages)

  • "tv_grab_xx --configure-api --stage select-channels"

unsure, needs clarification

  • --list-channels shall list all channels that are available on the select-channels stage, allowing to go back and find new channels programatically. E.g. the consumer has a list of all received channels and can compare that to the list of channels provided by the grabber. If a channel without guide data suddenly appears in the --list-channels list the consumer can rerun the select-channels stage and "order" the additional channel.

sources