The decision to deprive Squeezebox HA users of the sync and unsync commands and replace them with the media player join and unjoin commands has resulted in a step backwards for this platform. Prior to this breaking change, I had a fantastic set of automations that, when triggered, would sync my squeezeboxes, mid-track, when I would leave one room and enter another with a squeezebox. Now, the join only happens once the current track stops playing and a new one begins. This is fine, I suppose, if youāre used to listening to a playlist full of 3 minute-long bubble-gum pop, but itās a massive disappointment for anyone used to listening to three-hour-long DJ sets. Or a symphony. Or anything longer than a 3 year-oldās attention span.
You broke it! It was perfect and you replaced it with a dud. Give it back ya vandals! I donāt care why you did it. Stop breaking things that were not broken!
So the PR which added the change you are complaining about is here
Iām looking at it and nothing changed except the name. The code that was in the async_sync method (which is what squeezebox.sync called) moved to the async_join_players method. Itās identical code though. Nothing in here suggests waiting for the track to finish or any waiting at all.
Iām also confused by your timing. This change was made two releases ago. Since then hereās what the code has been if you called squeezebox.sync:
It literally just calls join players after logging a deprecation warning. It hasnāt changed since this was made.
So are you just getting around to reporting this or are you noticing some new behavior? Because if youāre noticing new behavior now then its not caused by HA. Something mustāve changed on squeezeboxās side.
Ah ha! I think I know what the problem is now. Until quite recently, I had my Squeezebox Duet receiver attached via its LAN port to a Huawei WiFi 6 which I use as an access point in the master bedroom. I was getting WiFi dropouts due to its close proximity to a secondary mesh router so I shifted it into the den and reconnected the Duet to the network via a new network switch connected to the secondary mesh routerās solitary LAN port. It might very well be in an IP conflict with another device that wants its IP address.
That was the receiver that I was using to reproduce the problem as originally described, so that seems a good bet to me. Iāll perform some further tests when I get home and if the problem is then resolved by my tinkering, I shall throw myself on the mercy of this court for the false accusation made to our mighty programmers.