[vdr] [ANNOUNCE] VDR developer version 1.7.24
Klaus.Schmidinger at tvdr.de
Wed Feb 29 16:17:07 CET 2012
On 28.02.2012 16:48, Frank Schmirler wrote:
> 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.
Even though VDR itself doesn't have the necessity for "remote receivers"
(yet), I see the problem for streamdev. I have therefore reconsidered
this matter and will make the following changes for the next developer
- Revised priority handling to allow receivers with a priority that is lower than
that of live viewing (with suggestions from Frank Schmirler):
+ An idle device (one that is not used for live viewing and has no receiver
attached to it) now has priority IDLEPRIORITY (-100).
+ An unused CAM slot now has priority IDLEPRIORITY.
+ The default priority of a cReceiver is now MINPRIORITY (-99).
+ A device that is used only for live viewing (no matter whether it's in Transfer
Mode or real live mode) now has priority TRANSFERPRIORITY (-1).
+ The function cDevice::Receiving() now returns true if there is any receiver
attached to the device. Its boolean parameter has no meaning any more.
+ The default value for the Priority parameter of the function cDevice::ProvidesChannel()
has been changed to IDLEPRIORITY.
When searching for a device for live viewing, VDR uses priority 0 for
the search (thus avoiding any devices that are serving actual timer recordings),
and - if going into Transfer Mode - gives the cReceiver a priority of -1.
That way the next search for a live device will be able to use the one
that is currently serving the Transfer Mode, because the search has a
higher priority (this is pretty much the same as it was before).
Now a "remote transfer mode" (which I assume is what streamdev and the like
implement) can use a "search priority" of, say, -10, and a transfer priority
of -11. That way the remote mechanism will also be able to reuse devices,
just like local Transfer Mode. And local live mode can override remotely
used devices due to its higher priority.
I'm currently testing these changes in my own production VDR (local live and transfer mode
only) and will release them in version 1.7.25 shortly. Let me know then if this works
More information about the vdr