Users of MythTV and other similar software need a way to identify the television stations that they receive. If this can be accomplished, two large benefits can be provided to our user base.
First, identifying stations is the first step to building an open lineup tool that will allow users to automatically detect and configure which stations their home DVR can receive.
Secondly, a centralized repository of channel information will allow users to enhance their user experience by loading meta data including names and logos, as well as links to related websites and other media.
Our goal would be to have a system which is capable of automatically identifying the specific channel lineup for any user, given a minimal amount of information.
On the surface, the problem seems simple: identify each station that the user receives. Unfortunately, the problem goes deeper. In the US and abroad, there are layers of ownership and affiliation that must be traversed in order to correctly identify the specific variant of what the end user calls a "channel".
Defined: Source of the TV signal/broadcast
Providers are probably the easiest piece of the puzzle to define: the source of the user's TV. Examples include Comcast, DirecTV, and Sky.
The only oddity is broadcast TV, which is provided directly by local stations, but for our purposes is probably best identified by postal code or some other similar geographic
Defined: Set of tuning information, tied to a specific Provider, over which TV programming is transmitted
At the basic level, a channel refers to the data transmitted to the end user on a particular frequency (or other kind of tuning identifier), usually identified by a number (e.g. channel 13). Digital tuning is more complex, but most of the complexity is hidden from the end user, who still expects a numeric channel identifier to refer to the expected collection of programming.
Though some broadcast channels are given unique identifiers called callsigns, their usefulness (and uniqueness) starts to deteriorate with Cable and Satellite providers, and they are almost unheard of outside of North America.
RFC 2838 was written to create a way to uniquely refer to channels, but no attempt to create a standard database of identifiers has been created successfully. XMLTV has been the most successful group so far in the open source world to produce identifiers, but has done so without accompanying tuning info, which leaves the user with the job of manually correlating an xmltvid to the channels on his or her TV.
Affiliate / Station
Defined: Content source or creator for a specific channel
The affiliate, which for our purposes should be synonymous with the station, is the producer of the content broadcast over a specific channel. Affiliates are generally restricted to broadcast TV, and are generally considered the local face of larger nationwide content producers.
Understanding affiliates is useful because they are generally what people think of when they talk about the stations they receive, although naming conventions are often confused with Networks, who produce most of the more popular prime-time content that affiliates use.
Defined: Parent partner of some affiliates
Networks are larger content sources. In the US, the large broadcast affiliates are not directly accessible by viewers, who must tune into an affiliate to view the programming. However, many newer so-called Cable Networks do not actually have a local affiliate, which leads to difficulties in identifying the differences between Networks and Affiliates as they relate to cable and satellite programming.
Defined: Collection of channels available to users of a Provider in a specific location
One of the goals for this project is to allow users to identify the lineup(s) available to them. Conversely, certain tuning technologies provide basic lineup information (e.g. a channel scan) that could be used to help identify a more accurate lineup description in our proposed database.
Cable technologies like [Scte65scan SCTE65] can help provide information about lineups, but often provide details for more than a single location and/or use nonstandard channel identifiers (callsigns and names do not match standards like TMS and/or contain inconsistent white space).
MythTV Channel Icon service
MythTV developers have built a rudimentary database that can identify channels by their xmltvid value (in the US, xmltvid has been supplanted by the TMS id provided in their data feed via Schedules Direct), with supplemental identification based on the DVB and ATSC tuning parameters. Though it has been running successfully for quite awhile, it is based on an incomplete understanding of the problem, and needs to be replaced with something that can provide a more accurate and useful information.
At the basic level, users seem to think the system performs its function: it auto-identifies the majority of channels based on xmltvid and allows users to download channel artwork.
- Identifies individual channels only after users have properly configured their lineup information with XMLTV or Schedules Direct.
- Too much work for a small team of volunteers to maintain and validate submissions.
- Channels can change affiliation or update logos, and the system lacks and easy way to change icons or push updates to users.
- Attempt to collect ATSC/QAM tuning info separately from DVB does not work.
- DVB identifiers may or may not be unique, and more importantly provide no way to identify at a glance other than total number of submissions for a particular icon.
- System is slow (Perl CGI and SQLite) and needs to be rewritten (PHP and MySQL).
- Users differ in their preference for Affiliate vs Network icons (e.g. affiliate vs network).
- Logos are obtained via deep links to Lyngsat, and I doubt they appreciate it.
- Difficulties with Lyngsat's site layout and the way the icon database was designed prevent us from linking to high quality transparent PNG/SVG logos.
Now that we have identified the problem and defined both our goals and a set of terminology, we need to look into specific solutions.
Silicon Dust currently collects a large amount of tuning information from their [Silicondust_HDHomeRun HDHomeRun] devices, which can be searched here. Though they are very supportive of MythTV and similar open source projects, it is unlikely that they will be interested or able to share this information with us because licensing it to providers like Tribune would be much more lucrative.
On the other hand, we should examine their data collection methodologies to see if there would be any benefit to doing something similar.
Australian Data Sources
There are some existing sources of user-generated TV information, including lineups. This system seems to work, so there may be something to be learned from them.
It would be nice to get some links and more description here.
XMLTV Lineup Proposal
A few members of the XMLTV team have been working on a Proposal for handling lineups. Unfortunately, though the file format has been thoroughly defined, little work has been put into designing a system to create and maintain the content.
The focus of this proposal is also very specific to tuning information and does not explicitly provide a means for storing or accessing channel meta data like icons, names, affiliations, etc.
Updated MythTV Channel Service
MythTV (especially with the help from a group like Schedules Direct) has the resources to build the channel icon service into something much larger that could provide additional meta data as well as a tool to identify specific lineups. Resources and planning should be shared with XMLTV.
More to come here