The SlimServer open source application appears well suited to replace the obsolete software provided with these machines. Is anyone aware of the extent of the hack that would be required to have this software feed the Rio?

It would have been useful to include a link.

The other alternative, which might be a much better long-term prospect, would be a new client which made the Receiver fully emulate the Squeezebox! That way the Receiver could benefit from new Slim-Server plugins as they're developed and operate cleanly in a mixed Slim / Rio environment. Of course it's not quite as simple as that - there would need to be a seperate NFS boot-loader and the Rio is in some ways smarter than the SliMP3 / Squeezebox (these cannot link directly to Shoutcast streams for example - all traffic flows via the server). However the development community for Slim is very active and this would give the Rio Receiver a very dynamic future.

Of course the REALLY elegant solution would be for the new client (as an option?) to drive a Noritake VFD from the Rio serial port to provide an exact emulation - probably a better end result than wrapping / scrolling the display text on the current LCD.

As a general point, I think the lack of any standards or interoperability between the multitude of emerging Digital Receivers and their unique Server solutions is a big inhibitor on market growth. The products look too me to be at the stage in their lifecycle where a standard protocol would be more of a benefit to all players than a disadvantage. However the existence of a common solution for Slim and Rio (which probably have the greatest number of shared customers) would be a real bonus whatever happens to the rest.

Now if DNNA could see sense and make the Karma (and a formal Receiver client upgrade) work with Slim Server then THAT would be an interesting development. I wonder what Sean Adams (Mr. Slim...) would make of this idea!

I'm using slimserver to drive my Rio receiver at this very moment.

I'm running an old version of rioplay on the rio, and just have it pointed to the mp3 stream from the slimserver. The interface on the rio doesn't do much (volume, mute, and stop/play), but at least it plays for long periods without flaking out (something none of the rio-specific clients and servers have been able to do).

I've been thinking of altering one of the clients to at least partially interact with the slimserver. Simple interaction should be, I suspect, easy. Next-track, pause, and play could even be done using only http requests. The display partially works as-is, since slimserver puts the current track and artist information in the mp3 stream (which rioplay displays).

True integration would be more work, but perhaps the fact that the new roku mp3 player uses slimserver and has a bitmapped display means there is now configurable display code...

Slimserver is really nice, though. Easy to set up, easy to use, handles any number of clients each with its own stream, stable.

What I would like to be able to do is replace ARM with SlimServer. The goal would be to have Slimserver host the database which the Rio Receiver accesses for music information so that navigation from the RR console remains possible. With SlimServer as the backend, though, the RR would benefit from internet streams and more robust functionality (incl. more control of the RR from the computer) and, ideally, the ability to use SlimServer's navigation options (i.e., directory structure in addition to tags).

I have access to programmers who could do the work, but need to develop the specifications to modify the opensource code so that ARM could be replaced entirely, and have SlimServer handle the task. I would prefer not to have to reverse engineer the whole thing, so I am hoping there may be some here who can give me the specs to get programmed.

i'm testing with slimserver also, don't like the way it doesn't remove the tracks from the playlist/queue once there played as opposed to Streamsicle.
Can still use Trio with either of these, just treat them as another station to stream to.