[vdr] Disabling EPG update from air or shift it in time

Alex Betis alex.betis at gmail.com
Sun Feb 1 15:10:33 CET 2009


On Sun, Feb 1, 2009 at 11:58 AM, Klaus Schmidinger <
Klaus.Schmidinger at cadsoft.de> wrote:

> On 31.01.2009 11:51, Alex Betis wrote:
> > ... [ EPG for time shifted channels ] ...
>
> >     > As an example, 75.0E has NTV and NTV-2, or DTV and DTV-2
> >
> >     Please post the complete channels.conf entries of these channels.
> >
> > Here it is:
> >
> > This couple looks like sending the EPG shifted correctly:
> > HTB;GTSS:12640:vM2O0S0:S75.0E:22000:503:504,505:0:0:100:58:103:0
> > HTB-3;GTSS:12640:vM2O0S0:S75.0E:22000:501:502:0:0:500:58:103:0
> >
> > This couple looks like not shifting the EPG at all:
> > DTV-0;GTSS:12640:vM2O0S0:S75.0E:22000:201:202:0:0:200:58:103:0
> > DTV-2;GTSS:12518:vC78M2O0S0:S75.0E:22000:701:702=eng:0:0:504:86:100:0
> >
> > This one looks like shifting the EPG in wrong direction (its scrambled,
> > but I've compared the content of EPG.data with official site):
> > CTC+7;CTC Media:12640:vM2O0S0:S75.0E:22000:401:402:0:2600:400:58:103:0
>
> Looks like you got all sorts of variations: some do it right, some do
> it wrong, and some don't do it at all ;-)
>
> Since every channel has its own SID, it also has its own EPG data, which
> logically needs to correspond to the times the programmes are actually
> broadcast. So far I don't se any proper solution than having the providers
> fix this.

As I wrote, those channels started transmitting EPG not long ago, so I hope
the issue will be fixed one day. I agree that its probably a provider fault.
Anyway, I think a configuration that will allow disabling EPG from DVB might
be useful for those who retrieve all EPG data from the net, that in most
cases contains more data than transmitted by the provider.

By the way, if we already discussing EPG...
I think the epg.data is very limited. I would like to see an option to
integrate pictures or even movies in that file.
Ofcause I could place tags in description and have a plugin that could parse
those tags and show the pictures stored somewhere else, but I think it
should all be located in the same place.


>
>
> >     >     > I use s script that updates those channels from internet, so
> >     I don't
> >     >     > mind to disable EPG update received on the channel.
> >     >
> >     >     You can set the "table id" of these events to 0 (see man 5
> vdr).
> >     >
> >     > The problem is not with overwriting the data, but appending the
> wrong
> >     > data for that channel.
> >     > I see both script inserted and DVB transmitted data that are
> differ.
> >     >
> >     > Is there such "table id" setting per channel and not per EPG entry?
> >
> >     No, this is per EPG event, not per channel.
> >
> > I'll probably patch the code for now to disable the received EPG
> processing.
> >
> > But as I see it, there is an issue even when the EPG is correctly
> > transmitted by a provider, for example:
> > What VDR will do when there is a change in the program and there is a
> > delay in transmission of some program?
> > Will it have 2 entries for the same program or update the previous entry?
>
> VDR will update/replace all EPG entries according to the new tables.
> There shouldn't be double entries.
>
> > If EPG time is in UTC, than that's a mystery how should those coupled
> > channels be handled.
>
> As I said, each channel has its own SID, and therefore its very own
> EPG data, which needs to be adjusted to the actual broadcast times
> of that channel.
>
> As an example: if you have two channels, say ABC and ABC+1, where ABC+1
> broadcasts everything one hour later that ABC, then if the air time of
> event XY is 8:00 for channel ABC, it needs to be 9:00 for channel ABC+1.
> All times given in UTC, of course.
>
> Klaus
>
> _______________________________________________
> vdr mailing list
> vdr at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/vdr/attachments/20090201/cea78396/attachment.htm 


More information about the vdr mailing list