This is a very common problem and stems from the way that media 100 (and other NLEs) handle incoming timecode. The system samples timecode at the start of digitising and then inserts its own generated TC into the file rather than continuing to read the inbound TC from the player. Usually this works fine, but if there is a TC jump within the DV recording the the system doesn't see or account for that.
Media 100 is also meant to re-sample the inbound TC at the end of a digitised section and report of any inconsistency - but in my experience it doesn't always do that, especially when digitising is stopped by a break in recording etc.
DVCam and DV are notorious for introducing TC jumps, sometimes of only a few frames when recodings are paused, stopped, re-cued, or resumed.
The only way to guard against it is to manually stop the digitising whenever a shot changes in the raw footage (pay particular attention when the pre-roll rolls the tape back past a cut) and then re-start for that shot.
To get yourselves out of the hole you are in now (and believe me I've been there!) you have two choices - 1 slip the picture back into sync, or 2 force redigitise the audio with the picture and adjust all the affected edits. I find setting up a two timelines with the off-line version, and the on-line and switching between the two at convenient timecodes will show which ones are wrong quickly, and also enable you to work out the offset.