Unix-based server software suggestion

I know that the FAQ lists a number of alternate server software packages, but I wanted to know what people were actually using. I've been trying to use the mock one, but it doesn't seem to like the v104 software. (I haven't tried to downgrade to v103 yet.)

I just wanted to know what other people actually used that they thought was effective.

I've been using JReceiver for the office Rio Receiver.

Seems to work. A few bugs, but mostly, we just run it in random play jukebox mode, and it seems just fine doing that.

I'm using JReceiver as well -- it works well on my network (linux, 2 Rios, plus external streaming). I really like the XML-RPC backend (though soon to be changed to SOAP). It allowed me to build a simple menuing/search system in Python/Apache for when I want to listen to stuff on a PC when I'm not in front of a Rio.

I can't really use the Java one because (1) Java on OpenBSD doesn't really cut it at the moment, and (2) Java on a Pentium 166 doesn't really cut it.

Is anyone using the mock one? It seems to work, but then it mounts the NFS share and reboots or restarts or something. Can anyone give me pointers?

Hi Shawn,

Would you mind sharing your "simple menuing/search system" with the rest of us? I don't know XML-RPC or Python and would like to be able play files on my PC as well.

Thanks,

Brent

Well, I recently updated to JRec 0.2.4, and some of the XML-RPC interface has changed, so my app broke. However, this should be able to give you a good idea of what I was using. Right now, the play buttons (perhaps the most important?) don't work.

I'm by no means a python expert, and this is poorly written code, but this gets the job done for me. To use, drop into a directory on a webserver, and update the jrecusername and jrecpasswd to a username/password that you've created in JReceiver (the user role should be "users"), as well as rpchost and rpcport to point to your JReceiver installation.

This requires a web server (its a CGI script, I'm using Apache), and XML-RPC libraries for Python 2.1 (might work with newer, I think I'm using an older XML-RPC library.)

I know Reed Esau (JRec's author) is talking about moving to SOAP for the next release, which is part of the reason I haven't really bothered to fix this much yet.

JRec (and its successor) will be sticking with XML-RPC as its core RPC protocol.

The API should stabilize once JRec gets into beta, which will likely be the coming release sometime this year.

--Reed

I use a somewhat customized mock server for my single rio. When I set it up that was all that was available. And even now i like the simplicity. It's a really slick set of perl scripts.

My customizations are mainly to the regexs used to parse the filenames and directory structure. My music is arrainged in author/album/song.mp3 form, so rather then make use of the frequently inconsistent (or non-existant) id3 tags, i altered things to use the directory structure. With this setup more of my music is available to the Rio then is available to the Autotron out in the living room.

At the moment it's running on my web/mail/file server, which is a Pentium-1 166 with 64 megs of ram and 200 Gigs of software-raid-1 storage.

On the rio itself i'm running an old version of RioPlay (it's in dire need of an upgrade...).

tRec may finally be enough to force me to install java on my fileserver...

Don't know if anyone's still monitoring this thread, but here's the solution I'm using.

I looked at Jeff Mock's server, but liked some of the work that had been put into the YARRS version. However, neither did what I need, so I re-mangled it all to suit my requirements.

I use iTunes (on a Mac in fact, but should work with Windows version) to encode and manipulate all the music (over 12K tracks). My server (linux/perl) then reads the iTunes XML backup file and serves all this data to any of the 4 Rios I have around the house. A nightly routine checks for any changes and rebuilds if necessary, including a complete list of m3u playlists that I use to drop onto Jemplode to update the RioCar with the same data.

This way I can keep everything up to date with the music and playlists I control via iTunes and it all seems to be working at the moment, although I couldn't guaranteee it'll never hiccup. Particularly if Apple change the Track IDs that iTunes uses as that requires a complete rebuild. Also, iTunes now changes the XML file whenever you play anything, so detecting changes is more convoluted.

Like the Mock original it uses symlinks to the actual music files, but creates them only as needed so a rebuild is much faster.

My aim is to integrate it all as much as possible with iTunes and so far I'm reasonably happy, but always looking at ways to improve. I'd really like the RioCar to emulate an iPod so I can sync directly from iTunes, but not really looked into that yet.