From patchwork Sat Sep 7 10:14:33 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Klaus Schmidinger X-Patchwork-Id: 20034 Received: from localhost ([127.0.0.1] helo=www.linuxtv.org) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1VIFXP-0000TA-LN; Sat, 07 Sep 2013 12:14:43 +0200 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from ) id 1VIFXN-0000T4-Eq for vdr@linuxtv.org; Sat, 07 Sep 2013 12:14:41 +0200 X-tubIT-Incoming-IP: 188.40.50.18 Received: from racoon.tvdr.de ([188.40.50.18]) by mail.tu-berlin.de (exim-4.72/mailfrontend-6) with esmtps [TLSv1:AES256-SHA:256] for id 1VIFXM-0003Hn-3v; Sat, 07 Sep 2013 12:14:41 +0200 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 r87AEc28003487 for ; Sat, 7 Sep 2013 12:14:39 +0200 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 r87AEXkJ022237 for ; Sat, 7 Sep 2013 12:14:33 +0200 Message-ID: <522AFC89.40102@tvdr.de> Date: Sat, 07 Sep 2013 12:14:33 +0200 From: Klaus Schmidinger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: vdr@linuxtv.org References: <522A3349.6070101@setho.org> In-Reply-To: <522A3349.6070101@setho.org> X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.9.7.100620 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 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, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_MEDIA_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __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] Does the back key not really stop the replay? 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 On 06.09.2013 21:55, Thomas Maass wrote: > ... > When pressing the back key during replay, the replay is not really stopped > immediately. It has another behaviour than pressing stop or blue. > When pressing back, the replay stops, and I get back to the menu. But the > recording seems to be still open. That's because when pressing kBack, the cReplayControl::ProcessKey() returns osRecordings case kBack: if (Setup.DelTimeshiftRec) { cRecordControl* rc = cRecordControls::GetRecordControl(fileName); return rc && rc->InstantId() ? osEnd : osRecordings; } return osRecordings; which, in turn, makes the main loop in vdr.c call cControl::Shutdown(): case osRecordings: DELETE_MENU; cControl::Shutdown(); Menu = new cMenuMain(osRecordings); break; > I derived the cReplayControl class in my plugin, to add the archive-hdd > functions. > Before play, the archive-hdd gets mounted, then the videofiles are > symlinked to > the recordingdir under /video. After stopping the replay, the symlinks > should be > removed again, and the archive-hdd should be unmounted. > I did not find a better place to do the unlinking and unmounting, than the > destructor of my class cMyReplayControl. This works only, when stopping the > replay with stop or blue. When stopping with back, I get a "busy" while > unmounting. > And my derived class only implements my own destructor, nothing else. > > Klaus, can you check the exact behaviour when pressing back during replay? > I cannot see kBack in cReplayControl::ProcessKey. But it *is* there - see above. Since kBlue and kBack are both supposed to end replay, and the only difference is that kBack shall open the Recordings menu, I see no reason why the code should actually be different. What is done in case kBack is also done in cReplayControl::Stop(), so I guess the following change should make it behave as you expect: Klaus --- menu.c 2013/08/21 10:45:11 3.3 +++ menu.c 2013/09/07 10:03:16 @@ -4990,10 +4990,8 @@ else Show(); break; - case kBack: if (Setup.DelTimeshiftRec) { - cRecordControl* rc = cRecordControls::GetRecordControl(fileName); - return rc && rc->InstantId() ? osEnd : osRecordings; - } + case kBack: Hide(); + Stop(); return osRecordings; default: return osUnknown; }