Working around iTunes lack of multi-user support

Update 2/28/06: Geez, this is complex. I ended up giving up on the sync approach when I found I could do just as well by dragging and dropping a music folder from my Public folder onto my wife's copy of iTunes. (I only need an update sync, not a true sync.) However, some things didn't work. My wife couldn't select a bunch of tunes and edit ratings and preferences across the group, she could however set preferences on one file at a time. I had a hunch permissions were an issue. She could read from but not write to the Public folder.

So, I next used Sharepoints to create a new Group called Parents (grrrr. OS X should have an easy bundled GUI app to do this -- in this regard OS X is as bad as XP Home.) and added Emily and I to that Group. Then I set permissions on the Music folder within my Public folder so Parents could read and write to the Music folder. This fixed the problem.

Why is write access required to set ratings using one method, but not with another method? I don't know, but I'd bet I've uncovered some hacked designs in iTunes.

Update 11/8/05: MacOSX Hints has a version of this that's at least comparable if not better. I might integrate the two some day or leave it up to the reader! The MacOSXHints submission includes an AppleScript that looks like it may update the Client's Library database when tunes are added to the Master Library. That sound great and I'll try it.

Update 11/10/05: The synchronization script referenced in Mac OS X Hints didn't work when two users were on the same machine and used Fast User Switching. I figured out how to revise it to support FUS (my first ever AppleScript project). I posted the sample code to the comments section on the Mac OS X Hints article. I may create a web page for this sometime; the techniques are apparently undocumented. (Parenthetically, I think AppleScript's days are numbered -- the lack of documentation is impressive.)

Update 12/11/05: It turns out there's a much easier approach that just works with iTunes. After adding new tunes to the 'master user', switch to the 'client user'. Then click on the folder containing all the music. Drag and drop to the left side of iTunes. iTunes compares and only adds references to the new music. View by date added and add to playlists as desired.

Here's my original article with its updates:

---

There's a "design flaw" in iTune when it comes to multi-user support.

Here's a brief version of the hack to work around it. I'll write more when I'm less tired.

1. Move iTunes Library to Public folder of iTunes owner. (If you don't know how to do this you shouldn't be trying a hack like this!).
2. User 2 opens Public Folder. Copy 'iTunes Library' file to User 2 music folder.
3. Open iTunes. Change advanced prefs on Library to 'don't copy when add'.

User 2 now has their own database pointing to the music repository. They can rate songs, create playlists, etc -- all independently. They can sync with their own contacts and calendar and their own version of iPhoto. (Ahh, but you want to use the shared iPhoto library? Tough luck! Similar set of problems as with iTunes. I'm still working this one. For now I export the images that will go on my wife's Nano.)

But what about songs I add to my collection in future? I have experience with this in another setting. You keep track of what you added and you drag and drop the folder into iTunes for User 2. iTunes will add the songs by reference (since pref is set to 'no copy'.) A bit tedious, but not that hard really. We only add songs occasionally. When you do this drag and drop by the way, iTunes does not create duplicates, it's very good at resolving these conflicts.

Can user 2 do damage? Not to the music library. They have read but not write privileges on the Public folder. [see 2/28 update for why this doesn't quite work]

Update 11/3: A longer version of the above that I submitted to MacOSXHints:

iTunes is designed to support multiple iPods, but not multiple users. In particular attributes like "last played" and "ratings" are meaningful only for a single user. Contacts and Calendars are also user specific.

That's fine, unless your spouse (SO, daughter, son, etc) has their own iPod. Each time they sync they'll mess up smart playlists that depend on "last played", and "ratings wars" may occur.

Of course they could have their own music collection and sync in their own user account. That's presumably what music owners would like. Communal property is not their favorite topic. Apple could readily fix this (see below) but their music partners would likely object.

There's a workaround. I used something similar to this in the past and it works reasonably well if you have a mature music collection and are not adding a ton of new music.

User 1 moves iTunes Library Music to User 1 Public Folder (iTunes will do this for you if you change Library location then tell it to consolidate). Copy User 1 iTunes database there to for the moment using the Finder (ignore the xml file, iTunes recreates that).

User 2 copies the iTunes database file to their default location, deleting their old database. Start iTunes. Change advanced options to uncheck import into iTunes when adding music.

User 2 now switches to their account when syncing. They set ratings, etc. They have their own Playlists.

What about new music?

User 1, Administrator, handles all new music import.

After new music is added Administrator switches to user 2 account (need to know pw of course, otherwise user 2 has to do this) and uses Finder to navigate to newly added music.

Administrator starts user 2 iTunes and drags and drops new music folder into user 2 iTunes.

iTunes is very good at adding references to the new music, but it does not move the music into iTunes because we unchecked the 'move into library' option.

Note that User 2 cannot delete music (read-only privileges on Public folder). User 1 can delete, but User 2 will have dangling references. So, periodically Administrator must delete dangling references in shared libraries, though in fact they don't really do anything -- they just look unsightly. (I think there's an AppleScript that might do this.)