entering a refresh rate of 30 will result in an actual refresh rate of 23

Is there a way to resolve this?

Sorry for the minor wall of text.

Re: Refresh Rate Inaccuracy

One solution to inaccurate refresh rates would be calls to timeBeginPeriod and timeEndPeriod. This affects a global Windows setting and comes with significantly increased power consumption, reduced battery life, and reduced system performance, since it means Windows's thread scheduler is awoken up to 15.625x more often than normal. Otherwise Windows's default system timer resolution of is 64 ticks/second, which limits the precision of Thread.Sleep to 15.625 milliseconds.

Re: DateTime.Now.Ticks

Wouldn't it be better to use a Stopwatch than DateTime.Now.Ticks? It's (probably) much more precise, and measuring elapsed time is what Stopwatch is meant for. DateTime.UtcNow.Ticks would at least be less expensive since it doesn't have to do time zone calculations. It's also Stopwatch's backup if QueryPerformanceCounter isn't available.

DateTime.UtcNow.Ticks and DateTime.Now.Ticks are affected by the system clock being changed and are limited in accuracy by Windows's system timer resolution. DateTime.Now could also maybe potentially risk time zone related bugs.

This affects a global Windows setting and comes with significantly increased power consumption, reduced battery life, and reduced system performance, since it means Windows's thread scheduler is awoken up to 15.625x more often than normal.

That sounds awful. I'd never want LiveSplit to significantly affect system performance.

Stopwatch has the exact same issue