From patchwork Sat Aug 26 14:01:09 2006 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Anssi Hannula X-Patchwork-Id: 12377 Received: from pne-smtpout3-sn2.hy.skanova.net ([81.228.8.111]) by www.linuxtv.org with esmtp (Exim 4.50) id 1GGyjP-000878-HM for vdr@linuxtv.org; Sat, 26 Aug 2006 16:01:51 +0200 Received: from mail.onse.fi (80.223.77.223) by pne-smtpout3-sn2.hy.skanova.net (7.2.075) id 44A2F3EC00202477 for vdr@linuxtv.org; Sat, 26 Aug 2006 16:01:20 +0200 Received: from [10.0.0.3] (kone [10.0.0.3]) by mail.onse.fi (Postfix) with ESMTP id 550404708287 for ; Sat, 26 Aug 2006 17:01:11 +0300 (EEST) Message-ID: <44F05425.5080707@gmail.com> Date: Sat, 26 Aug 2006 17:01:09 +0300 From: Anssi Hannula User-Agent: Thunderbird 1.5.0.5 (X11/20060818) MIME-Version: 1.0 To: VDR Mailing List 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> In-Reply-To: <44F040BE.1090605@gmail.com> X-Enigmail-Version: 0.94.0.0 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:01:51 -0000 Status: O X-Status: X-Keywords: X-UID: 10514 Anssi Hannula wrote: > Klaus Schmidinger wrote: >> Anssi Hannula wrote: >>> >>> diff -Nurp -x '*~' vdr-1.4.1-5/device.c vdr-1.4.1-5-mod/device.c >>> --- vdr-1.4.1-5/device.c 2006-08-20 21:59:20.000000000 +0300 >>> +++ vdr-1.4.1-5-mod/device.c 2006-08-23 18:41:26.000000000 +0300 >>> @@ -292,7 +292,7 @@ cDevice *cDevice::GetDevice(const cChann >>> // 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() && device[i] != >>> cTransferControl::ReceiverDevice() || 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) >> Wouldn't this also avoid a non-primary device if the transfer mode >> is coming from there? I don't think that would be good... > > I don't understand what you mean. It just modifies the algorithm to > prefer receiving devices on the same transponder that have priority>=0 > receivers or transfer mode receivers. Before the patch it would prefer > any receiving devices on the same transponder, causing osdteletext > receiver to make a difference. > > Consider scenario > - user watches transponder 1 channel 1 through primary FF > - recording starts on transponder 1 channel 2 > > Before this patch: > - if osdteletext has a receiver on FF, the recording is made via FF > (Receiving(true) is true), otherwise via budget card > > After this patch: > - recording is made via budget card (same behaviour as VDR 1.4.1) > > > The alternative (more logical) fix would be to prefer transponder-tuned > primary devices too, so that the recording in above example would be > made by FF as it is tuned in the same transponder. But this would > probably not be a good idea (at least without YASO) due to the apparent > problems with recording via FF. > However, one possibility is to prefer the FF for recording in this > situation by default (which would leave the budget card free), and also > in the original situation (in which the budget has CAM), and have a > setup option for Avoiding primary device for recording at all cost. 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. diff -Nurp -x '*~' vdr-1.4.1-5/config.c vdr-1.4.1-5-alt/config.c --- vdr-1.4.1-5/config.c 2006-08-20 21:59:16.000000000 +0300 +++ vdr-1.4.1-5-alt/config.c 2006-08-26 16:22:30.000000000 +0300 @@ -275,6 +275,7 @@ cSetup::cSetup(void) CurrentDolby = 0; InitialChannel = 0; InitialVolume = -1; + AvoidPrimaryDevice = 0; } cSetup& cSetup::operator= (const cSetup &s) diff -Nurp -x '*~' vdr-1.4.1-5/config.h vdr-1.4.1-5-alt/config.h --- vdr-1.4.1-5/config.h 2006-08-20 21:59:24.000000000 +0300 +++ vdr-1.4.1-5-alt/config.h 2006-08-26 16:22:10.000000000 +0300 @@ -252,6 +252,7 @@ public: int CurrentDolby; int InitialChannel; int InitialVolume; + int AvoidPrimaryDevice; int __EndData__; cSetup(void); cSetup& operator= (const cSetup &s); diff -Nurp -x '*~' vdr-1.4.1-5/device.c vdr-1.4.1-5-alt/device.c --- vdr-1.4.1-5/device.c 2006-08-20 21:59:20.000000000 +0300 +++ vdr-1.4.1-5-alt/device.c 2006-08-26 16:45:13.000000000 +0300 @@ -292,9 +292,10 @@ cDevice *cDevice::GetDevice(const cChann // 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]->IsTunedToTransponder(Channel) || (Setup.AvoidPrimaryDevice ? !device[i]->Receiving() && device[i] != cTransferControl::ReceiverDevice() : device[i]->MaySwitchTransponder()); // use devices that are already tuned by something else, but don't count non-transfermode liveview if primary device is to be avoided 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 <<= 1; imp |= Setup.AvoidPrimaryDevice && device[i]->IsPrimaryDevice(); // avoid the primary device here if configured so 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) imp <<= 8; imp |= min(max(device[i]->ProvidesCa(Channel), 0), 0xFF); // use the device that provides the lowest number of conditional access methods imp <<= 1; imp |= device[i]->IsPrimaryDevice(); // avoid the primary device diff -Nurp -x '*~' vdr-1.4.1-5/menu.c vdr-1.4.1-5-alt/menu.c --- vdr-1.4.1-5/menu.c 2006-08-20 21:59:16.000000000 +0300 +++ vdr-1.4.1-5-alt/menu.c 2006-08-26 16:23:44.000000000 +0300 @@ -2572,6 +2572,7 @@ cMenuSetupRecord::cMenuSetupRecord(void) Add(new cMenuEditIntItem( tr("Setup.Recording$Instant rec. time (min)"), &data.InstantRecordTime, 1, MAXINSTANTRECTIME)); Add(new cMenuEditIntItem( tr("Setup.Recording$Max. video file size (MB)"), &data.MaxVideoFileSize, MINVIDEOFILESIZE, MAXVIDEOFILESIZE)); Add(new cMenuEditBoolItem(tr("Setup.Recording$Split edited files"), &data.SplitEditedFiles)); + Add(new cMenuEditBoolItem(tr("Setup.Recording$Avoid primary device"), &data.AvoidPrimaryDevice)); } // --- cMenuSetupReplay ------------------------------------------------------