[vdr] [ANNOUNCE] vdr 1.3 SUSE RPMs

Klaus Schmidinger Klaus.Schmidinger at cadsoft.de
Sun Jun 19 12:12:07 CEST 2005


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:

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?

> 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



More information about the vdr mailing list