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 >>> viewing >>> (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 > 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 ;-) 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. > http://projects.vdr-developer.org/attachments/355/vdr-1.7.12-detachreceiver-4.diff For description: http://projects.vdr-developer.org/issues/show/10 > 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 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... Cheers, Udo _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
