Gigantic Library split over two locations

Exactly, anything located outside the designated media folder is copied into it. Whatever is already there stays put. See Managing your Mac media libraries - Apple Community for some further background. The media folder would typically contain folders for each type of media, or some of those and all artist folders, depending on any previous history with different builds of iTunes. While manually moving things around on local HFS+/APFS drives should be OK I'd be wary of moving anything by hand on the RAID.

tt2

Ouch. I'd have skipped the renaming if asked. It probably renamed files according to the details set out in the iTunes Media Organization section of Managing your Mac media libraries - Apple Community, which in and of itself ought not to have had any impact on the content of the files. You can recover the state of the library from the Time Machine backup, but do you have a backup of the RAID as well?

tt2

Use Music > Preferences > Files to set the media folder location to the folder containing your content on the RAID drive. You may be prompted to consolidate to that location when you set it, or you can do so via File > Library > Organize Library > Consolidate Files. This will create copies of the files that are currently on the local HD and update the library such that it points to the new copies. Once the process is complete you can manually clean up the old media folder location on the internal drive.

There is an advantage to having the .musiclibrary package in the same folder as the media folder as the library can then be easily cloned to another drive for security. Reading the library from a RAID location may be less efficient however, so there may not be any benefit in going through the steps to rearrange the library into this shape.

tt2

DHeckeler wrote:

I've never done this before. What should I be looking for in the XML file? Thank you!

XML is a text file, and is readable. Each field in an XML file is tagged, and related fields (such as each playlist entry) are nested.

Here is a hunk of the XML of an exported playlist, showing part of one track within the playlist:

<key>6842</key>
		<dict>
			<key>Track ID</key><integer>6842</integer>
			<key>Name</key><string>Espacio Sideral</string>
			<key>Artist</key><string>Jesse &#38; Joy</string>
			<key>Album Artist</key><string>Jesse &#38; Joy</string>
			<key>Composer</key><string>Jesse Huerta &#38; Joy Huerta</string>
			... {stuff here deleted } ... 
			<key>Apple Music</key><true/>
			<key>Location</key><string>file:///Users/mrhoffman/Music/iTunes/iTunes%20Music/Apple%20Music/Compilations/Jesse%20&#38;%20Joy/03%20Espacio%20Sideral.m4p</string>
			<key>File Folder Count</key><integer>5</integer>
			<key>Library Folder Count</key><integer>1</integer>
		</dict>

Each track will have information containing the full file name of the file containing the music.

From a test XML created and exported here (from a consolidated music library, which means stuff isn't located all over), the file location info from the XML file looks like this:

<key>Location</key><string>file:///Users/mrhoffman/Music/iTunes/iTunes%20Music/Apple%20Music/Compilations/Jesse%20&#38;%20Joy/03%20Espacio%20Sideral.m4p</string>

This location is a standard URL, like those that work with a web browser. (This uses standard URL encoding too, which means the %20 is a space, and &#38 is an & ampersand character.)

In this example, the file:/// means the location is a file, a colon and three slashes immediately following means no host name is specified; that the referenced location is local. If you see entries with a host name between the second and third slashes, that particular track is not located locally. It's on a file server or host somewhere, and that could conceivably be the local host accessed remotely.

An example of a remote file specification for a file served by the host fileserver.example.com looks like this:

file://fileserver.example.com/Users/mrhoffman {rest of path here}

You can use a search tool in your preferred editor, or a command-line tool such as grep, to search for just the location entries from the file, which will make this all less to look at.

The following is an example of using the grep tool available in zsh and other command line shells to search for the location entries for the tracks included in the playlist XML file named Jesse y Joy.xml :

% grep -i ">location<" "/Users/mrhoffman/Documents/Jesse y Joy.xml"
... {stuff expurated} ...
			<key>Location</key><string>file:///Users/mrhoffman/Music/iTunes/iTunes%20Music/Apple%20Music/Compilations/Jesse%20&#38;%20Joy/03%20Espacio%20Sideral.m4p</string>
... {stuff expurated} ...
mrhoffman@cupertino ~ % 

There are quite probably better tools for managing enormous libraries too, or at least for reading and processing XML playlist files.

TL;DR: look for locations in the XML that don't include a string starting with file:///

I suspect you're going to have to roll back everything, but try holding down option+cmd as you launch Music which opens it in its safe mode and does some internal consistency checks. If you're using a .musiclibrary restored from backup hold down option as you launch Music and explicitly chose the restored file in case the app is actually opening a cached copy of the library.

tt2

That error would suggest that you have one or more items that your library believes are stored somewhere on your network, at a fixed IP address rather than a named device. Could that be the case? One possible approach is to uncheck all items in that playlist and sync once more, (syncing only checked tracks of course) then check tracks in blocks of say 4,000 at a time until you see the error again. Once the error crops up play with the selection until you can determine what track causes the problem.

tt2

Gooner2105 wrote:

Sorry to Hijack thread, but how can I pick your brain about Music problems turingtest2? I've sent you a message yesterday to samsoft and was just wondering if you could help,

Thanx

Steve

Please start your own thread as mixed threads get confusing, please include actual details about “music problems”, and please link to the user that you wish to ping. If tt2 doesn’t see it, I’ll get them over to your new thread as I’ll see your new thread. This if, it’s not something others can answer.

Whatever was done with locating or relocating those files, those files are being accessed remotely.

Whether you added that linkage without realizing, or some corruption thoughtfully added that?

First step is rebuilding the playlist.

Second is reviewing the 54,000 music files involved. (I keep my music library consolidated, so I don’t know if Get Info (in Music app) will show a local or remote location for a song. It might.)