From patchwork Mon Mar 21 17:00:43 2005 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Carsten Koch X-Patchwork-Id: 11815 Received: from mail.icem.com ([158.225.1.2] helo=mail.icem.de) by www.linuxtv.org with esmtp (Exim 4.34) id 1DDQGZ-0004Ge-Vv for vdr@linuxtv.org; Mon, 21 Mar 2005 18:00:36 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.icem.de (Postfix) with ESMTP id DA1D5125BCA for ; Mon, 21 Mar 2005 18:00:47 +0100 (CET) Received: from mail.icem.de ([127.0.0.1]) by localhost (melpumpe [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28486-03; Mon, 21 Mar 2005 18:00:45 +0100 (CET) Received: from [192.168.25.1] (natan.icemnet.de [192.168.3.5]) by mail.icem.de (Postfix) with ESMTP id 6B26A125BA4 for ; Mon, 21 Mar 2005 18:00:44 +0100 (CET) Message-ID: <423EFDBB.90002@icem.com> Date: Mon, 21 Mar 2005 18:00:43 +0100 From: Carsten Koch User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Video Disk Recorder Mailing List X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at icem.com Subject: [vdr] [PATCH] Getting rid of redundand resume.vdr files. X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Klaus Schmidinger's VDR List-Id: Klaus Schmidinger's VDR List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2005 17:00:36 -0000 Status: O X-Status: X-Keywords: X-UID: 934 While trying out VDR 1.3.23 today, I noticed that it does not contain the attached patch (yes?). Klaus, is anything wrong with my patch or my idea or did you just did not have time yet to look at it? Anyway, the patch still fits smoothly into VDR 1.3.23. Cheers, Carsten. 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. --- /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; }