You sure this isn't referring to the normal version of the Xine-GUI? LMCE uses its own, which does not seem to support that many of the functions of the standard Xine GUI.

I would say that you are right. LMCE merely uses the same xine libraries that the Xine player GUI uses. It doesn't use the GUI itself thus I would doubt very much that any of those keyboard shortcuts work. the Xine_player wrapper would have to implement the key presses. There is no reason why it couldn't issue the same calls to the xinelib libraries that the GUI version does. However, how you intercept those key presses is a different matter. I remember having a conversation with Thom about this on a different matter - I assumed that the Orbiter received the key presses and somehow you had to hook into that perhaps using DCE messages. Thom explained, and I didn't really get it then, and can't remember now! Functionally, it seems it would be easy to add, as long as you understood how this part of the architecture worked, and could track down the calls to xinelib you need to make, then updated the wrapper code and any other part that you need to capture the key presses....

I have now ditched my external room correction kit, which was adding the 100ms delay, and got an Onkyo receiver with Audessey MultEQ XT. Their technology promises to perform FIR based room correction filtering but through some undescribed enhancements be able to reduce the number of filter taps (correction bands) required and therefore the processing power and delay. Reviews look promising.