On Mon, 27 Feb 2012 21:29:44 +0100, Udo Richter wrote > Am 27.02.2012 14:33, schrieb Frank Schmirler: > > 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". > > Unfortunately not, because "may be detached anytime" is intentionally > broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live > TV freeze on recording start" bug. Ah, I see. The "Receiving(true)" in cDvbDevice::ProvidesChannel which came in with 1.3.8. That was the missing piece. Thanks for pointing me there. > > - 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 > > Such -1 offset workarounds usually don't work, I would prefer not to > have them. For example, one transfer device can still block another > before detaching or via Streamdev. The only consistent solution is to > give transfer mode the same priority as primary device live priority, > either PrimaryLimit or 0. That was an attempt to get a solution without "volatile". A "don't ever use priority "PrimaryLimit" (or 0) elsewhere" would have been better than nothing. Regards, Frank _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
