When doing a transcoding pipe like this:

mov flc * *
        [faad] -w -f 2 $FILE$ | [flac] -cs --totally-silent --compression-level-0 --endian little --sign signed --channels 2 --bps 16 --sample-rate 44100 -

The first process in the pipe (faad) is not terminated by the server if one switches to a new song mid-stream. The "flac" process immediately dies. If the song plays to the end, then both processes disappear as expected. On a fast PC the "faad" process decodes the rest of the song after a song switch, and disappears after a few seconds (thus not causing any problems), but on my slow server (a 533 MHz EPIA board), it can take up to 30 seconds or longer. And if I switch song again within these 30 secs, and again and again, then suddenly the PC is swamped with faad's (and it takes longer and longer for them to disappear), and the "active one" cannot decode in real time any longer until some of the old ones finishes off (which takes a LONG time now).

If I only have one process in the pipe, ala:

mov wav * *
       [faad] -w -f 2 $FILE$

things seem to work (ie. no left-over processes at song switch), but this stresses my WiFi more, which is why I want flac compression also.

I think the problem must somehow be related to how the pipe is built and taken down in the slimserver Perl script. If I just pipe "faad" into "more" in a shell pipe and exit "more", the faad process immediately dies. So the shell pipe works, but the slimserver one doesn't.