Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] Re: timer sorting
Emil.Naepflein@philosys.de(Emil Naepflein) 28.03.02 13:59
Once upon a time Emil Naepflein shaped the electrons to say...
>On Thu, 28 Mar 2002 12:29:12 +0100, Tim Abels <tim.abels@ewetel.net>
>wrote:
>> So it happend to me on tuesday...
>>
>> BTW: What exactly does the VDR when searching the recordings ?
>>
>> My box is running since november and the time to search the
>> recordings is increasing since then.
>>
>> Is a search-time of about 10seconds normal ? (80% of a 76GB
>> partition) Or might the few mp3's on /video/mp3 are responsible for
>> that ?
>The more files you have the longer it takes.
That's true, but i too find that the recording search time
is much too long, but i don't have so many files.
>It is also dependend on whether a playback or recording was
>running and has pushed out the info.
>I have about 300 GB on disk and it normaly takes less than a
>second.
I have only 50GB on a 60GB Samsung and the time between pressing
"4 recordings" and the directory listing took almost 6 sec!
(Debian with 2.4.17 from kernel.org, Debian-ext3, 128MB DRAM, 1000MHz)
May be some "mean" tricks are required?
- Do not search for more directories, that are actually
possible to be displayed (but continue in the back ground...)
- Do not recurse for files as long as no directory is selected/displayed
But such tricks are only required if there were ten thounds of
files. But there are far less than 50 files (IMHO), and it is always so slow.
Still i think the problem is originated by the mkfs tool.
On such a "big" disk, mkfs seems to reserve Zillions of filename
entries, and Zillions of never needed inodes too.
>You may loose all your recordings.
But then it'll become faster, right? ;-)
Rainer
Home |
Main Index |
Thread Index