Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: unique channel id



"Rienecker, Fa. Evenio, ITS P, M" wrote:
> 
> Hello @ll,
> sorry to once more raising this topic, but something went wrong with the way
> 1.1.16 was implemented.
> 
> To recall the intentions:
> 1. There are lots of tv- and radio-stations out there and I am sure
> everybody identifies the stations by name.
> 2. There a a lot of combinations of tuning parameters: VPID, APID, SID and
> sat-transponder(position + frequency + polarization). The later Information
> might even by substituted with some sort of combination of sat-position,
> TID, NID and/or ONID.
> 
> Now, if I want to set up a list of my favorite tv/radio-stations I want to
> refer to them by name, nothing else.
> But vdr only needs the tuning parameters, it doesn't need names to tune.
> 
> Now what is the unique channel ID ???
> The unique channel ID was supposed to be an artificial unique number that
> relates the channels in my personal list to the tuning parameters. This is
> necessary to get rid of the intrinsic connection between channel and tuning
> parameters present at the moment in vdr.
> 
> The benefits will be:
> If a channel switches tuning parameters (like e.g. Studio Universal, Disney
> Channel and Planet) you don't have to edit the channel list nor the timers
> need to be updated. You just edit the list that maps tuning parameters to
> unique channel IDs. This enables us to publish one master list for all vdr
> users. The local channel list need not to be changed.
> This scheme also covers the case of channels beeing substituted by another
> one (like Chillout replaced Volksmusik) in a way that Chillout gets a new
> unique channel ID and the entry for the unique channel ID related to
> Volksmusik will be marked dead or temporarily unavailable in the tuning
> parameter list. This way vdr may pop up a message to inform the user if
> (s)he tries to tune to the now inactive channel.
> 
> How to construct a unique channel ID:
> Don't use anything related to real world values. Especially tuning
> parameters, because they _ARE_ changing.
> Don't use plain channel names, because people use different names for the
> same channel ('PRO7', 'PRO 7', 'Pro 7', 'Pro-7', 'PRO-7', ...)
> The easiest Way would be to just start numbering, starting from 1 and add
> new channels at the bottom of the list.
> Artificial keys have proven to be the best way to perform a join over two
> tables (the channel list and the tuning parameter list).
> 
> Of course there are channels available from different sources, i.e. various
> tuning parameters. E.g. 'ARD - Das Erste' is available in Berlin from cable,
> terrestrial, Astra, Hotbird and maybe more.
> Basiccally there are two ways to handle this:
> 1. Assign one unique channels ID for each sourse and let the user decide
> which one to use in his personal channel list.
> 2. Assign just one unique channel ID to ARD and make vdr aware of the
> capabilities of the local equipment. E.g. VDR is configured to only receive
> Astra and subsequently choses the tuning parameters related to Astra
> ignoring the other ones matching the unique channel ID.
> 
> I don't want to offend anyone, but my personal opinion is that the way
> 1.1.16 is implemented we have introduced restrictions without gaining
> benefits.
> 
> My suggestion would be something like this:
> add a field 'unique channel ID' to the channels.conf, keep everything else
> the same for compatibility reasons.
> Actually the ca filed must still be used since this is something that might
> dependend on the local setup.
> 
> channels.conf:
> ----schnipp----
> :@1 RTL
> RTL::::::::0:;1
> RTL2::::::::0:;4
> :@11 ProSiebenSat1
> Sat.1::::::::0:;2
> Pro-7::::::::0:;3
> :@21 ARD
> Das Erste::::::::0:;5
> ----schnapp----
> 
> And add a new file 'tuner.conf' that has the unique channel ID instead of
> the channel names.
> 
> tuner.conf
> ----schnipp----
> :Astra
> 1:12188:h:S19.2E:27500:163:104:105:0:12003
> 2:12480:v:S19.2E:27500:1791:1792:34:0:46
> 3:12480:v:S19.2E:27500:255:256;257:32:0:898
> 4:12188:h:S19.2E:27500:166:128:68:0:12020
> 5:11837:h:S19.2E:27500:101:102:104:0:28106
> :terr Berlin
> 1:658000:I0C23D0M16B8T8G8Y0:T:27500:337:338:0:0:16405
> 2:658000:I0C23D0M16B8T8G8Y0:T:27500:385:386:0:0:16408
> 3:658000:I0C23D0M16B8T8G8Y0:T:27500:305:306;307:0:0:16403
> 4:658000:I0C23D0M16B8T8G8Y0:T:27500:353:354:0:0:16406
> :telekom cable
> 5:410:M64:C:6900:101:102:104:0:28106
> ----schnapp----

I don't agree. The unique channel ID ***MUST*** be soemthing that can be derived from the
data transmitted in the DVB broadcast. The can ***NOT*** be some artificial number.
Who would take care of registering these numbers and keeping them unique??

It was posted several times on this list that a combination of NID, TID and SID
would uniquely identify any channel (plus the 'source' parameter, in case we're
dealing with various sources). VDR 1.1.16 implements a first step towards this,
by setting the NID to always 0 (VDR currently doesn't use this parameter yet)
and using the transponder frequency instead of the TID. At a later point it will
switch to NID+TID, which will be compatible since the two verions can be distinguished
by the 0 NID).

Now, apparently it is NOT the case that _every_ channel has a unique combination
of NID+TID+SID, as can be seen with those french radio channels. Assigning more APIDs
to a channel doesn't help in this case, since the various APIDs have nothing to do
with each other (they are completely separate programmes, as opposed to the APIDs of
a video channel, where they are, e.g., different language versions of the same programme).

So, in order to keep these channels apart, I would agree to add their APIDs to the channel
ID. This has the downside that a change in the APIDs could not be detected (since the APID
is part of the channel ID), but it would allow at least to use the NID+TID+SID scheme
for video channels, and where that isn't enough (as with radio channels) we can add the APID.

One reason why I have to insist on only using data that is broadcast is that the EPG
records need to be assigned to the channels. In the EPG dat stream we have only the
data that is broadcast, and there is no way of bringing in some artificially generated
number here.

I'll change the channel ID so that it can (optionally) include an APID, which should
solve the problem with the french radio stations.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.



Home | Main Index | Thread Index