Yes. Since we are happy with the timer_a_min values, leave them the way they are, but set timer_b_min back to:
#define FPS_TIMER_B_MIN MIN(fps_timer_b_orig, 500)
and see how low you can push timer b before you have problems (remember to keep your shutter speed at 180 degrees, as this is how you would use the feature when shooting videos. so if you are starting at 24fps, shutter at 1/50)
When you are testing the 3x crop mode, start with desired fps set to 45, and then start lowering timer b from there (it will save you lots of time and put timer a at a realistic value)
here are the values from my own testing:
FULL FRAME: (we agree on this)
1080p30: 1965
1080p24: 1965
720p : 1965
480p : 1965
5X:
1080p30: 1195
1080p24: 1195
720p60 : 1195
480p : 1195
3x: (here's where our results are drastically different)
1080p30: 1195
1080p24: 1298
1080p25: 1195
BTW, you don't need to check recording vs. not recording because there is nothing in current fps implementation to support that, besides if timer B can go lower when recording vs. standby it's not going to do you any good because you would normally set it in standby, and if it goes lower in standby vs. recording the worst thing that happens is your recording stops.
so to sum things up, the goal is to choose values that give the maximum range of FPS, then pull them back a bit to some meaningful value on the safe side. i chose 650 since that allows me to overcrank up to 45fps (in my testing I can record 44fps reliably)
So I have mine set like:
#define FPS_TIMER_B_MIN (fps_timer_b_orig - (ZOOM ? 290 : MV720 ? 57 : MV1080CROP ? 650 : 57))
If we can agree that these values are safe, I will modify the pull request, if not, then I guess we'll have to go with the ones you reported initially.