[ANNOUNCE] vdr 1.3 SUSE RPMs

  Carsten Koch wrote:
> Ludwig Nussel wrote:
> 
>> Carsten Koch wrote:
>>
>>> Ludwig Nussel wrote:
>>>
>>>> I've built RPM packages for 1.3.26. Video directory and epg file
>>>> location is the same as in the 1.2.6 packages, config files are in
>>>> /etc/vdr13 instead of /etc/vdr. So you can safely install 1.3 in
>>>> parallel to the 1.2.6 packages. vdr contains minimal patches. the su
>>>> patch, the patch to use a broadcast variable instead of sleep in
>>>> cDvbPlayer and pagedown.diff from Udo Richter. I also removed the
>>>> check for NPTL and vdr does run with NPTL if available. 
>>>
>>>
>>> I absolutely cannot use VDR without the SourceCaps patch, since I
>>> have 3 DVB-S cards connected to 2 different dishes.
>>
>>
>>
>> I've never heard about that one or forgot about it because I don't
>> need it. Was it ever posted here for official inclusion?
> 
> 
> Yes.
> It startet on January 18th, 2004 with a posting by Christian Schuld
> (the patch author).
> I posted a version on April 6th, 2005, that was adopted to the latest
> VDR, see attachment.
> 
> 
>>> I also kind of like my own "delete_resume" patch which dramatically
>>> reduces the number of redundant resume.vdr files. See my posting
>>> from March 3rd, 2005. Of course, that patch is just "nice to have",
>>> not "cannot live without it".
> 
> 
> It started on January 30th, 2005.
> I posted it again on March 21st.
> See second attachment.
> 
> 
>>> I guess there will be many people who require one or another patch
>>> before they can use vdr.
>>>
>>> Any ideas?
>>
>>
>>
>> Try to convince Klaus to include the patches. I'd like to keep vdr
>> 1.3 patches in the package to a minimum at the moment so Klaus can
>> be blamed for bugs rather than the patches ;-)
> 
> 
> OK.
> 
> Klaus, as I said above, on a system without diseqc and with more than
> one dish, I believe Christian's SourceCaps patch is a must.
> It's also not very complicated and thus should not impose a high
> risk of breaking something in vdr.

Well, I still believe that the majority of systems will have only one
LNB, anyway, and any reasonable multi-LNB system should use a multiswitch.

Anyway, am I missing something here, or will this patch _require_ SourceCaps
to be set? If I look at

  bool cDvbDevice::ProvidesSource(int Source) const
  {
    int type = Source & cSource::st_Mask;
+  if(type == cSource::stSat  && frontendType == FE_QPSK)
+  {
+      for(int i = 0;i<MAXSOURCECAPS; i++)
+          if(sourceCaps[i] == Source)
+              return true;
+      return false;
+  }
+  else
    return type == cSource::stNone
        || type == cSource::stCable && frontendType == FE_QAM
-      || type == cSource::stSat   && frontendType == FE_QPSK
        || type == cSource::stTerr  && frontendType == FE_OFDM;
    return true;
  }

it would appear to me that this won't work if no SourceCaps are set.
If you really want this to go into VDR then you need to make sure
a system that does not have SourceCaps set (which IMHO will be the
majority) will still work.

BTW: what's with this:


Obviously this has nothing to do with SourceCaps - but what's it for then?

> My patch is just a performance optimization. On a system with very
> many recordings, it can become quite significant, though.
> It is even smaller than the SourceCaps patch, though
> and thus should not impose any risk of breaking something in vdr.

This is probably not worth the effort, because in a future VDR version
I will most likely store the selected audio track in that file, too, and
then deleting it wouldn't make sense any more.

Klaus
  

Klaus Schmidinger wrote:
...
> it would appear to me that this won't work if no SourceCaps are set.
> If you really want this to go into VDR then you need to make sure
> a system that does not have SourceCaps set (which IMHO will be the
> majority) will still work.

I fully agree that the default must be "source is provided".

I suppose a global flag "SourceCapsSet" which is initialized
to false and which is set true true by ParseSourceCaps should
do the trick?

After all, this is Christian's patch, so I do not want to take
it over unless Christian wants me to.
Christian, are you reading this?
Would you like to fix your patch so Klaus can accept it?


> 
> BTW: what's with this:
> 
> diff -ru /hetis/home/cko/VDR/sources.c VDR/sources.c
> --- /hetis/home/cko/VDR/sources.c    2004-12-26 12:58:52.000000000 +0100
> +++ VDR/sources.c    2005-04-05 22:12:55.421326944 +0200
> @@ -68,7 +68,7 @@
>       int pos = 0;
>       bool dot = false;
>       bool neg = false;
> -     while (*++s) {
> +     while (*++s && !isblank(*s)) {
>             switch (toupper(*s)) {
>               case '0' ... '9': pos *= 10;
>                                 pos += *s - '0';
> 
> Obviously this has nothing to do with SourceCaps - but what's it for then?

I do not know.
My guess is that Christian needed this in a previous version of
cSetup::ParseSourceCaps? After all, cSetup::ParseSourceCaps is
calling cSource::FromString.
I believe this hunk can safely be omitted.


Carsten.
  

Klaus Schmidinger wrote:
...
>> My patch is just a performance optimization. On a system with very
>> many recordings, it can become quite significant, though.
>> It is even smaller than the SourceCaps patch, though
>> and thus should not impose any risk of breaking something in vdr.
> 
> 
> This is probably not worth the effort, because in a future VDR version
> I will most likely store the selected audio track in that file, too, and
> then deleting it wouldn't make sense any more.

Please consider the performance hit that VDR takes when it has to
open an extra 500+ files (I currently have 519 recordings)
just to bring up the recordings menu.
It really does take a long time here already!

Your philosophy has always been to store all information
displayed in the recordings menu in the directory entry.
I believe you have done that for a good reason: do make
the creation of the recordings menu's contents perform well.
Why break that philosophy now?

Automatically removing "resume.vdr" files that point to the
first few seconds of a recording would again allow you
to stick to that philosophy 100%, since you would not
have to read the file at all to display the recordings menu.

Carsten.
  

Klaus.Schmidinger@cadsoft.de(Klaus Schmidinger)  19.06.05 12:12


>Well, I still believe that the majority of systems will have 
>only one LNB, 

The adavntage why i still use (the meanwhile relativley expensive) VDR 
is it's ability to use up to four cards, mixed(!) DVB-T, DVB-C, DVB-T. 
No commerical can do that (and will never, i assume). 
But they usualy have a clean "resource management"
which i am missing at VDR.


>anyway, and any reasonable multi-LNB system should use a
>multiswitch.

AFAIK there approx. 100 downloads of the LNBsharing patch
for 1.3.x.
As it is of very limited (actually no, as VDR already "locks" the
LNB in a single card system) use for the SingleLNB guys
i assume there are at least 50 users in that unlucky situation,
to have only one wire, which can ONLY be solved with VDR, AFAIK.

Affordable "Single-Wire-Solutions" are no solution - they 
will block many transponders.

There is a list of the most dangerous things in the world,
two i rember:
"A softworker with a solder iron" and:
"A software with a hardware patch".

The second fits your suggestion to fix missing 
the resource managent with a mulit-switch ;-).


And:
On Motor dishes a mulit-switch will not help much.

Too recently some asked if VDR is so clever that in a
two card system DVB-S and DVB-T will chosse the transmission
on the other system if the program is avaible on both...

I assume that should be solved from the ground and not by separate
"patches". Else it will be an endless story.


Ooops, i forgot to mention the "CA"-resources...




Rainer
  

Hi Carsten, 
Hi Klaus,

I will prepare a patch that doesn't change VDR's default behaviour. You are 
absolutly right about that.

On Sunday 19 June 2005 13:49, Carsten Koch wrote:
> Klaus Schmidinger wrote:
> ...
>
> > it would appear to me that this won't work if no SourceCaps are set.
> > If you really want this to go into VDR then you need to make sure
> > a system that does not have SourceCaps set (which IMHO will be the
> > majority) will still work.
>
> I fully agree that the default must be "source is provided".
>
> I suppose a global flag "SourceCapsSet" which is initialized
> to false and which is set true true by ParseSourceCaps should
> do the trick?

I will try a per device flag approach, which will give a bit more flexibility.

> After all, this is Christian's patch, so I do not want to take
> it over unless Christian wants me to.
> Christian, are you reading this?
> Would you like to fix your patch so Klaus can accept it?

Yes, I will try, I will post to the list so that you can review it, when it is 
ready.

> > BTW: what's with this:
> >
> > diff -ru /hetis/home/cko/VDR/sources.c VDR/sources.c
> > --- /hetis/home/cko/VDR/sources.c    2004-12-26 12:58:52.000000000 +0100
> > +++ VDR/sources.c    2005-04-05 22:12:55.421326944 +0200
> > @@ -68,7 +68,7 @@
> >       int pos = 0;
> >       bool dot = false;
> >       bool neg = false;
> > -     while (*++s) {
> > +     while (*++s && !isblank(*s)) {
> >             switch (toupper(*s)) {
> >               case '0' ... '9': pos *= 10;
> >                                 pos += *s - '0';
> >
> > Obviously this has nothing to do with SourceCaps - but what's it for
> > then?
>
> I do not know.
> My guess is that Christian needed this in a previous version of
> cSetup::ParseSourceCaps? After all, cSetup::ParseSourceCaps is
> calling cSource::FromString.
> I believe this hunk can safely be omitted.

No, tried this, but omitting breaks the patch. The reason for this small patch 
is that without the !isblank(*s) term the cSourceFrom::FromString won't 
accept a list of source ssepareted by white spaces, which is need to keep the 
parsing simple. For expample parsing a string like "SourceCaps = 1 S13.0E 
S19.2E S5.0E" will lead to three cSource::FormString(...) calls with this 
input strings
"S13.0E S19.2E S5.0E"
"S19.E S5.0E"
"S5.0E"
Without the !isblank(*s) term the return value would be stNone, which is not 
exactly what i need ;-)
But if you dislike this behaviour, i will change the Parse function and leave 
cSource untouched?

Have a nice day (and nice holiydays)

> Carsten.

Christian