DeleteResume patch for vdr 1.3.32.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Carsten.Koch@xxxxxxxx(Carsten Koch)  11.09.05 18:00


>Klaus Schmidinger wrote:
>...
>> The reading of the video directory is going to be
>> put into a separate thread, so that the user won't experience
>> any more delays, anyway.

>I hereby volunteer to beta-test that change. :-)

>I currently have 519 recordings on 9 disks.
>Even with my patch it takes 30-40 seconds to bring up
>the recordings menu.
>So some of my family members often inadvertendly start
>the first recording in the first folder because they keep
>pressing OK thinking VDR did not receive the previous OK
>command.

That's a generall problem of VDR key processing too.
LIRC commands are not time stamped.
So VDR can't discard "superflous" keys.
Maybe it can help, if VDR would direct LIRC keys into
the "big byte bucket" to discard superflous keys before starting 
to do anthing, and redirect it back to the real processing when done?
The "escape" key should not be directed into bb,
so an action can always be aborted.

Of course these 30...40s are completely inacceptable!
5sec is the limit of any action!
If the action lasts longer the program MUST show
a progress bar or other signs of life...

But there will always be actions which takes "longer".
It is a not acceptable "human interface" that VDR is using the
"queued" keys seconds(!) after pressed. That was state of the computer 
art in the 80th...


Rainer



[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux