[vdr] Re: split up channels.conf

[jhall@UU.NET (Jeremy Hall)]

In the new year, Klaus Schmidinger wrote:
> Robert Schneider wrote:
> > 
> > kls@cadsoft.de wrote on 24.09.2002 16:28:35:
> > 
> > You are absolutely right, but if we had SID, TSID and NID in the line for
> > a channel in channels.conf, a [to be developed] scanner could easily
> > identify the channel representing that line and could update VPIDs, DPIDs,
> > APIDs and TPIDs.
> 
> I have no problem with adding further fields to the channels.conf lines.
> They won't have any meaning to VDR itself when tuning, but it it helps
> a scanner...
> 
> So, I take it that the only additional field that would be necessary would
> be the "original_network_id", right? You mentioned "SID, TSID and NID" - which
> of these are already in channels.conf, and which should be added? I get the
> feeling that everybody talking about these parameters uses different abbreviations
> or names.
> 
SID is in the line as the last field, you call it pnr.  tsid and
original_network_id (NID) are needed to properly map EPG data to service
entries.

In the case of a vdr operating on Echostar's Dish Network, the TSID could
be properly identified by tuning to each transponder and for the case
where there are two transponders with the same polarization and frequency,
it could assume this is definition of a ``spot beam'' transponder.  Upon
startup, as VDR scans through its known list of transponders, if it
detects a spot transponder, it could tune to it and then mark all the
other tsids for that frequency as ineligable, as well as services located
on them.

The value of 0 shouldn't be set or EPG won't work because tsid and nid are
both in the EPG and a lookup would fail.  Maybe if a user is creating a
new channel, he could select the appropriate NID from a list.  The NIT
tells you a text description for the numerical value (descriptor 0x40) In
the case of CONUS transponders, where there is only one TSID, the problem
is solved.  In the case where there are multiple TSIDs, but all except one
are marked ineligable, the user should be expected to be adding a channel
to a transponder he can actually view.  If the user has selected a
transponder that is previously unknown to VDR, vdr should ask before
tuning, then try to tune to that transponder to gather some default NID or
TSID parameters.  At this point, since the NID is known, it should not be
setable--as soon as vdr has tuned to the transponder, it knows the nid and
might know the TSID.  I need to check the linkage descriptor to find out
what it is linking, if it is linking to a TSID then this whole point is
useless and might not even need to be usersetable.

The original point I was trying to make is that I don't think 0 is a good
idea for these parameters since the data needs to be accurate.

> VDR itself would initialize that new field to 0 when creating a new channel
> entry and otherwise simply ignore it.
> 
Why have a field that is potentially usable ignored?

_J

> 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
> _______________________________________________________________
> 
> 


-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
From field.