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