>if you stack commands to navigate the menu system.
>Sometimes it won't be just right due to the speed

Yup, I see that too. I was hoping not to have to fuss with it for now, because the "fix" is HUGE -- it requires a timing queue to be implemented for button presses.

But.. I have given in and implemented it today. v67 now "paces" button presses when feeding them to the player software (let me know if the pacing is still not slow enough -- also, this might still fail if the player waits for the disk to spin up.. dunno).

A side effect of implementing the timing queue is that "LONG" presses can now be emulated as well, using the .L modifier to denote them in the IR translation sequence to the right of the equal sign.

And one person asked for a "SHIFT" toggle feature, so I'ved added that too, using a .S modifier. Any .S left of the equal sign means "do this only if in 'shift' mode", and .S on any value to the right of the equal sign means "toggle the shift mode".

Of course, all of these modifiers may be used in various combinations to really overload the buttons on a remote, so it is important (for now) to specify them in the correct order: .L comes first, then S, then T(uner), A(ux), or M(ain/mp3) (only a single dot at the beginning).

I've also fixed some rather peculiar bugs in the button translation code, so everyone should probably upgrade to v67 or higher.

It'll take a few minutes before the instructions on the web page are brought up to date, but the code is there now.

Enjoy

-ml