From patchwork Sun Feb 26 16:26:45 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Klaus Schmidinger X-Patchwork-Id: 12931 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1S1gw0-0007XS-Qx for vdr@linuxtv.org; Sun, 26 Feb 2012 17:27:17 +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 1S1gw0-0000Hh-B3; Sun, 26 Feb 2012 17:26:52 +0100 Received: from dolphin.tvdr.de (dolphin.tvdr.de [192.168.100.2]) by racoon.tvdr.de (8.14.3/8.14.3) with ESMTP id q1QGRChh030311 for ; Sun, 26 Feb 2012 17:27:13 +0100 Received: from [192.168.100.10] (hawk.tvdr.de [192.168.100.10]) by dolphin.tvdr.de (8.14.4/8.14.4) with ESMTP id q1QGQjql026265 for ; Sun, 26 Feb 2012 17:26:45 +0100 Message-ID: <4F4A5D45.2080305@tvdr.de> Date: Sun, 26 Feb 2012 17:26:45 +0100 From: Klaus Schmidinger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.26) Gecko/20120124 SUSE/3.1.18 Thunderbird/3.1.18 MIME-Version: 1.0 To: vdr@linuxtv.org References: <4D73B330.6080503@tvdr.de> <20110307115410.M30707@linogate.de> <4D74D0AB.5050408@tvdr.de> <20110307125423.M60134@linogate.de> <4D74DAFB.3060002@tvdr.de> <4D7CB3DA.6020809@tvdr.de> In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (racoon.tvdr.de [188.40.50.18]); Sun, 26 Feb 2012 17:27:13 +0100 (CET) X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.2.26.161516 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_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NO_WWW 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: Re: [vdr] [Bug] VPS Recording not starting as long as another recording (with lower priority) is running 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: , X-List-Received-Date: Sun, 26 Feb 2012 16:27:18 -0000 Status: O X-Status: X-Keywords: X-UID: 25745 On 14.03.2011 23:05, Markus Ehrnsperger wrote: > 2011/3/14 Markus Ehrnsperger: >>>> Hi, >>>> >>>> I have a suggestion: Treat the VPS margin the same way as the time a >>>> non VPS timer will start before the EPG event starts. Example: >>>> >>>> Tagesschau, starts at 8:00 PM. >>>> >>>> If I don't use VPS, I will create a timer at 7:58 PM (in case the news >>>> start slightly before 8) >>>> If I use VPS, I will create a timer at 8:00 PM. The VPS margin is 2 >>>> minutes (in this example). >>>> >>>> >>>> If I don't use VPS, another recording (with lower priority) will be >>>> stopped at 7.58 PM. The timer will start recording. >>>> If I use VPS, another recording (with lower priority) will be stopped >>>> at 7.58 PM (my suggestion). The next two minutes, the device will be >>>> used for VPS checking only. The recording will start at 8:00 PM. >>>> >>>> Of course, this might look like wasting a device for two minutes only >>>> to check the VPS. On the other side, not using VPS is even worse: I >>>> will waste the device and disk space. So, using VPS is still better. >>>> And, the timer with lower priority has lower priority by purpose. So, >>>> I want it to be interrupted. >>>> >>>> Summary: >>>> I suggest to use GetDevice as soon as the timer is within the VPS margin. >>>> This has the following advantages: >>>> - Easy to implement >>>> - Easy to understand for users, and expected behavior: The timer with >>>> higher priority has higher priority :) . >>>> - No rocket science >>>> >>>> I admit, it has some disadvantages. But, from my point of view, these >>>> are minor compared to the advantages. At the moment, I can use VPS >>>> only with care as I might miss a recording with very high priority. >>>> >>>> Markus >>> >>> Please provide a (tested) patch that implements this. >>> >>> Klaus >>> >> Hi, >> >> I attach a simple patch. I tried it out and it works for me. Any >> comments are very welkome. Sorry I didn't get to this earlier... I'd rather like to give the attached method a try. It modifies the code that actually checks whether a timer matches, and now takes into account whether the "present" event has been seen within a certain time. If it hasn't, the timer behaves like a normal timer and starts at the start time of the event (provided its priority is high enough). Klaus =================================================================== RCS file: ./RCS/timers.c retrieving revision 2.7 diff -u -b -r2.7 ./timers.c --- ./timers.c 2012/02/20 15:51:55 2.7 +++ ./timers.c 2012/02/26 16:09:30 @@ -433,8 +433,12 @@ if (Margin || !Directly) { startTime = event->StartTime(); stopTime = event->EndTime(); - if (!Margin) + if (!Margin) { // this is an actual check + if (event->Schedule()->PresentSeenWithin(Setup.VpsMargin / 2)) // VPS control can only work with up-to-date events... return event->IsRunning(true); + else + return startTime <= t && t < stopTime; // ...otherwise we fall back to normal timer handling + } } } return startTime <= t + Margin && t < stopTime; // must stop *before* stopTime to allow adjacent timers