[vdr] [ANNOUNCE] VDR developer version 1.7.24
Klaus.Schmidinger at tvdr.de
Sat Feb 25 15:39:17 CET 2012
On 25.02.2012 00:21, Frank Schmirler wrote:
> On Fri, 24 Feb 2012 19:33:06 +0100, Udo Richter wrote
>> Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
>>> IIRC that whole "Primary Limit" thing was introduced because in the
>>> the full featured DVB cards were unable to record and play at the same
>>> So it could happen that a timer occupied the primary device and left the
>>> user with a black screen. Since the old FF cards have been given the
>>> to do simultaneous recording and replay a long time ago, and the new TT
>>> has been able to do this from the very start, I'd rather prefer to do
>>> away with
>>> the "Primary Limit" altogether - to make things simpler instead of more
>>> complex ;-)
> I was not aware of this as I have no FF card. For me, "Primary Limit" always
> was the "Priority of Live TV". Ok, MANUAL talks about being allowed to "use
> the primary DVB interface" and not denial to "affect live TV", but the use
> case "recordings that should take place only when there is nothing else to do,
> but should never keep the user from viewing stuff on the primary interface"
> clearly pointed into that direction.
> Always using priority 0 instead of a configurable "Primary Limit" means
> there's no way to get anything with less priority than live TV but without the
> "may always be detached" meaning of negative priorities.
> Streamdev is using the "Primary Limit" to control priorities between multiple
> clients and partially also between clients and server. Only "partially" due to
> transfer mode receiver device running with priority -1. Currently a plugin
> can't simply call GetDevice with a non-negative priority without disturbing
> Live TV in transfer mode. Some ugly workarounds were necessary in streamdev to
> handle this.
>>> Well, I don't like the idea of introducing yet another parameter
>>> ("volatile") here.
>>> The "priority" should be sufficient to solve this. So if you can suggest
>>> a solution
>>> that works solely with priorities, I might take a look ;-)
> Well, the -1 priority on the transfer mode receiver device solves the
> "receivers still attached when switching channels" problem. But it introduces
> an exceptional case which causes problems (osdteletext) or makes apparently
> simple things hard to handle (streamdev GetDevice). Trading this for an
> explicit parameter sounds like a very good deal to me.
>> Letting VDR know that a device will probably soon be detached was
>> one of the smarter solutions to this. Another alternative I was
>> thinking of was to let the device know that a receiver is 'live-
>> related', and thus can be canceled for another live view, but the
>> 'volatile' solution was more general.
>> Maybe it would be possible to manually lower the transfer mode receivers
>> to -1 when calling GetDevice with live view, and raise them back to
>> PrimaryLimit (or 0) at the end. Not sure if that's more elegant...
> +1 for the "volatile" solution. Streamdev-server has to handle channel
> switches, too. On the server side they are not "live-related", but the problem
> is the same: The receivers for the previous channel are still attached.
> "Volatile" would obsolete an other workaround in streamdev.
Definitely *no* "volatile"!
PrimaryLimit is going to be dropped, since the old FF-DVB cards can now (since
version 1.7.21) be run with the --outputonly option to avoid problems with recording
high bandwidth channels. Besides, with HDTV becoming ever more popular those cards
are pretty much obsolete by now (the TT S2-6400 has no problems recording and replaying
high bandwidth channels simultaneously). And, last but not least, people using software
players won't notice this change, anyway.
There was also apparently some misunderstanding about what PrimaryLimit was supposed
to do. It was *never* meant to allow "Channel switching can cancel timers with priority <= Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr-developer.org/issues/show/10).
Its sole purpose was to not use the primary device for recording low priority
timers and leave the user with a black screen. Those days are long gone, and PrimaryLimit
is obsolete and causing nothing but trouble.
A recording shall *always* have priority over live viewing.
Since cReceivers can have priorities between -99 and 99, the priority
for an unused device has been changed from -1 to -100.
The attached patch implements all these changes (*.po files left out for
clarity). Please try this and let me know if anything doesn't work as
I did try running a recording on the primary device, so that live view
would be done in Transfer mode from the secondary device (only two devices
activated for testing) and had no problem with zapping through channels
with Up/Down. I also tried starting a recording on device 2 while in
Transfer Mode, and the live channel was switched to device 1 when the
recording kicked in.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 10809 bytes
Desc: not available
More information about the vdr