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
> > beginning
> > the full featured DVB cards were unable to record and play at the same
> > time.
> > 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
> > ability
> > to do simultaneous recording and replay a long time ago, and the new TT
> > S2-6400
> > 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.
Regards,
Frank
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
