Itunes allows library sharing also.
One nice feature is You can connect to multiple libraries at the same time
I think. I don't know if it's got a limit on the number of users though.
Will have to try that one. If it doesn't then maybe JRiver can
point at Apple? 
The iTunes library sharing does have a limit (5 concurrent users), which is actually annoying because you can connect to multiple "remote" libraries at the same time. Because it doesn't auto-disconnect itself from these remote libraries when they're not being used, generally if I share my library using iTunes at the office, that 5 user limit fills up in about 15 minutes and no one else can get in (even though the 5 users actually just connected to see what I had).
The iTunes system is a bit different than what the parent poster (and Fred and I frankly) were looking for though. The iTunes system actually streams the media files themselves to the connected libraries. This is nice, but not really what we need. We'd simply like multi-user, read/write access to the database itself (the machines would need to be able to access the actual media files though some other means -- such as a mounted network drive). Access to the database only certainly poses no copyright infringement problems. Also, there is no
real legal reason that Apple had to limit their system to 5 concurrent users (so long as the remote users can't "record" the stream to their own machines they should be cool). They just didn't want to end up as a test case in court so it was easier to slap on an arbitrary 5 user limit.
So you know, Firefly Media Server (the "new" mt-daapd server) works quite well and doesn't have any user limit at all.
I've tested the current MC database with 200,000 records and noticed a very slow performance when editing or simply clicking the "Audio" button to load the records into the list. The MC database is situated on my "fileserver"-pc, so it is accessed via LAN. The audio- and picture files are stored there, too. To test with so many audiofiles, i copied my tracks to various locations on the same drive.
A couple of things here... First off, I don't know that their point was that you
couldn't build a networked, multi-user, relational database back end for MC. I think their point was that they
don't want to, because the effort isn't worth the gain from their point of view.
Next... Your performance issues are quite likely
because your database is situated on your fileserver PC. MC performs about a million times better when the library (the database files) live on a fast, local hard drive. That's the whole reason I built my scripted system! Plenty of users here have libraries of 200,000+ files and get acceptable performance. It's perfectly fine for the media files themselves to live on network or other slow drives (or even removable media), but MC likes it's database to live on a fast drive. This need has been reduced somewhat with MC12 vs. older versions, but it still doesn't work great with large libraries.
So, in some way, that points to some of the issues that they'd have using a networked, relational database. It's certainly possible, but not for users trying to run MC on Pentium3 CPUs on 10mbit networks (
and we have plenty of those). Everything is a tradeoff!
All in all... Jim's response is quite helpful. I had been (back of my mind) considering replacing my current scripted system with an actual application that provides a similar service. This could be better in a number of ways: I could provide a nice GUI to configure it, the system could more easily support more than two machines, installation would be greatly simplified, and I could make the copy process smarter (to avoid copying over files that haven't changed). However, I've been hesitant to do so because I suspected that as soon as I was 1/2 way through the project, JRiver would add the functionality themselves and my effort would be wasted (especially since the current scripts work fine for me). This gives me an indication that, at least for the next version or two, we're not likely to see too much change in this area.
