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
