[From nobody Mon Mar 21 18:00:40 2005 Return-Path: <vdr-bounce@linuxtv.org> X-Original-To: Carsten.Koch@icem.com Delivered-To: cko@icem.de Received: from localhost (localhost [127.0.0.1]) by icem.de (Postfix) with ESMTP id 0C24A125BC2; Sun, 30 Jan 2005 14:59:57 +0100 (CET) Received: from icem.de ([127.0.0.1]) by localhost (melpumpe [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23391-05; Sun, 30 Jan 2005 14:59:55 +0100 (CET) Received: from mail.convergence2.de (mail.convergence2.de [217.160.180.71]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by icem.de (Postfix) with ESMTP id 7C68A125BA7 for <Carsten.Koch@icem.com>; Sun, 30 Jan 2005 14:59:55 +0100 (CET) Received: from mail.convergence2.de ([217.160.180.71]) by mail.convergence2.de with esmtp (Exim 4.34) id 1CvFbF-0005Bj-Hu; Sun, 30 Jan 2005 14:58:49 +0100 Received: with ECARTIS (v1.0.0; list vdr); Sun, 30 Jan 2005 14:58:14 +0100 (CET) Received: from mail.convergence.de ([212.227.36.84] helo=email.convergence2.de) by mail.convergence2.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1CvFag-00056B-Jl for vdr@mail.convergence2.de; Sun, 30 Jan 2005 14:58:14 +0100 Received: from melpumpe.icem.de ([158.225.1.2] helo=icem.de) by email.convergence2.de with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CvFag-0004uN-CS for vdr@linuxtv.org; Sun, 30 Jan 2005 14:58:14 +0100 Received: from localhost (localhost [127.0.0.1]) by icem.de (Postfix) with ESMTP id BA360125C68 for <vdr@linuxtv.org>; Sun, 30 Jan 2005 14:58:16 +0100 (CET) Received: from icem.de ([127.0.0.1]) by localhost (melpumpe [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23257-05; Sun, 30 Jan 2005 14:58:14 +0100 (CET) Received: from [192.168.25.1] (wald.icemnet.de [192.168.25.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by icem.de (Postfix) with ESMTP id 1505F125BA7 for <vdr@linuxtv.org>; Sun, 30 Jan 2005 14:58:13 +0100 (CET) Message-ID: <41FCE7F2.6060304@icem.com> Date: Sun, 30 Jan 2005 14:58:10 +0100 From: Carsten Koch <Carsten.Koch@icem.com> Organization: ICEM Technologies GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Video Disk Recorder Mailing List <vdr@linuxtv.org> Subject: [vdr] [PATCH] Getting rid of redundand resume.vdr files. Content-Type: multipart/mixed; boundary="------------090105000105050202050304" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at icem.com X-archive-position: 1926 X-ecartis-version: Ecartis v1.0.0 Sender: vdr-bounce@linuxtv.org Errors-To: vdr-bounce@linuxtv.org X-original-sender: Carsten.Koch@icem.com Precedence: bulk Reply-To: vdr@linuxtv.org List-help: <mailto:ecartis@linuxtv.org?subject=help> List-unsubscribe: <mailto:ecartis@linuxtv.org?subject=unsubscribe%20vdr> List-software: Ecartis version 1.0.0 List-Id: vdr <vdr.mail> X-List-ID: vdr <vdr.mail> List-subscribe: <mailto:ecartis@linuxtv.org?subject=subscribe%20vdr> List-owner: <mailto:listmaster@convergence.de> List-post: <mailto:vdr@linuxtv.org> X-list: vdr X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at icem.com X-Spam-Status: No, hits=-3.3 tagged_above=-999.0 required=6.3 tests=AWL, BAYES_00 X-Spam-Level: This is a multi-part message in MIME format. --------------090105000105050202050304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I noticed that updating the recordings menu is still very slow. Caching the data of course did speed up things, but vdr still has to scan when /video/.update was touched (after an external change), when it starts up, etc. Also, this has been a workaround at best against the two basic flaws: 1) when replaying or recording, VDR floods the linux file system cache somewhat needlessly with data that do not need to be cached since they typically do not get read again while they reside in the cache, thus slowing down the intire system and not leaving room in the cache for even the directory entries, which makes all directoy accesses - including vdr's own recordings scan - rather slow. I know this problem is not trivial to fix, but using O_DIRECT on nnn.vdr files whenever possible should cure it. 2) vdr's recordings scan is slowed down further by the fact that VDR opens all resume.vdr files to see if the recording is rewound. This problem can be greatly reduced by two steps: a) Remove the resume.vdr file if it points to (almost) the beginning of the file. Patch included. b) Never try to read it. If the directory entry is there, with the above patch it can be assumed that the recording is not rewound. Carsten. --------------090105000105050202050304 Content-Type: text/plain; name="delete_resume.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="delete_resume.patch" --- /tmp/vdr-1.3.17/recording.c 2004-11-01 15:04:47.000000000 +0100 +++ recording.c 2005-01-30 13:30:03.383815096 +0100 @@ -193,15 +193,25 @@ bool cResumeFile::Save(int Index) { - if (fileName) { - int f = open(fileName, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); - if (f >= 0) { - if (safe_write(f, &Index, sizeof(Index)) < 0) - LOG_ERROR_STR(fileName); - close(f); + if (fileName) + { + if ((Index / FRAMESPERSEC) < 60) + { + Delete(); return true; - } } + else + { + int f = open(fileName, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH); + if (f >= 0) + { + if (safe_write(f, &Index, sizeof(Index)) < 0) + LOG_ERROR_STR(fileName); + close(f); + return true; + } + } + } return false; } --------------090105000105050202050304-- ]