So, when the multimedia -ho timer in this alias has result of 65 when run as the only timer, does that mean the multimedia settings are silently disabled, and in-effect the timer is behaving in all ways as a non-multimedia -m timer even though $timer(test).mmt returns $true?
It is still a multimedia timer :-)
As the results are consistent during an application run, it looks like the application is being assigned to either a particular core, thread processing order, etc. that determines when the multimedia timer interrupt updates the tick count relative to when the timer is triggered, and this affects the time elapsed measurement. In other words, the tick count update vs the timer trigger may be in or out of sync, determined at the time the application is run. It could even be due to high resolution vs non-high resolution tick count measurements, since the high resolution tick count measurement can only take place after a multimedia timer is started.
Timers are tricky. mIRC's timer source code includes commented out test code for five different methods of triggering timers and five different methods of retrieving a tick count. The actual timer code uses four different methods of measuring tick count, depending on whether certain APIs are supported on your version of Windows and/or whether a multimedia timer is being used. In addition, the multimedia timer is set to trigger no lower than every 5ms, even if a scripter requests a 1ms timer, due to the impact multimedia timers have on system resources.
Couple the above with Windows messages being used to relay timer events, along with the other issues mentioned in my previous post, and there are quite a few possible causes for what you are seeing.
I will add this to my to-do list to look into in the next beta cycle.
