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.
Klaus
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
