STMo is only sent if there is a stream connection:

net/slim_tcpdata.c line 294:

                else if  (!sent_output_underrun_event &&
                          stream_connection &&
                          slimproto_connection) {
                        DEBUG_TRACE("Sending output buffer underrun event");
                        slim_tcpdata_event(SLIM_TCPDATA_EVENT_OUTPUT_UNDERRUN, 0);
                        sent_output_underrun_event = 1;

                        // If we wait for the server to tell us to pause, it will cause audio glitches
                        // so we need to automatically pause here
                        decode_pause(0);
                }

so you are right STMo will not occur in this case.  Shouldn't it be sending STMu in this case?

I was not clear enough. There is a stream connection (for the new track) but no audio data has been received by the time the output buffer underruns. This may be some variation on 9617.

Is there an easy way to reproduce?

I have not had a chance to try since I did the analysis.

Maybe one could configure an mp3->flc transcoder that actually just does 'sleep 100', disable mp3->mp3, and make a playlist of a flac track (which will play normally) and then an MP3 track, which will use the bogus transcoder and thereby send no data.

OK, that sounds reasonable.

Yes, I can reproduce it like that.

This is the relevant code (decode.c:859):

			// Check if the audio buffer has underrun.
			if (decode_audio_state() & DECODE_STATE_RUNNING) {
				if (fifo_empty(decode_fifo_rptr, decode_fifo_wptr) && !decoder_first_buffer) {
					current_audio_state |= DECODE_STATE_UNDERRUN;
				}
				else {
					current_audio_state &= ~DECODE_STATE_UNDERRUN;
				}
			}

The problem is that decoder_first_buffer will be TRUE during the inter-track gap, and it needs to be for the other used to which it is put (to do with crossfade, etc.).

Actually, I'm not sure why the '!decoder_first_buffer' is needed because, as far as I can tell, current_audio_state only enters DECODE_STATE_RUNNING once the decoder has produced some data, but perhaps I am missing something to do with inter-thread delays or race conditions.

Alan,
  This bug was created when we corresponded regarding bug#10436.  If I have it right Bug #10436 was split into bug#10680. bug#10681 and bug#10682.  I'm not sure if it matters but I'm running an IMAC and using Apple Lossless files.  

I upgraded to 7.3.2 and the problems that I mentioned in bug#10436 are still there.  The difference seems to be that I don't have to manually go into Squeezecenter or the playlist to get things playing.  If I wait the problem out the system usually resolves it by eventually playing the track correctly or playing the next track.

It may also be interesting to note that these problems seem to go away when I shut off my living room Squeezebox3.  Sync'ing 3 boxes I only have trouble with Gapless play here and there.  All four boxes sync'ing brings back all the problems that I previously mentioned.

After a couple of weeks of cutting off rooms to avoid problems these are the patterns that I'm seeing.
-If I use all four rooms I'm pretty much guaranteed to have problems pretty quickly.
-If I cut it down to three rooms the problems are much more intermittent but they're there.
-Most of the time I'm forced to go to two rooms.  One room being my wired player and the second being the transporter which gets 99% signal strength.  This cuts the problems down even more but they're still there.

I'm not tech savvy enough to understand the posts below.  I do see that the details describe flac.  Please note that I use ALAC on an Imac.

We are now planning to make a 7.3.3 release.  Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future.

Thanks!

Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out.  If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it.

Thanks.

I sent a detailed e-mail to Chris, I was really counting on getting things fixed.

Andy and Alan will work together on this