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