OK, folks, this one has me stumped at the moment, and I’m curious if anyone has ideas that might help.
In the Music app on my 2020 iMac, first in Big Sur and now in Monterey, when I click an album or playlist in Listen Now, and then click nearly anything inside it (an artist name, play button, etc), I’m taken instantly back to the main page of Listen Now. (The same thing happens in Browse, but I never use that.) Every now and then, a click will take me where I’m supposed to go, but almost never. Needless to say, this renders Listen Now almost unusable.
The problem does not occur in another user account on my Mac, so it’s clearly somehow connected to my main account. And it doesn’t apply to all of Music’s Web-based views—I can choose Account > Account Settings and work with my account just fine. Here’s what I’ve tried:
Quit and relaunched. No change. Restarted. No change.
Upgraded macOS from Big Sur to Monterey, and installed all updates. No change.
Signed out of Apple Music and signed back in. No change.
Moved everything out of the Music folder (no change) and back in.
Quit Music, compressed the Music Library file, relaunched to create a new one. No change.
Compressed my old iTunes Library file too. No change.
Moved com.apple.Music.136DA2B8-681B-522C-B80C-B9016B367C02.plist and
com.apple.Music.plist out of my ~/Library/Preferences folder. No change (though I get the Apple Music splash screen on the next launch).
Launched Music with the Option key down and created a new library. No change.
If you want to see the bug in action, check out this video on Dropbox:
Does the other user account (where the problem is not occurring) use the same Apple ID? If not, it would interesting to see whether the problem goes with your Mac account or your Apple ID by changing the other account to use your Apple ID (or changing your account to use another Apple ID).
Adam, I tried to replicate this here, but failed. Does this happen for you only with Apple Music? I don’t use AM so I tried it here with albums in my Library. Wasn’t able to trigger it regardless if I hit play or the artist name link.
Yes, it’s using the same Apple ID in both user accounts. And the Listen Now screen updates on both sides, so it’s clearly connected.
However, you got me thinking, so I signed into Apple Music on my iMac using Tonya’s account. No change—the problem still existed. So it’s something specific to my user account on this particular Mac. I suppose I could do a clean install of Monterey and move everything back manually, but talk about a lot of work…
I’m not surprised—I can’t replicate it anywhere else either. I should also have note that I have no problems on other Macs either. My Apple Music account is clearly fine.
And one more minor addition: the same problem afflicts the Radio screen, which is also a webview. But it doesn’t hit when I play anything in my library, such as my playlists or music videos.
Interesting. The only other thing I can think to try would be to check the Console for messages from Music in case it’s logging an error when you’re observing the bad behavior. Even if it does, you may not end up with a smoking gun, but worth a shot if the only other alternative is a re-install of the OS.
Good suggestion. I did that, and Console does indeed log a ton of stuff from Music when I start streaming messages. However, none of them offer anything that I can interpret as an error. Most seem to be processes that are either the Music app or a system framework like com.apple.WebKit.Networking. I can’t find any preferences that I can control surrounding those.
I also tried using Clean My Mac X to erase all caches—there were indeed two cache folders associated with Music. Then I rebooted, but alas, no change.
Another possibility. The screen you’re showing is, I think an embedded web page. So maybe deleting these files might help:
~/Library/WebKit/com.apple.Music/WebsiteData/...
I think these files (especially WebSiteData/LocalStorage) store cached data from the web site. If they got corrupt, it might create the problems you’re seeing.
Of course, before deleting any files, make a backup copy, in case deletion breaks something and you need to put the files back.
Grasping at straws here, but have you tried the web view directly via Safari at music-dot-apple-dot-com (didn’t want the text to “linkify” since macOS tries really hard to launch Music when you click on such a link)? I would expect you do not see the problem there, since you don’t see it under your Apple ID on your alternate user account, but might be worth a look.
To help you find all relevant files to test:
Quit all applications including Music.
Start a Finder Search in “This mac”
Enter nothing in the search field
With “System files” “are included”
and “Last modified date” “is within last 1 days”
Sort by Date Modified
Start Music and note which files are used as you do your testing. End by observing what happens when you quit.
Cache is a problem when you do tests by removing files, so instead of testing by removing one after the other of the files you are suspecting remove all.
If this does not help, you can try to make a new user account on your mac and do the same test when you start Music the first time.
I guess you know, but if others want to test it: If “System files” option does not appear, you have to add it by Selecting Other…
Interesting thought—I hadn’t tried that, but when I do, it works fine. In fact, it works well enough that I could probably just use it instead of the Music app for this. I don’t do much with local music files anymore.
I’ll have to try this when I have some time, thanks!
It’s describing the permissions repairing, but it mentions something I didn’t previously know:
I think we can safely assume that Apple’s own apps (including Music) are using this service. So deleting Music’s preference file isn’t going to be enough.
You need to kill the per-user cfprefsd daemon for your account. It will automatically restart, using the contents of preference files to repopulate its cache. The following command (from a terminal) will work:
$ killall -u `whoami` cfprefsd
The `whoami` parameter (the back-quotes are critical here) runs the whoami command and replaces itself with the results. So if your short user name is “appleseed”, the above will execute as if you typed
$ killall -u appleseed cfprefsd
The above command will look for all instances of the cfprefsd process running under your account (e.g. “appleseed”) and send it a SIGTERM signal (a software request to shutdown). macOS will automatically re-launch it a few seconds later and the new copy won’t have any old/deleted preferences in its cache.
The demise of preference files has long been in the making.
Howard first described it in 2019 with Mojave.
He then followed up with many pieces on this topic later on. Often with warnings about how unsuccessful working with plist files these days can be.
Bottom line, we should learn how to work cfprefs and we should forget a lot of what we learned on preferences ever since Mac OS X came originally out. /OT