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. Extending this to priorities down to -99
doesn't change anything, and I currently see no real advantage in it:
Why would someone want an unimportant stream with priority -10, and
another with -20? VDR itself doesn't use them, so anything below 0 would
be the same.

Maybe, with some ugly hacks, Streamdev could emulate the old
PrimaryLimit by adding some kind of priority offset to all streams, but
as long as the rest is all broken, there's no real point in it.

> - instead of any negative priority, only priority -MAXPRIORITY gets the
> special meaning of "may be detached anytime"

See above. Would require transfer mode to run on -99 too, otherwise
would re-introduce live TV freeze.

> - 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.



vdr mailing list

Reply via email to