On 30 March 2012 09:46, Ben Bucksch <***@bucksch.org> wrote:
> On 30.03.2012 03:43, Nick Morrott wrote:
>> Your application uses the relevant Sky and Virgin lineups and asks the
>> _user_ (not the lineup creator) which numbering scheme to use, and
>> uses the information in the lineups to arrive at a non-conflicting
>> solution?
>
> No, I am shooting for zero configuration, the user specifies nothing.
> I would create one single lineup for all of UK, including Sky and
> Virgin, i.e. there wouldn't be any two Sky vs. Virgin stations with the
> same preset, but Sky would be 100 and Virgin 200. That's not hard.
> That's of course coming from my German background, and I don't know how
> UK users would react to that. I would also create 2 other lineup files
> for the UK that have the official numbering scheme of Virgin and Sky, on
> a different URL, and the user could specify that, yes. But that would be
> optional.
Ben,
I've had "real-life" issues for the last few days so please excuse my
brevity in replying.
> Please note that in my model, the lineup and grabber are independent.
> There can be 1 lineup URL and 10 grabbers for Germany. The lineup is
> designed to be a static webserver URL that can be used by anybody, and
> be fetched only rarely, e.g. after the app did a channel scan. Of
> course, the grabber can also provide such a URL, but it doesn't have to,
> it can be independent.
The XSD spec permits the same: each station is identified with an
rfc2838 attribute (where defined). This identifier can be used across
any grabbers that want to use the lineup.
>> My top-rated channel BBC Four [2] is available in the UK/Ireland on
>> the following TV platforms with these channel presets:
>>
>> Freeview - Channel 9
>> Freesat - Channel 107
>> Sky (UK) - Channel 116
>> Sky (Ireland) - Channel 230
>> Virgin Media- Channel 107
>> UPC Ireland - Channel 117
>> Smallworld Cable - Channel 119
>
> I accept that this is what you expect, but not people here. That would
> confuse and annoy me to no end. It's common here that people subscribe
> to Sky only for 1-2 years. They don't want all their TV to change every
> time.
I read an article the other day [1] about EPG numbering changes in the
UK, which also included comments about the state of EPG numbering in
Germany:
"In Germany there is no channel numbering scheme, so everyone numbers
the channels themselves. It's fairly hard to sort 100+ channels over a
bad rubbery remote."
This explains the unstructured nature of your lineup proposal.
[1] http://forums.reghardware.com/forum/1/2012/03/30/dmol_proposes_freeview_epg_shuffle_to_take_in_iptv/
>> I don't think it's due to differing locations, as TV here in the UK is
>> pretty much the same as TV in France, Germany and everywhere else when
>> you break it down into stations (content) and channels (transmission).
>
> Indeed. What seems to be different is the user expectation. I take it as
> a granted since a child that 1 = ARD and 2 = ZDF. Anything else is
> simply broken, and I think most Germans share that viewpoint. You expect
> BBC 1 to be on a different preset depending on whether you pay for Sky
> or not. It's probably because we have a different TV landscape: ARD is
> still the most important channel even if you do have Sky. Sky just adds
> some additional premium channels with new movies or soccer.
This is the crux of the problem. Based on the definition of the
'lineup' that I am working to, by default it is intended for lineup
producers to uss the EPG numbering scheme of each TV provider for
which a supported lineup exists. However, if there is a more accepted
(and arbitrary) preset numbering scheme used, that can be used
instead.
In the UK, most/all TV users would probably expect BBC1 to be the
_first_ channel on the EPG, as historically that has always been the
case. However, and where your universal numbering scheme falls down,
different TV providers use different numbering schemes and so BBC1
_might_ be channel 1 on one platform (e.g. Freeview), it can be
channel 101 on another (Freesat).
Here the channel numbering assumption is based on relative, rather
than absolute, position in the EPG. That is an important distinction.
>> A lineup is not intended to
>> be a complete set of all channels available everywhere on all
>> platforms (that is not a lineup, that is a channel database). Nor is
>> it intended to provide a single channel preset for all channels across
>> all platforms based on past broadcast history or the whims of the
>> lineup creator.
>
> Given that English is not my native language, I can't know what "lineup"
> means precisely. I thought it meant a list of stations (not channels)
> and their presets.
As you have cut the definition I am working to from your reply, I
shall simply repeat what Mattias defined it as:
"A lineup contains a set of channels that a customer can order from
his provider"
> It seems to me that in your model, 1. the user would first have to
> select a subscription plan or channels or similar manually, then 2.+3.
> you'd download the lineup and TV programming, and 4. you'd do a channels
> scan, and 5. you'd match the stations with the channels you have.
> My idea is the opposite: 1. Scan, and find out which channels are
> receivable (and decodable), 2. fetch the lineup for the country, 3.
> match channels to stations, 4. selecting a grabber / the grabbers for
> the receivable stations, and 5. fetching the TV programming. That means
> the user doesn't have to enter anything, not even select a grabber.
Usage based on my model would be (for DVB-T/S, usage has to be
different for other types of lineup):
1. End-user application does a channel scan
2. User is optionally prompted in application for their TV provider
(the list of supported lineups can be made available either by
retrieving a lineups.xml file following the XSD, or by calling
"$grabber --list-lineups" if the app is using XMLTV for listings. If
using XMLTV, the grabber is configured at this stage.
3. The lineup is retrieved - either by retrieving a $lineup.xml file
following the XSD, or by calling "$grabber --get-lineup" if the app is
using XMLTV for listings.
4. Scanned channels are matched against the content of the lineup XML
file, XMLTV IDs are configured and channels are renumbered.
5. Listings are retrieved for configured channels.
Because lineups are specific to a TV provider, you will likely not
want every single matched channel to be configured for you
automagically. An example:
A UK satellite user does a channel scan of available DVB-S channels at
28.2E. Their application finds >1000 FTA channels but they only want
the Freesat lineup configured (176 TV and radion channels). Under my
proposal, the user simply chooses the Freesat lineup, and only those
channels are configured. If the user wanted all FTA channels carried
on 28.2E configured a separate lineup would be used with arbitrary
presets.
As a second example, if a user receives their TV through a STB
connected to their HTPC via a capture card (i.e. not a tuner) the
order would be:
1. User is prompted in application for their TV provider (the list of
supported lineups can be made available either by retrieving a
lineups.xml file following the XSD, or by calling "$grabber
--list-lineups" if the app is using XMLTV for listings. If using
XMLTV, the grabber is configured at this stage.
3. The lineup is retrieved - either by retrieving a $lineup.xml file
following the XSD, or by calling "$grabber --get-lineup" if the app is
using XMLTV for listings.
4. Channels are automagically created and configured against the
content of the lineup XML file, XMLTV IDs are configured and channels
are renumbered.
5. Listings are retrieved for configured channels.
Because there are no scanned channels to match against, the
configuration process here is different. I am not sure how your
proposal you work in this scenario.
> Given that we now understand the different needs, what do we do? As I
> said: What you want to do is possible with my spec. What I want to do is
> not possible (cleanly) with your spec.
>
>> Following my spec you can create a single DTV lineup and include all
>> DVB-T and DVB-S channels available in Germany in it, associated with
>> whatever preset you want.
>>
>> If the restriction on channel type is removed (it is an enum in the
>> XSD to enforce the intended behaviour of a lineup), you could also
>> include IPTV/analog/STB channels.
>
> Can I specify that DVB-Name "Das Erste" and "DAS ERSTE" and "Das Erste
> HD", are actually one and the same station (identically programming),
> without replicating the station name, preset etc.? This is what's
> important for my app: no duplication, clear identity of stations and 1:n
> mapping station (programming) to channel (technical reception). Given
> that you have a 1:1 mapping of stations between channels, I think that's
> not possible. And as you said, that doesn't even reflect UK landscape
> where stations and channels are separate, too.
This is factually incorrect per the XSD.
There is no 1:1 limitation on mapping stations to channels. There is a
1:n mapping of station:*-channel but it is currently limited to
channels of the same "type" (where type is DTV/STB/IPTV), so whilst
you can have unlimited DVB-S/DVB-T channels attached to a single
station, you cannot also throw in an IPTV channel (this would require
a different IPTV-specific lineup).
>> Data duplication within a single lineup is so infrequent that it is
>> not normalised out.
>
> This is not true for the setups that I know. It is *very* common to have
> both DVB-S or DVB-C plus 1-2 DVB-T receivers. On top, most stations
> these days have a normal SD channel and a HD version with identical
> programming, just higher resolution. Their DVB names and DVB IDs are of
> course different (e.g. "arte" and "arte HD" or "sky action" and "sky
> action HD"), but they are the same station. So, pretty much everybody in
> Germany who has either DVB-S or DVB-C has the situation of having 2
> channels (with different DVB names) for the same station.
Again, see above. Entirely possible with current XSD.
> And I want to shield my users from that. In my app, the user does not
> select "arte HD", but he selects "arte" and automatically gets the best
> available version. This is true for live-TV, but even more so for
> scheduling of recordings.
Not a problem. Your app configures each tuneable Arte channel against
the single Arte station configuration in the lineup. Your app can
place priority based on the best quality (e.g. HD) version of the
station and prefer to record from that.
> And I most definitely do not want to download the TV programme twice,
> once for "sky cinema" and once for "sky cinema HD", both with identical
> content. But that's status quo. That's another reason why the station
> identity is so important.
In MythTV you associate the same XMLTV ID with each station where you
want to receive the same programme listings.
Cheers,
Nick
--
Nick Morrott
MythTV Official wiki: http://mythtv.org/wiki/
MythTV users list archive: http://www.gossamer-threads.com/lists/mythtv/users
"An investment in knowledge always pays the best interest." - Benjamin Franklin