Recorded stream corrupted when stopped and appended

There's a lot of code that isn't particularly important for this problem at hand, but here's the important stuff.

The client app is a Flex application.  All presenters are streaming at all times to the server, but only one is being rebroadcast.  The moderator selects the presenter that gets broadcast.  That triggers newClient.connectStream on the server side. The problems come in particularly if ever the video broadcast is stopped (which we refer to as reverting to logo because the video window shows a company logo in it).  That's done with the newClient.revertToLogo function.

...

var serverStream;
var currentClientStream;

...

application.onAppStart = function() {

... 
     
     recordingFileName = dirs[1] + "_" + dirs[2] + "_" + appStartTime + "_stream";
     
     // Create a new stream for recording the session on the server that's includes the room number and timestamp in the filename 
     serverStream = Stream.get(recordingFileName );

...

}

newClient.connectStream = function(streamName) {
     // Set the sharedObject to point to the selected presenter's stream    
     application.currentStreamSO.setProperty("currentStream", streamName);
     trace("Stream changed: " + streamName);
     // Start the recording clock running and log the presenter change     
     setRecording(true);
          
     // ******* This should work but doesn't seem to properly
     // serverStream and visibleStream play the right streams but serverStream's recording gets data corruption and lost time
     // Subscribe to the new stream
     serverStream.play(streamName, -1);
     serverStream.record("append")     
          
     trace("Beginning recording of streams");          
          
     /* This _does_ work, but appending is only okay if it's a client stream that's being recorded
      * not a stream created on the server that's playing the client stream */
     currentClientStream = Stream.get(streamName);          
     currentClientStream.play(streamName, -1);
     currentClientStream.record("append");
}
newClient.revertToLogo = function() {
          
...
     application.currentStreamSO.setProperty("currentStream", null);
     serverStream.record(false);     
     currentClientStream.record(false);
...
}

The code that's cut out is just for clarity.  It's mostly to do with some logging and slide changing, but nothing to do with the video streams.

You can see that there are two streams being recorded, the serverStream which plays whatever client stream is selected and should record that as one long file, and the currentClientStream, which changes each time a different presenter is selected and records a stream that matches their stream name (so like 1201_Mike_Jones.flv for instance).  This has no problem recording and appending.  It's ONLY the stream created on the server side that has this issue.

If I record for, say 20 seconds, then revert to logo, then record that same presenter for another 20 seconds, there are two files, the serverStream recording and the 1201_Mike_Jones recording.  They are _almost_ identical in size, but not exactly.  The serverStream will vary by a few hundred bytes.  Opening them both, the 1201_Mike_Jones will have a file length of 40 seconds but the serverStream recording will only show a length of 20 seconds.  The video can be extracted with some video tools, but it gets garbled after the append.

I experimented a bit to see if it's a problem with the the way serverStream was created, even though I couldn't see how.  So I tried changing the line currentClientStream = Stream.get(streamName); to currentClientStream = Stream.get(streamName + "_test"); and then leaving the rest the same.  Of course the result is that now I get a file called 1201_Mike_Jones_test.flv.  And now it has the file error.  So it's any stream that's created server side appears to be unable to append properly.

This problem started after rebuilding the server with 3.5.3, a totally fresh install.  Since then it's been downgraded back to 3.5.2 and continues to do this.  The code worked prior to that, so I have to wonder if it's a configuration issue, but what could cause this?