[vdr] Re: what is supposed to be going on with EPG in vdr-1.2.5

[Jeremy Hall <jhall@maoz.com>]

I have implemented a fix that works for me when the NID and TID are 
correct, and am currently debugging the condition which occurs when the 
NID and TID fields are set to 0.  When I have that working, I will send 
you a patch.

I had not seen this autopid patch, so will go investigate it.  I also 
would like to make the suggestion that care be taken so that if the EPG 
section has been seen before and the version matches that which is on 
file, the section is not processed to save CPU cycles.  This helps when a 
machine cannot process sections in real time and thus may want to pick one 
up next go around, but if we're processing all the sections and are too 
slow, we'll never catch up and it'll be a race condition to grab all the 
EPG data.

_J

In the new year, Klaus Schmidinger wrote:
> Jeremy Hall wrote:
> > 
> > Hello,
> > 
> > I have made me a channels.conf which looks normal but has the following
> > three fields added which are populated with correct infos.
> > 
> > 11: original network id
> > 
> > 12: original transport id
> > 
> > 13: an arbitrary number in case of conflict that is administratively
> > controlled and guaranteed to be unique
> > 
> > now I observe the following:
> > 
> > The EPG is transmitted in bulk for an administrative domain consisting of
> > several original network ids, but vdr is ignoring all entries for channels
> > not in the network id of the transponder holding the EPG, for example
> > 
> > If the guide is on network 1000 on transponder 1, all entries for network
> > 1000 are accepted, but entries for network 1002 are ignored.  If you tune
> > to a channel on network 1002, for a while you have no EPG data for that
> > channel, because vdr didn't learn about those guide entries from the other
> > network.
> > 
> > What I want is:
> > 
> > If the original network id field and transport service id fields are
> > properly filled in, if you have a channel defined in your channels.conf or
> > some other means, i.e. vdr knows about this channel, go ahead and load
> > data learned about it from another network.  One could allow a
> > configuration directive:
> > 
> > allow other networks to be friends
> > 
> > or
> > 
> > define which networks belong to an autonomous system, and permit the
> > definition of multiple autonomous systems
> > 
> > NOTE: the loose definition here of an autonomous system is a set of
> > networks and transponders that share a common administrative domain.
> > Confederation would also do.
> > 
> > It looks like the hooks are in place to keep all the channels straight in
> > the backend, but something in vdr is preventing friends from notifying us
> > of EPG information.  If this doesn't make sense, please ask questions.
> 
> The problem may be that VDR currently doesn't use the NID/TID yet to identify
> the channel related to a given EPG event.
> See VDR/eit.c:
> 
>    //XXX TODO use complete channel ID
>    cChannel *channel = Channels.GetByServiceID(CurrentSource, VdrProgramInfo->ServiceID);
>    tChannelID channelID = channel ? channel->GetChannelID() : tChannelID(CurrentSource, 0, 0, VdrProgramInfo->ServiceID);
>    channelID.ClrRid();
>    //XXX
> 
> This will be changed soon by adopting stuff from the 'autopid' patch.
> You might want to try that patch (see related postings here on the list)
> and see whether it already implements what you want.
> 
> Klaus
> 
> 
> -- 
> Info:
> To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.
> 



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