Fucking iTunes. When Apple renamed iTunes to "Music" they changed it so that it no longer automatically updates an XML file of library metadata, because fuck you, that's why.
That file was the fastest and most convenient way to get info about your music, e.g. by using the Mac::
So I tried writing a command line program that talks to a running iTunes via the ObjC AppleScript RPC crud (SBApplication iTunesApplication and such) that would iterate everything and generate a (hopefully) identical XML file to the one that Apple's no longer generating. I thought that maybe doing this nightly would be good enough for my needs, and would allow the things that parse that XML to continue to work. But it is mind-bogglingly slow. Like, I think it will take 3+ hours to write this file. Which is maybe not terrible for an overnight task, but does make debugging it a lot harder. I'm about 1/4th of the way done writing this thing and I'm already sick of it.
Has anyone else come up with a better solution yet?
Remember, APIs only ever get less useful over time!
Update: I wrote a thing to do this. It was very complicated, and is included in the jwzlyrics Xcode project.
Music.app can still export the XML file that you want
There's also a way you can somewhat automate that, via AppleScript
https://kirkville.com/how-to-export-an-xml-file-in-the-music-app-in-macos-catalina/#comment-27915
Still, probably faster than your intended solution. There's also a framework for doing this, but I doubt you want to start writing Objc/Swift for this https://developer.apple.com/documentation/ituneslibrary
I would have bet that someone would have used that to write a tool that produces the original XML format, but I can't seem to find one offhand. There is this tool which uses it and can export JSON, though: https://github.com/bolsinga/itunes_json
Annoyingly, that framework is only usable if your app is codesigned with an Apple developer certificate.
Cycle times and fast feedback make my day-to-day work bearable -- I can see how much of a pain the waiting is, plus forgetting context and remembering context when you go away/come back (respectively).
You can probably avoid overnight waits: is it worth the time to set up a second login with a tiny library so that the iteration of programming and testing is much much quicker/less frustrating?
K3n.
This seems like it'd work: https://github.com/kylekingcdn/music-library-exporter .
The CLI program took 0.03s, according to 'time', to export a new library containing 43 songs, testing on laptop running Big Sur.
For scheduling within Launchd, you might try https://github.com/mach-kernel/launchk .
That does look promising! Would you mind emailing me an xml file that it wrote, so I can take a look at its output?
Hey neat, that worked flawlessly if I remember what the old XML looked like. And it only took about 4 seconds for 22k-ish songs too, so not too shabby?
Thanks for the shoutout :-)
Happy to answer any questions that anyone may have!
Forgot to mention, an example launchd plist is included and some information is described in the docs: https://github.com/kylekingcdn/music-library-exporter#scheduling-exports-with-a-launchd-service
Unless they've changed it again, the binary itunes library file is a sqlite3 database.
I don't think that's been true for almost twenty years.
Nope, it's binary garbage now.
-j
McCusker strikes again?