[vdr] Re: Editing the Tid from VDR's OSD?

[Jeremy Hall <jhall@maoz.com>]

Hi,

I haven't read the entire thread, but this is probably having something to 
do with providers "moving" channels.

I don't know if they're using the "channel is moving" descriptor, whatever 
that is, but if vdr isn't running, it won't see that anyway and the 
channel will have moved.

If, in this example, NASA TV were to move to Echostar 8, the network id, 
transponder id, and frequency/pol/srate/pids would move.  In this case, 
the old channel is no longer valid and the new one is.

In this case it might be a good idea to bind nid/tsid pairs to user 
definable groups, and then a service id could be unique within that scope.  
Vdr could find the correct channel to "change" then.

_J

In the new year, C.Y.M. wrote:
> 
> > 
> > How is that? Is there an algorithm to do this math? In 
> > general I don't believe
> > that there is such a correlation - maybe some provider has 
> > invented such a thing
> > for their own purposes, but AFAIK the standard doesn't mention that.
> > 
> > AFAIK the NID and TID define a particular transport stream 
> > and are independent
> > of the actual transponder frequency. What strange channels 
> > are these that jump
> > around like that, changing both transponder frequency _and_ 
> > TID at the same time?
> > There is no way such a channel could be followed 
> > automatically - unless there
> > is some additional information in the data stream that VDR 
> > doesn't process yet...
> > 
> > Klaus
> > 
> > 
> 
> In North America, AFAIK, there has always been a direct correlation b/n the
> freq. and the Tid.  All of the providers that I have seen behave in this
> fashion.  In Canada, the providers seem to make a sport out of jumping the
> channels to different transponders every few months.  In every case, I have
> always been able to match a specific Tid with a specific transponder
> frequency (and the relationship between the two never changes). If one
> changes, then they both change.  It may not be the correct standard, but it
> seems to be how they always do it.  Here is an example of how I parse the
> sdt for a FTA channel in North America:
> 
> <sdt>
> <version id="27"/>
> <section id="0" max_section="0"/>
> <network id="4100" tsid="6"/>
> <service id="213" ca="0">
> <descriptor tag="0x4a" data="001310048ffd02" text="......." />
> <description tag="0x48" type="154" provider_name="NASA" service_name="NASA"
> />
> <descriptor tag="0x93" data="028a" text=".." />
> <descriptor tag="0x86" data="0101002c00ffff" text="......." />
> <stream type="2" pid="5922">
> </stream>
> <stream type="4" pid="5923">
> <iso_639 language="eng" type="0" />
> </stream>
> </service>
> 
> If I am tuned to channel 213, and parse the channel, the results will always
> give me the correct Tid (tsid).  If no vpid/apids are displayed, then I know
> my channels.conf is not tuned to the correct frequency.  I can look up on a
> table what frequency is related to Tid=6 (which is always 12297 in this
> case) and fix it.  I currently do not have the source code for this parsing
> application, but I may be able to find it if you think it would help.  But,
> VDR seems to already be capable of determining the correct Tid/Nid values on
> its own from the stream as it is.  I would just like to be able to edit the
> channels.conf and fix a channel so the epg is displayed properly w/o having
> to stop VDR.  In North America, that would mean having to change both the
> freq. and the Tid if a channel has changed tranponders.
> 
> Thanks,
> C.Y.M.
> 
> 
> 
>