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 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.
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 expected. 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.
Klaus