[vdr] Re: keys: Very slow response to "recording"

[Usenet-372112@zocki.toppoint.de (Rainer Zocholl)]

Carsten.Koch@icem.de(Carsten Koch)  28.10.01 00:35

Once upon a time Carsten Koch shaped the electrons to say...

>Rainer Zocholl wrote:
>...
>> What the heaven(hell?) is VDR doing during this 15 seconds?

>It is executing the shell command defined at recording.c line 34.

>This has been discussed here before.

Uups, sorry, where/ (subj?)


>You can run than same command outside vdr and time it, e.g.:
>     time find /video -follow -type d -name '*.rec'

Aha, thanks.
gives:

real    0m0.124s
user    0m0.050s
sys     0m0.070s

missing: 14,876 sec ;-)
          

>Then tune your system so this command runs faster.

I think that's someting different.
(The system is a 1000MHz Pentium with 128MB 133MHz CL 2 RAM 
and i815 Chipset, UDMA is enabled, hdparm say: 
22MB/s datarate from disc. All not that slow?)


How do i generate logfile entries from this routine?


>Maybe you have other stuff under your /video path.
>That would slow things down.

>> On the second attempt this seems to go
>> a little faster, only 7 seconds between "recording" "OK"
>> and display.

>Linux has cached the directory entries.

Yes.

>I'm surprised it still takes 7 seconds.
>Maybe you do not have enough memory.

128MB ??

The system is never swapping (AFAIK)

top:

  2:13am  up  6:48,  1 user,  load average: 0.18, 0.07, 0.02
59 processes: 57 sleeping, 2 running, 0 zombie, 0 stopped
CPU states:  1.7% user,  1.9% system,  0.0% nice, 96.2% idle
Mem:  125920K av, 122372K used,   3548K free,      0K shrd,   1440K buff
Swap: 489972K av,      0K used, 489972K free                 77120K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
 1792 root      16   0  8176 8176   904 S       0  1.1  6.4   0:34 vdr
 1793 root      14   0  8176 8176   904 S       0  0.3  6.4   0:59 vdr
 3229 root      10   0  8176 8176   904 S       0  0.3  6.4   0:00 vdr
 3234 root      10   0  1588 1588   616 R       0  0.1  1.2   0:00 top
    1 root       8   0   460  460   400 S       0  0.0  0.3   0:04 init
....


while recording...

uups. memory leak in VDR?
  2:42am  up  7:17,  1 user,  load average: 0.11, 0.05, 0.01
59 processes: 55 sleeping, 4 running, 0 zombie, 0 stopped
CPU states:  0.3% user,  2.3% system,  0.0% nice, 97.2% idle
Mem:  125920K av, 123112K used,   2808K free,      0K shrd,   1088K buff
Swap: 489972K av,      0K used, 489972K free                 77924K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
 1793 root      16   0  8464 8464   904 R       0  0.3  6.7   1:07 vdr
 1792 root      17   0  8464 8464   904 R       0  0.1  6.7   0:44 vdr
 3300 root      15   0  8464 8464   904 R       0  0.1  6.7   0:04 vdr
 3372 root      12   0  1584 1584   612 R       0  0.1  1.2   0:01 top

No, it was the OSD that uses the extra 0,2% memory.



>If I remember it correctly, it takes abut 2 seconds here.

>> It would generally help a lot, if VDR would first turn on
>> a "point" or "carret" on in the OSD before it starts to process
>> any command.

>Total agreement. That would be very nice.



>Also, I believe that Klaus has plans to internally buffer the
>names of the recordings. I am not sure if that idea is bullet-proof,
>as of course you could remove, rename, copy, add, etc. recordings
>outside vdr.

Yepp.
Maybe the problem is somewhere other.


I wonder why the effect is now gone.

I had serval times in a row the 7 sec delay.
Now a longer record stopped, but i started an other:
The delay for "recordings" is gone.
(the 1sec for main ist still there, but that's not so severe)

Last famous user words: "I did not change anything" ;-)