I've taked Jeff Mock's code, cleaned up it, organized it, added documentation, and put it here:

http://homepage.mac.com/pauljlucas/software/rio_grande-0.9.tar.gz

The complete set of changes is:

• Reorganized the directory structure:
  (a) Moved CGIs to a cgi-bin directory.
  (b) Moved the database out from under the web server's document root.
  (c) Moved non-CGI (e.g., ssdp) code out from under the web server.
• Rewrote all CGIs majorly cleaning up the code.
• Playlist support has been added to the CGIs.
• Half of the "favourites" Rio request has been implemented: the Rio can now request "/favourites/all" and get the contents of a plain text file back.
• The "build" CGI has been rewritten as a command-line program and also:
  (a) Now builds playlist files from directory names.
  (b) Colons are now allowed in track names.
  (c) Added optional warnings.
• The "ssdp" daemon has been cleaned up and also:
  (a) Now takes command-line options.
  (b) If started as root, gives away its root privileges.
  (c) Added proper setting of SO_REUSEADDR socket option.
  (d) Can now alternatively run under (x)inetd.
  (e) Logging is now optional.
• Added sample a dhcpd.conf, a (correct) httpd.conf, an NFS exports, inetd.conf, and xinetd files.
• Removed the web interface. (Sorry, I don't care about it. I edit my MP3 files' ID3 tags using other software anyway, e.g., Apple's iTunes.)
  

Suggestions (including a better name) welcome.

If you give that a page I can link to (I don't see it on http://homepage.mac.com/pauljlucas/software for example), I'll add it to the FAQ entry about third-party servers.

A web page is coming (as soon as I can think of a nifty graphic logo for the top I'd also really like to think of a better name. I don't like the one it has now, but I needed to call it something.

The only other thing I've thought of is YARS: Yet Another Rio Server.

I'd also really like to think of a better name.

Deriode? Deriosion? Derion? Riodicule? Cariocature?

Ooh! Spurious!

(If you can't tell, which is likely, I'm finding similar words to ``mock'' and forcing ``rio'' into them.)

I still think we should have called the Central "Rio Grande".

Peter

YARS: Yet Another Rio Server.

When I finally finish writing (on my own time) my replacement Rio server (to atone for my sins writing the stock one), I'm thinking of calling it ARSE (Another Rio Server), but I can't figure out what the E should stand for...

Effort ?

When I finally finish writing (on my own time) my replacement Rio server...

I really have only one wish for the Rio Receiver right now, and unfortunately, it would need to be a combination client/server code change. It would also have to be implemented server-side on the Jupiter, because that's the server I'm using.

It's the simple feature of saving the receiver's settings across a power loss. We lose electricty here, briefly, several times a month. Each time, I have to fiddle with the receiver to reset the bass and treble, turn on shuffle/repeat, and select a playlist. This sounds simple, except for the fact that I don't always know the power has screwed up the receiver when I just want to turn it on and listen to it. The times when this happens, I'm either at the dining room table in the middle of a meal, or I'm in the hot tub, and I'm using the remote. So having to get up, walk to the receiver, and peer at the display to reset it is a Big Deal in those situations.

If it weren't for that little problem, the receiver would be essentially a zero maintenance music player, a true "appliance". As it stands right now, that problem makes it continue to be a fiddly little computer-type gadget that "crashes" sometimes, instead of an appliance.

Effort ?

Cool! ARSE it is!

Sounds like you really need a UPS Tony...

OK, I changed the name and provided a web page:

http://homepage.mac.com/pauljlucas/software/yarrs/

It's the simple feature of saving the receiver's settings across a power loss.

That's why the Rio Receiver is supposed to send "State!" packets to the server every now and then. When it boots, it's supposed to send a "State?" packet to the server to retrieve its state. I don't recall whether everything that you want to store would have been passed in those packets, though.

As I recall, we didn't get around to actually implementing it, and the "third party OEM" weren't that bothered about it.

Do you have any plans to extend the existing protocol?

It'd be really cool if you could do stuff like list all the albums for a particular artist.

Cheers
Paul

Oops sorry, that post of mine should have been in reply to Paul, not Roger.

I can't extend the protocol since that's detemined by the client.

It shouldn't be too difficult to alter the replacement clients (RRR, RioPlay and tRio) to support new stuff though. If it's done the right way, you'd still be backwardly compatible with the original clients - they'd just not make use of the new calls.

Sounds like you really need a UPS Tony...

Honestly, I don't have any always-on equipment except for the Jupiter and the Rio Receiver. Power loss doesn't seem to bother the Jupe, it's just the volatile-RAM nature of the Receiver that makes it fiddly.

That's not to say I haven't considered putting the Receiver on a UPS already. I think I may end up doing precisely that. Seems kind of silly to use a UPS to protect the least expensive computer-related item in the house, though.

Well, that presupposes I have an interest in writing client-side software. Currently I don't; but even if I did, I don't have that kind of time right now.

I'm fairly happy with the stock client player. My only complaint is that, when I select a track to play, the Rio plays it and stops. What I really want is it to play from that track forward (just like my CD player currently does).