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