Actually, probably result of change 21643. It only hits when transcoding includes a pipeline (not, for example, when transcoding MP3->Mp3 for bitrate limiting) because, in this case, there is a real OS pipe(2) with a small buffer between the processes in the pipeline. This may be different on Windows.

Change 23161 attempts to address this. It has not been tested on Windows (or Mac) and this is important because of the significant difference in the way Pipeline work on that platform.

If however, it does work well on all platforms, then the timed retry mechanism in Slim::Web::HTTP::sendStreamingResponse() could be eliminated, I think.

See also bug 9475 for further issues to do with Pipeline.

Created attachment 3981 [details]
full log

Testing on Windows Server 2003, that worked much better for a minute, then crashed the server.

I was playing to an SB2 with bitrate limiting set.  Skipped tracks two times.  The display froze with track 2 showing (E:/flac/Red Hot Chili Peppers/By the Way/02 Universally Speaking.flac) for a few seconds, then went blank.

See the attached log.  I have logging of player.source set to Debug.

I've tested this a few more times.  It seems skipping the track works fine if I watch the buffer fullness and do it after the buffer reaches 100%.  Attempting to skip at anything less than 100% fullness crashes the server every time.

I'm guessing this may be related:  Stopping from the remote no longer works for this player getting a transcoded steam.  Pause works, and Off works, but hold-Pause just causes the display to go into Date/Time screensaver (my stopped screensaver), then back to my Now Playing screensaver after a while.  Music is never interrupted.  Stopping still works on players not using bitrate limiting and transcoding.

This is working quite well now with Squeezeslave connecting remotely to the server across a slower Internet link, although the crasher happens there too if I try to Skip from the web interface too soon after a track begins.

Jim, I think one of your problems was caused by the select that I introduced in the earlier change not always being cancelled when the transcoding pipeline was closed. I'll fix that in a minute: change 23206.

*** Bug 9482 has been marked as a duplicate of this bug. ***

I think this is fixed now.

The crasher appears to be fixesd.  But I still have a lot of trouble stopping an SB2 while playing a transcoded stream.  In a few dozen tries I've only gotten it to recognize hold-pause a couple times.  No other remote commands have trouble, all acting instantly.

I played around with it a bit more - the stopping problem may not have anything to do with transcoding.  Maybe related to the changes made for bug 9221?