[vdr] [ANNOUNCE] VDR developer version 1.7.24

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Mon Feb 27 18:05:39 CET 2012

On 27.02.2012 14:33, Frank Schmirler wrote:
> On Sat, 25 Feb 2012 15:39:17 +0100, Klaus Schmidinger wrote
>> There was also apparently some misunderstanding about what
>> PrimaryLimit was supposed to do. It was *never* meant to allow
>> "Channel switching can cancel timers with priority<=
>> Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr-
>> developer.org/issues/show/10). Its sole purpose was to not use the
>> primary device for recording low priority timers and leave the user
>> with a black screen. Those days are long gone, and PrimaryLimit is
>> obsolete and causing nothing but trouble.
>> A recording shall *always* have priority over live viewing.
> I would be fine with that with respect to recordings, but this shouldn't be
> generally true for cReceivers. What I'm hoping to get is the possiblity to
> attach a cReceiver with a lower priority than live TV but without the
> "cReceivers with negative priority do not count".
>> Since cReceivers can have priorities between -99 and 99, the priority
>> for an unused device has been changed from -1 to -100.
> Udo Richter's patch basically turned "PrimaryLimit" into a configurable
> "LiveTV priority". A "LiveTV priority">  0 gains you cReceivers with a
> priority less than live TV but still non-negative. To fix the "Transfer mode
> receiver device has priority -1" problem, he introduced "volatile".
> Instead of a configurable "LiveTV priority", your approach uses the fixed
> priority value 0 for LiveTV. The new idle priority of -100 opens the range for
> cReceivers with negative priority. The problem is, that *any* negative
> priority is still considered as "may be detached anytime", so there's still no
> real "cReceiver with less priority than live TV".
> I suggest the following additional changes:
> - instead of any negative priority, only priority -MAXPRIORITY gets the
> special meaning of "may be detached anytime"
> - the constructor of cReceiver should use default priority -MAXPRIORITY, so
> not all plugins have to be updated to keep their previous behaviour
> - use LIVEPRIORITY-1 as priority for cTransfer
> I can't however overlook the impact these modifications have.

Me neither - and that's why I strongly oppose them ;-)

What exactly is the use case for this, anyway?

VDR has two purposes: "live view" and "recording". And the current
priority scheme handles this pretty well IMO.


More information about the vdr mailing list