Bugzilla – Bug 2957
button presses should be better queued
Last modified: 2008-10-02 14:56:58 UTC
When SlimServer is updating my music database, the client interacts slow. When I use the remote, button presses appear to be queued up in the server. I can press the keys a few times, remove my hand from the remote and the client has a life of it's own. While the client is dequeuing button presses slowly, a new "power off" button press can't poweroff the client. IMO this is a show stopper. It is suggested each button press has a class and time stamp associated with it. There should be two classes of button presses, POWER and OTHER. Power button presses would always be inserted at the head of the queue. If timestamps expire (5 seconds), the button press is removed from the queue. This makes user interaction more intuitive other then the box going out of synch from the user's intentions. USE CASE: - P4 2GHz Windows XP SlimServer 2.2, as service 1. Have SS clear and update a large music library (10k songs) 2. Use the client, you will notice huge lags between button presses and VFD response. 3. Also, button presses are queued, such that client response is out of synch with the user's commands.
I believe triode is workign on this for 6.5
If it works, hopefully he can backport it to 2.2. This functionality should be in the stable release. A friend and I tried the Slim after setting it up. Unaware of the library update, we were both disappointed with the performance. My friend was astonished that a device with unusable event/action performance problems cost $300! Again, hopefully this can be backported.
I have added something to 6.5 which should reduce the problem of queued button presses being processed over a long period of time. However this will not avoid the reduced responsiveness when the library is being scanned [there is other activity targeted at the 6.5 release which is aiming to do this.] As for back porting. To maintain the stability of the current 6.2 release I would not expect these changes to be back ported. [if we back port significant changes rather than just fix bugs then there is a significant chance of reducing the stability of 6.2]
6.5 has this queing. Closing.