[vdr] Re: Merging AutoPID-patch into VDR before 1.2.0 (was: Re: Re: pcr <> vpid)

[Andreas Schultz <aschultz@warp10.net>]

On Tuesday 22 April 2003 18:19, Rene Bartsch wrote:
> Klaus Schmidinger schrieb:
>  >>There was a great deal of activity on the list regarding the handling of
>  >>PCR<>VPID but nothing seems to have come out of that yet.  Is this
>  >>something that has to wait for 1.2.0 or later?  Or is there a patch on
>  >>the horizon.
>  >
>  > This will be one of the next things I add to VDR, _before_ version
>  > 1.2.0.
>
> What about adding Andreas Schultz's AutoPID-patch?

it's using STL, i'm not going to change that and Klaus doesn't want STL in 
vdr's core. Also, the impact of some changes required is rather large and 
there are even some required conceptual changes that i have not yet 
addressed. Short incomplete list of topics:
- tuning to a transponder without a channel
- tuning to a channel/service that is not in the channels list - linking
  services to a channel
- plugin interface for section filters (i have one, but it uses STL and i know 
  that even without STL Klaus will hate it ;)

So, all in all i believe that the patch will not be accepted in its current 
form and i'm not sure that it is yet ready for inclusion.

> Of course, it will need some debugging, but I think it will be the best
> solution to merge it in before 1.2.0.

well, the latest version is quite stable, the scanner needs some more work, 
and some more config options. 

> This will also solve the problems with channels.conf. It's a mess to get
> a channels.conf with all channels for TV and Radio for the satelites
> personally used. Especially as channel information often are dynamically.
>
> Currently additional channel-scanners are necessary for that. But that's
> no option for dummy-users only having OSD and no idea of linux.
>
> With the AutoPID-patch you wouldn't need to ship a channels.conf but
> only a transponders.conf with VDR and VDR would update channels.conf
> automatically.

The all-time automatic update of channels.conf is certainly not what you would 
want for normal operation. Only NVOD channels and linked services should IMHO 
be updated dynamicaly.

> The problem would be the line-based sorting of channels.conf (which I'm
> praying to skip for a year, now). This could be solved by an additional
> field "channel-number" which stores the unique number of the channel
> beginning with "1". A new channel simply would get the next free number.

Source+Nid+Tid+Sid uniquely describe a channel, using those and map them to 
channel numbers should solve your problem.

> This way the user would have a static number for each channel. And when
> the user rearranges sorting of channels, the channel-number in
> channel-number field would be changed instead of the line.
>
> Rene



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