Why the star in Music updates late after you favorite a song
You favorite a song with a shortcut, a script or a menu bar app. You look at Music. The star is still empty. Five seconds later it fills in. Nothing is broken
What we measured
While building Likeit we timed the gap. We changed the favorite flag of the current song with a script, then read the label of the favorite button in the Music window until it changed. It took between 5 and 11 seconds. The flag itself changed immediately: reading it back from Music right after the change returns the new value
So there are two things with two clocks: the stored value, which updates at once, and the picture of it in the Music window, which updates when Music gets around to it
Things that did not help
We tried to shorten the delay with nudges after the change: touching the volume, the rating, shuffle, the dislike flag. None of them made the window redraw sooner. Clicking the real star through the accessibility interface was tried too, and dropped: it is unpredictable, it lands on top of the same delay, and it needs extra permissions that a sandboxed app should not ask for
What Likeit does about it
Likeit does not wait for Music. The menu bar star flips the moment you click it, then checks the real value with Music and corrects itself if they disagree. While Music is running, Likeit re-reads the state every 2 seconds, because Music does not announce a favorite changed inside its own window
The effect: the menu bar star is the quick one, and the star in the Music window is the slow one. If they disagree, give Music a few seconds. The menu bar star shows what was saved
The same delay in other apps
Anything that sets a favorite from outside Music meets the same lag in the Music window, whatever the app. If you are writing your own script and the star looks wrong, read the flag back instead of looking at the window