It happens quite often, especially on newer emulators. You carefully construct your TAS and when you check your progress, the movie goes off at some point and does something wrong.
Most desyncs are a result of inconsistent savestates, when an emulator or savestate error causes you to start using a wrong savestate. Once that happens, your movie starts to go down the wrong track. If you notice this happening, recreate your savestates at the most recent point where the movie plays as intended.
While you are making a movie, make it a habit to periodically play through your whole movie to verify that it syncs, and always make a backup of the working copy.
If your run desyncs, no one can help you recover the lost work. It is up to you to be careful.
There are a number of causes of inconsistent savestates:
Emulator problems
PCSX, Mupen64, and FBA-rr
- In general, these emulators have some desync issues. Be careful.
Dolphin
- Wiimote recording is prone to frequent desyncs, and will fail to playback if you do not restart Dolphin each time you wish to start recording or playback of a movie.
Snes9x
- Official version of Snes9x 1.43/1.51/1.52 has some desync issues. Use snes9x-rerecording instead. (The improved Snes9x can play and record movies in both Final and WIP timing.)
- Snes9x 1.43/1.51 has trouble with sound. Games with timing to music or sound might desync. Some state saving/loading patterns during music changes might cause trouble as well. Using the improved version, disabling sound emulation entirely or using Fake Mute mode may prevent it from happening.
- SNES9x 1.52 improved sound emulation logic overall, and the issue above has probably been fixed. If you don't need some advanced TAS features (such as Lua scripting), you should use SNES9x Rerecording 1.52.
Visual Boy Advance
- VBA v20 has some emulation problems with SGB games. You may try recording with other versions instead. (The timing of GBx games is mostly different in v20.)
- VBA versions prior to v21 have a bug that may automatically disable the GBA Lag Reduction setting. If this happens, you may try to hex-edit the GBA Lag Reduction flag stored inside your desynced movie according to the VBM format description.
JPC-RR
- Stopping emulation when executing very long instruction sequences without any (conditional) jump instructions (and also some other instructions) can lead to a desync. Fortunately, such sequences are extremely rare.
- Savestating while the joystick is being polled will cause a desync in versions before r11.4. If you enable joystick (it isn't enabled by default), use r11.4 or newer.
- Certain forms of self-modifying code may very rarely produce desyncs if pipeline flushing is not enabled.
Savestate problems
- You loaded savestates in the wrong order. For example, you should never load a savestate which is ahead of your current time. Implementation of "bullet-proof rerecording" prevents this. Due to current standards, this has become an obsoleted problem. This only happens in Famtasia and older versions of Gens and should not happen in most modern emulators.
- Some savestates are flawed and will not exactly save what is supposed to be in the system at that moment. For example, savestates in older versions of Snes9x do not save the C4 memory used by games such as Mega Man X2, so critical or even functionally visible errors occur with savestating when C4 memory is used. There may be no choice but to use guesswork, and to keep checking the movie until you are out of the desync zone.
- Loading a non-movie savestate while read-only is off may break your movie at the point where you loaded it. Never overwrite your movie savestates with non-movie ones.
- Loading a movie savestate from a different movie before resuming recording, which may even happen with current "bulletproof rerecording" emulators as listed below:
- "Bullet-proof rerecording" is imperfect. Some emulators may allow you to load savestates from the movie while the movie is being played in read-only mode, and you may resume recording from the already desynced movie by toggling off read-only mode or making a new savestate and then loading it. Avoid loading wrong savestates during replaying, or at least do not overwrite your correct movie savestates with desynced ones. Implementation of "bullet-proof replaying" prevents this problem.
- At the present moment, no known emulator can prevent you from producing two distinct movies which share the same movie identifier, by using an external tool (e.g. a movie editor). The safest way to this issue is to discard any old movie savestates that were made in a different timeline than your current movie's.
Other problems
You have external codes on (ex. Game Genie codes)
Be very careful that you don't have external codes on. It is easy to miss. If your movie requires external codes to play back correctly, TASVideos cannot accept your movie.
You changed the settings by accident
If this happens, try to rectify what you can. Do not continue with inconsistent settings.
Replay is not quite deterministic
If you discover that different ways of playing the movie yield different results, it could mean an emulation issue with that game, and it is recommended you stop TASing it until the problem is diagnosed and fixed.
Game suddenly resets
Some versions of some emulators may have a bug that inserts spurious resets in some conditions, resulting in a movie that suddenly resets the game. This can be fixed by editing the movie file to remove the spurious reset.
TODO: update info.