search

music-assistant / hass-music-assistant

Turn your Home Assistant instance into a jukebox, hassle free streaming of your favorite media to Home Assistant media players.
Apache License 2.0
1.2k stars 44 forks source link

Deleted players come back to life when restarting MA #2500

Closed madbrain76 closed 1 week ago

madbrain76 commented 1 week ago

What version of Music Assistant has the issue?

2.0.7

What version of the Home Assistant Integration have you got installed?

2024.6.2

Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

The problem

After deleting players in the player list, they reappear when restarting MA. The same is true if disabling and re-enabling a music provider.

How to reproduce

  1. In MA, add one or more player providers. I used Airplay, Chromecast, and DLNA.
  2. In the settings / player list, delete one player from each provider. I deleted the 3 "Backyard" players from a WiiM Pro Plus device
  3. in HA, go to settings / add-ons / MA and press restart
  4. go to the MA settings / player list
  5. observe that all 3 backyard devices have come back

The same behavior is observed when disabling/re-enabling player providers in step 3, rather than restarting MA. I believe this is a related issue, which is why I'm not filing it separately.

Music Providers

File system (remote)

Player Providers

Airplay Chromecast DLNA

Full log output

log.txt

Additional information

The doc is silent on the expected behavior for delete. My expectation, was that deleted players would not re-appear, unless I explicitly deleted the corresponding player provider and loaded it again.

What version of Home Assistant Core are your running

2024.6.2

What type of installation are you running?

Home Assistant OS

On what type of hardware are you running?

Windows

OzGav commented 1 week ago

That is normal as they get rediscovered. You just need to DISABLE them in the settings.

madbrain76 commented 1 week ago

Yeah, I figured that might the case, but it was unexpected since the doc didn't address it. The disabled players still show up in the list, and that persists with a restart, but the deleted property doesn't. It seems the "deleted" behavior mostly has a temporary and mostly cosmetic effect. It is a bit confusing. I'm wondering what the use case is for the current "delete" implementation, or whether it's even needed, if disabled does a more consistent job.

OzGav commented 1 week ago

If there were problems with a player then deleting it and having it get rediscovered can be useful.

madbrain76 commented 1 week ago

I see. That makes sense, but it isn't an obvious UI. I hope this gets documented.

OzGav commented 1 week ago

Just added to the docs so that will appear when we next do an update.

madbrain76 commented 1 week ago

Thanks. If you are open to suggestions on this, I believe there are several possible other ways to expose this in the UI that might be more obvious, and could file a more detailed enhancement request in discussions.

OzGav commented 1 week ago

Marcel is always open to suggestions. He is busy though so try and keep it succinct! :-)

madbrain76 commented 1 week ago

I'll try, but as you may have noticed, I'm a very detail-ortiented person :)

madbrain76 commented 1 week ago

I gave it several hours of attention while in my hot tub tonight. I came to the conclusion that the single most impactful change would be to change the wording from "Delete" to "Forget" , or something else less final. I think this change would have fewer users reaching for the doc. It won't be perfect, of course, but it will be an improvement, IMO. If you don't want to read the dissertation, you can stop here :)

"Delete" has a connotation of finality. You don't expect something that you have deleted to come back, unless you have explicitly undeleted it. "Forget" allows for the possibility of remembering later.

This would also be similar to the way devices are managed in the Ubiquiti Unifi controller/network application, or at least used to be, in case you have ever used it. They have now changed the wording from "Forget" to "Remove", though. And Unifi devices get discovered again automatically and fairly quickly after being removed/forgotten, unless of course they are physically disconnected (failed/sold/powered off device, etc).

I have already written half a dissertation. I don't have a very clear single recommendation for how o further improve things, as there are some edge cases. But I do have some observations which could be taken in consideration by devs in the future in order to decide if/how to improve things.

a) the auto-discovery after delete is surprising, not just because it happens at all, but because it happens much later

b) a possibility is to take into account whether the device is currently connected when being deleted. And if so, warn the user that the device will come back, unless it is forcibly disconnected, to avoid the surprise resurrection.

c) expectations and results are not the same for a device that is physically still connected, vs one that isn't. In one case, the device comes back, and in the other, it doesn't, because of course, it can't. Even though they are very similar, the first case feels seems like one is "resetting" the device, and in the second case, "deleting / removing / forgetting" it. There could be some level of feedback in the UI to differentiate them, possibly two separate context menu options.

d) for example, an explicit "reset" option might immediately rediscover the device, rather than wait for it to happen later.

e) the delete/remove/forget option might not rediscover the device, or at least not immediately, just like what happens today with delete. This would give time for the user to physically disconnect the device, if it is still connected, so that it doesn't reappear. There could even be a message after the operation to that effect, stating something like "please unplug your device now".