As this came up in my recent submission (
#4376: MrWint's GB Pokémon: Red/Green/Blue/Yellow Version "Gotta Catch 'Em All!" in 1:54:56.62), I feel the need to discuss this a bit more:
As of version 1.7.0, the frame timing has changed, forcing all frames to have the same length. Since these frames determine when you can do your inputs, this changes the input timing (and is therefore incompatible with input sequences recorded on the old timing).
The pre-1.7 timing allowed individual frames to be shorter and tried to end the frame at VBlank (this is where the new frame gets drawn). This way the input frames always stayed in sync with the video frames of the game, at the cost of having very few single shorter frames to sync them up again when e.g. the LCD was turned off by the game. The new timing ignores video frames, so that the input frame boundary and the video frame boundary get out of sync.
Let me illustrate the different behavior with a graphic (note that this is a simplification):
http://pastebin.com/sjETYLAW
The problem I have with this new frame timing is this desync of input frames and video frames. The game I was working on, and I assume many other games, fetch their input at VBlank.
With the old frame timing, this was ideal, since you had an input frame on every VBlank, so you can literally do all inputs that are possible on a real Gameboy, which was great. Moreover, if you want to do an action in frame X, you know exactly that the corresponding input frame where you need to make your inputs is also X.
With the new timing, this doesn't work anymore. If you e.g. want to close a textbox, and the game tests this during input frame 7, you can't be sure when you need to do the inputs: If it's after the VBlank that occurs somewhere during frame 7, you need to input it at frame 7, but if it's before the VBlank you already need to press the buttons in frame 6. This is highly confusing, and can (in rare cases) even lead to inputs not being possible at all, if multiple VBlanks occur quickly after another.
To put it in other words:
You set a breakpoint where the inputs are used, and run the game until it stops at the breakpoint. Now you want to know when you need to press the joypad to set the inputs at that breakpoint. In the old frame timing, this was easy, just go back to the last frame boundary and press the buttons there (this is how I created aforementioned run btw). With the new frame timing, it's not that easy: It may be the last frame, or the frame before that, or even no frame at all. It's a mess.
I assume you were trying to fix timing accuracy issues with this, since you determine the movie length by multiplying the frames with the frame rate, and some individual frames were shorter than the rest, resulting in a slightly too-high total time. The main problem here lies in the assumption that the frame rate is constant, because it just isn't. Well, it is under normal circumstances, which is 99.9% of the runtime, but not always.
It may be better to measure the time in terms of CPU cycles, which are in fact constant, and accept that some video (and therefore input) individual frames are shorter. Forcing all frames to be the same length causes issues as described above, and at least for me makes the way I create TASes impossible. I hope there is a chance to rethink this change, or I'm probably forever stuck with BizHawk version 1.6.1 for GB games...
Note that I had this discussion (with a slightly different focus) before for lsnes (
Thread #14274: lsnes (libgambatte core): Frames don't end on VBlank), which does the same thing. I'm running out of usable emulators it seems...
