From patchwork Sat Aug 26 14:35:29 2006 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Klaus Schmidinger X-Patchwork-Id: 12378 Received: from raven.cadsoft.de ([217.7.101.211]) by www.linuxtv.org with esmtp (Exim 4.50) id 1GGzG4-0003gw-F4 for vdr@linuxtv.org; Sat, 26 Aug 2006 16:35:36 +0200 Received: from [192.168.100.10] (hawk.cadsoft.de [192.168.100.10]) by raven.cadsoft.de (8.13.3/8.13.3) with ESMTP id k7QEZZ5q024639 for ; Sat, 26 Aug 2006 16:35:35 +0200 Message-ID: <44F05C31.7010303@cadsoft.de> Date: Sat, 26 Aug 2006 16:35:29 +0200 From: Klaus Schmidinger Organization: CadSoft Computer GmbH User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: vdr@linuxtv.org Subject: Re: [vdr] Re: VDR prefers my CI DVB device for recordings and blocks it unnecessarily References: <20060820230505.17688GcOzDp244@wizard.castle> <44E8EB72.2040906@gmx.de> <44E9536B.500@cadsoft.de> <44E9B129.3060501@gmail.com> <44EC797C.6020902@gmail.com> <44F037CC.9090700@cadsoft.de> <44F040BE.1090605@gmail.com> <44F05425.5080707@gmail.com> In-Reply-To: <44F05425.5080707@gmail.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (raven.cadsoft.de [192.168.1.1]); Sat, 26 Aug 2006 16:35:36 +0200 (CEST) X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Aug 2006 14:35:36 -0000 Status: O X-Status: X-Keywords: X-UID: 10519 Anssi Hannula wrote: > ... > Attached is a patch which has this approach. > > So after *this* patch the above quoted scenario would continue like this > instead: > - recording is made via budget card (same behaviour as VDR 1.4.1) if > AvoidPrimaryDevice is set > - recording is made via FF card (leaving budget free) if > AvoidPrimaryDevice is not set. > > Also if AvoidPrimaryDevice is set, budget with CAM would be preferred > over non-CAM FF for recording FTA channels in the original situation. As I said I don't like introducing additional setup options for this. We already have the infamous "Primary limit", which was introduced at a time where the FF cards were unable to receive and record at the same time (this option will be removed in version 1.5, BTW). I'll probably take another look at your first patch - maybe I missed something when I asked whether it would also avoid a non-primary device if the transfer mode is coming from there. At any rate, this certainly requires more testing, so I'll do as suggested by Udo Richter and revoke this change altogether and release version 1.4.2 tomorrow. Just so that people can check this out, I have attached this final modification. Klaus --- device.c 2006/08/12 11:33:34 1.135 +++ device.c 2006/08/26 14:11:03 1.136 @@ -292,7 +292,7 @@ // to their individual severity, where the one listed first will make the most // difference, because it results in the most significant bit of the result. uint imp = 0; - imp <<= 1; imp |= !device[i]->Receiving(true) || ndr; // use receiving devices if we don't need to detach existing receivers + imp <<= 1; imp |= !device[i]->Receiving() || ndr; // use receiving devices if we don't need to detach existing receivers imp <<= 1; imp |= device[i]->Receiving(); // avoid devices that are receiving imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice(); // avoid the Transfer Mode receiver device imp <<= 8; imp |= min(max(device[i]->Priority() + MAXPRIORITY, 0), 0xFF); // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used)