It was based on all-Empeg code, though (i.e. not something I've still got access to), plus it was a really old version of Samba and they kept changing the plugin API.

Really, though, Samba isn't the Right Answer as it's too onerous on the client. If you want to pick music by genre or year, you can either build a database on the client (heavyweight) or do it by creating even more soup folders in the Samba plugin (but then, as SMB can't represent symbolic links, the client can't easily tell when two files are the same track). It would, in fact, be a bit like using a mass-storage MP3 player that isn't self-databasing.

And all the transcoding stuff would be nifty, but only really works for streaming. If the client supports fast-forward or rewind, and starts seeking in, say, a VBR MP3 transcoded on-the-fly from a FLAC, the server is in a world of hurt.

My current thinking on this is that, unlike with a portable player, you can't put the database in the client, which means that you really need UPnP or similar as the remote-access-database layer; and also, if you have clients that can only play MP3, you need the MP3 and FLAC files complete and pre-existing on the server if seeking is going to work.

Alternatively, if your media server runs Windows, you get to use Windows Media Connect. It's a Microsoft product that's robust, unobtrusive, does the job, and does so by implementing the relevant open standards fully and efficiently. Which is not something you'll often hear me say.

Peter