Re: SoundBridge M2000 and SlimServer

This is interesting info.

An intelligent server that catalogs metadata is fine with me as long as it
is designed to run well on a server. A client app like iTunes doesn't fit
the bill though, since it requires an active UI session and has client-app
type behaviors. A non-Apple implementation of a DAAP server would be a
particularly interesting proposition because it could do server-side
on-the-fly translation between non-Apple supported formats and
Apple-supported formats (e.g., transparent FLAC to WAV conversion).

It's also worth noting that implementation strategies aren't polarized
between a) smart clients that talk a file-server protocol (e.g.,
SMB/NFS/AppleTalk) and build catalogs on the client and b) smart servers
which build catalogs on the server and use higher-level protocols (e.g.,
DAAP, SlimServer) to drive dumber clients. Consider, for example, the TOC
generation model supported by the Audiotron which enables a catalog to be
built on the backend, which the client consumes, but the client talks a
file-system protocol. Tools like Philip Jacob's excellent TOC Generator[1]
can be run as a chron job, on demand, whatever, on the backend to build up a
catalog file, which the media player reads. No trolling metadata across a
thin pipe, and no need for a new protocol on the server.

Anyhow...I think we're probably straying from the purpose of this list and
should take this discussion offline if it's worth pursuing.

Thanks again for the info...

Greg.

[1] http://www.whirlycott.com/phil/software/audiotron/

Justin wrote:

> not sure if this will help you out, but there are other daap-compatible
> servers out there besides itunes. check out daapd[1]and mt-daapd[2].
> they are of course written for un*x, so not much help for a machine
> running windows, but someone has ported daap for windows[3].
>
> i haven't tried them yet, but i am *very* interested in replacing a
> server running smb/nfs/appletalk with just one protocol: daap. of
> course, the clients have to be capable of talking daap, but the current
> favorite (itunes) has no problems with that. <g> plus, there are other
> daap clients out there[4]. granted, they aren't all that pretty, but
> there is work being done.
>
> personally, i find a daap client/server setup much more appealing than
> a file-system sharing based setup. for one, it works better over slow
> links: the server can read and parse the media files faster than a
> client over an 802.11b connection.
>
> anyway, just some food for thought... :)
>
> [1] http://www.deleet.de/projekte/daap/daapd/
> [2] http://sourceforge.net/projects/mt-daapd/
> [3]
> http://www.rustydust.net/cgi-bin/wiki.pl?
> action=browse&diff=1&id=WinDaapd
> [4] http://sourceforge.net/projects/jtunes4/  (there are others)
>
>
> -justin
> -- 
> justin blecher  //  sr. design engineer  //  digital pulp | nyc
> mailto:[email protected]    http://www.digitalpulp.com
> vox://212.679.0676:235           fax://212.679.6217
>
> _______________________________________________
> Roku-tech mailing list
> [email protected]
> http://lists.rokulabs.com/mailman/listinfo/roku-tech
>