Mailing List archive

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

[vdr] Re: unique channel id



"Aike J Sommer (AS Media)" wrote:
> 
> Am Donnerstag, 21. November 2002 12:37 schrieben Sie:
> > Régis Bossut wrote:
> > > Klaus Schmidinger writes:
> > > >I'll change the channel ID so that it can (optionally) include an APID,
> > > > which should solve the problem with the french radio stations.
> > >
> > > Hmmmm, I should have mentioned that together with the radio name, the
> > > 0xc5 descriptor gives an unique id (the first byte is the radio number,
> > > remaining bytes up to the first 0x00 is the radio name). May be this id
> > > should be added, instead of the APID.
> >
> > I don't want to have strings in the channel ID, since these are subject to
> > change (one of the ideas of the channel ID is to be able to react on name
> > changes). So far the only useful additional ID I can see is the APID.
> >
> 
> well... i guess the apids might change just as the strings might! therefor i
> would suggest to really only stick to source, NID, TID and SID as that really
> does identify every station (considering that those radio "stations" are
> really only one station with different apids)
> to solve the "french radio problem" i would propose to:
> 
> 1) not check the channels.conf for uniqueness (that would also allow building
> own bouquets as somebody asked for on some other thread), when a unique
> channel id is to be mapped to a channel from channels.conf the first one
> could be chosen (you could maybe give a warning message when this occurs, but
> ignore it)

When the APID is added to the channel ID, channels will be required to be unique
only with respect to the APID. Or, in other words: if two channels have the same
SRC+NID+TID+SID, they will _have_ to have different APIDs. As long as all
channels are unique in their SRC+NID+TID+SID, no APIDs will have to be used.
Of course, this will all happen automatically.

> 2) allow optional values to entries in files like timers.conf, which could be
> alternating apids or vpids or anything else, in order to record those (this
> would also allow recording of alternating languages for movies, but actually
> this might be possible already, never tried that yet

VDR already records _all_ given audio PIDs, so that you can select the desired
version when replaying.

> 3) later, when you actually strip the data like frequency, polarisation and so
> on from channels.conf,

Who said I would do that? 'channels.conf' is going to remain exactly the way it
is, with the addition of two new fields for NID and TID.

> ...
> > Needless to say that it would have been best if the providers would have
> > adhered to the commonly used scheme of using unique SIDs for their
> > channels... After all, the EPG records _will_ be the same for all these
> > channels since they can only be distinguished by their SIDs - or am I
> > missing something here?
> 
> i suppose those radio stations do not send out epg-data, but i could be wrong
> about that, i dont use those channels...

Me neither. And if they actually don't broadcast EPG, then there will be no
problem.

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