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