[mad-dev] rio receiver replacement software

[Tripp Lilley]

On Fri, 3 May 2002, Reza Naima wrote:

> Yeah, that sounds fairly high level.  I've implemented most everything
> but the decoding already.  So, how do you plan on doing backward seeking
> with your implementation?

I don't. I've scrapped the original Receiver model of retrieving a song
and playing it. I've turned the Receiver into a dumb decoder of RTP
streams and displayer of screen blit updates and a collecter and dispenser
of IR / keypad inputs (though the display server and input dispatcher are
as-yet unimplemented).

Basically, in my world, the server is responsible for dumping out an RTP
stream, to which the Receiver(s) tune in. I'm planning on updating the
server (Obsequieum, currently) to support "locked" and "unlocked" streams,
then giving the Receiver's inputs to the server to control the "unlocked"
streams.

A "locked" stream is one that several receivers (and other RTP listeners)
might be listening to, therefore it wouldn't do to have them competing for
"control" of the stream. An "unlocked" stream is one that one Receiver is
listening to (presumably, although you could opt for anarchy). All of that
receiver's inputs would be able to modify the unlocked stream's contents.

Right now, I just use the web interface to Obsequeium, and don't even
bother with any controls on the receiver.