Yeah there's still an annoying race condition in the logic where the interrupt routine that reads serial data from the GPS module is trying to signal a new line available to parse, while at the same time the main loop is clearing that signal that a new line is ready to parse. The problem can occur when the GGA and RMC lines come in at just the right time so the main loop misses one of them. I have a feeling as the timing between the CPU and GPS module drifts around it can briefly get into that state and one of the messages is missed for a period.
One thing you might try is disabling the interrupt routine by changing this line in the setup:
To this:
Make sure the debug logging is turned off too because without the interrupt processing serial data the main loop needs to be as fast as possible to keep up with the data. To turn off debug logging change this define at the top:
Is defined as false:
You might even want to go into the loop function and comment out any Serial.print statement too just to save some cycles.
Ultimately the race condition is tricky to resolve because AVR chips and libraries aren't really made to handle concurrency--i.e. there aren't any lock, semaphore, or other structures you can use to easily serialize access to important bits of memory like the new line is ready to parse flag. A more drastic option might be to greatly simplify the script so it just reads as much data as it can from the GPS serial connection and immediately dumps that to the SD card. I.e. pull out any use of the GPS library to parse the GPS statements and check if there's a fix, etc. This would be the fastest way to handle getting data from the GPS module to the SD card and wouldn't have any race conditions, but wouldn't have any nice logic like only recording good location fixed GPS lines. Unfortunately it's a bit of a trade off in what your needs are for the sketch.