For an external process, e.g. a user interface, it might be necessary to know the current state of the Songcast receiver.
The Receiver service has a TransportState state variable with the following values: "Stopped", "Playing", "Waiting", "Buffering". These states are not really described in http://wiki.openhome.org/wiki/Av:Developer:ReceiverService. The last two values are not relevant to me and upmpdcli does not support them either. So, let's focus on "Playing" and "Stopped".
upmpdcli sets the state to "Playing" when sc2mpd is running and to "Stopped" when sc2mpd is not running. Since the halt flag is now processed by the receiver (if ohSongcast is build with the halt patch), the state reported by upmpdcli is not necessarily correct. This is the case when the Receiver device is linked to the Sender device, but the Sender is not sending audio data. Instead of the correct "Stopped" state, upmpdcli reports a "Playing" state.
The question is, which instance of upmpdcli/sc2mpd/ohsongcast should be responsible for setting the correct state?
One possibility is that the OhmReceiverDriver in sc2mpd is responsible, as it already has the necessary function calls like Playing() and Stopped(). However, the Stop() function is never called unless a user invokes the Stop action.
Another possibility would be to set the state according to the state of the halt flag of the audio message, e.g. in OhmReceiverDriver::Process(OhmMsgAudio& aMsg). However, that might not reflect the state of the audio output device. For example when an audio message with the halt flag is processed the transport state would be set to "Stopped", though there are still audio message from the different queues to be played by the audio backend.
A third option would be to set the state according to the state of the audio backend, e.g. if the ALSA device state is RUNNING, the transport state is set to "Playing".
Any thoughts?
