Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
> On 24.02.2012 15:37, Frank Schmirler wrote:
>> On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
>>> - Fixed handling the PrimaryLimit when requesting a device for live
>>> (reported by Uwe Scheffler).
Hmmm, didn't even notice that change...
>> Anyway, I think a better way to fix the problem would be to change the
>> priority parameter of the GetDevice calls involved from
>> "GetDevice(channel, 0,
>> true)" to "GetDevice(channel, Setup.PrimaryLimit, true)". There are
>> two calls
>> in device.c and one call in menu.c.
My 'volatile' patch did this, and it worked so far. I like that a lot
more than the 1.7.24 solution that just adds another quirk to the
priority system. If in doubt, this should just raise the priority on
channel switching. I don't think that it would cause any negative side
effects, esp. since this priority is ignored at the end anyway. (see below)
> 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 ;-)
Keep in mind that a recording on an un-modded SD-FF device nowadays can
cause broken recordings because of limited bandwidth. Being able to
record and play at the same time is a rather theoretical ability,
especially if its transfer mode playback.
However, I never had PrimaryLimit set to anything but 0.
> 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 ;-)
That patch actually goes the same way as the above fix, but beside that
its more about the detaching issue, and just fixed the PrimaryLimit
issue on the way, so its not directly related. Even dropping
PrimaryLimit wouldn't solve this issue.
One of the core problems is that VDR selects a new device for live
viewing before disconnecting the old live device. Thus, all live related
receivers will still be present and will block the current device from
being re-used. VDR works around this just because live view has no
receivers (FF cards) or -1 priority receivers (transfer mode,
subtitles), that are always of lower priority than anything.
As a conequence, VDR has to ignore the '-1 can always be disconnected'
rule, or it would also disconnect transfer mode on timers, regardless of
free devices. And this leads to the osdteletext issue that the teletext
receiver still blocks the device on channel switch. VDR's own receivers
also work around this because they get disconnected before doing the
final and counting GetDevice call, but plugins cannot do that at that time.
A clean solution should imho do these things:
- Fix the find-device-before-disconnecting loop
- Transfer mode devices with 'real' priorities
- Honor the -1 priority as always-detachable
In the end, you need to know at a very early point (ChUp pressed etc.)
whether a device will be available for live view, even if it is still
used right now, and might be used on (if ChUp fails).
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
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...
vdr mailing list