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