From patchwork Tue Mar 26 08:23:53 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Klaus Schmidinger X-Patchwork-Id: 17623 Received: from localhost ([127.0.0.1] helo=www.linuxtv.org) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1UKPAp-0005MZ-L4; Tue, 26 Mar 2013 09:24:04 +0100 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1UKPAm-0005MR-Ry for vdr@linuxtv.org; Tue, 26 Mar 2013 09:24:01 +0100 X-tubIT-Incoming-IP: 188.40.50.18 Received: from racoon.tvdr.de ([188.40.50.18]) by mail.tu-berlin.de (exim-4.75/mailfrontend-4) with esmtps [TLSv1:AES256-SHA:256] for id 1UKPAm-0004nA-AD; Tue, 26 Mar 2013 09:24:00 +0100 Received: from dolphin.tvdr.de (dolphin.tvdr.de [192.168.100.2]) by racoon.tvdr.de (8.14.5/8.14.5) with ESMTP id r2Q8NxZD009567 for ; Tue, 26 Mar 2013 09:23:59 +0100 Received: from [192.168.100.11] (falcon.tvdr.de [192.168.100.11]) by dolphin.tvdr.de (8.14.4/8.14.4) with ESMTP id r2Q8Nrjw031491 for ; Tue, 26 Mar 2013 09:23:53 +0100 Message-ID: <51515B19.6000203@tvdr.de> Date: Tue, 26 Mar 2013 09:23:53 +0100 From: Klaus Schmidinger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: VDR mailing list X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.26.81815 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __BAT_BOUNDARY 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __URI_NO_MAILTO 0, __URI_NS , __USER_AGENT 0' X-LSpam-Score: -1.1 (-) X-LSpam-Report: No, score=-1.1 required=5.0 tests=BAYES_00=-1.9, RDNS_NONE=0.793 autolearn=no Subject: [vdr] [PATCH] VDR 1.7.42: fix pending timers X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: vdr-bounces@linuxtv.org Errors-To: vdr-bounces@linuxtv.org There has been a bug report regarding overlapping "pending" timers. The original posting can be found here: http://www.vdr-portal.de/board17-developer/board97-vdr-core/p1134445-probleme-mit-aufnahmepriorit%C3%A4ten-und-wahrscheinlich-devicebonding/#post1134445 The diagram "version 2" shows 3 timers with different priorities, where timers 1 and 3 can record simultaneously, while timer 2 can only record by itself. This is due to limitations imposed by "device bonding", but similar situations may also occur in other environments. The problem here is that at time 'C', timer 3 starts and forces timer 2 to stop due to its higher priority. Now timer 1 would also be able to record, but it doesn't do so until timer 2 expires. This is caused by timers 1 and 2 being in the "pending" state, but timer 2 always being chosen in cTimers::GetMatch(time_t t) due to its higher priority. The attached patch fixes this. Please apply and test it. I'm considering to include this in the final version 2.0.0 which shall be released on sunday, so I need to know whether it causes any negative side effects. Klaus --- timers.c 2013/03/16 10:37:10 2.17 +++ timers.c 2013/03/25 10:44:46 @@ -720,8 +720,10 @@ for (cTimer *ti = First(); ti; ti = Next(ti)) { if (!ti->Recording() && ti->Matches(t)) { if (ti->Pending()) { - if (ti->Index() > LastPending) + if (ti->Index() > LastPending) { LastPending = ti->Index(); + return ti; + } else continue; }