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 version:
- 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 for you.
Klaus