instant stopping vs missing audio on end of playlist

[christf]

When the inputpipe is closed by th sender SnapcastC will issue a STOP-Signal to all clients on that stream. The intent is to instantly stop playback when requesting so at the source - for example by hitting pause/stop in the player application. This nicely hides the buffering that has the goal of compensating network issues.

When hitting the end of a playlist, the player will stop and close the inputpipe of SnapcastC. SnapcastC is unable to distinguish between the player hitting the end of the playlist or the user requesting playback to stop. This means that the audio stream will not be audible up to the end but only to the end - bufferMs. The current workaround, adding a song with silence to the end every playlist, is inconvenient.

It would be nice to:

• be able to completely play a playlist up until the very end
• use large network buffers
• allow to react to user input almost instantly

[christf]

seems like we can pick 2 out of 3. This is alleviated a little by using smaller values for timeout_ms and stopping the player on successful reads after timeout_ms has been reached earlier. Closing this as there is no way to address this with a second channel.