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.
vdr mailing list