Music Assistant
New Google Cast Issue #3423
-
|
So, to start, I've divorced myself from YTM. If Google doesn't want to let me stream the music I'm paying for the way I want, then I need not pay them for music anymore. I went nuclear and purchased MP3s of any music I didn't already own, cleaned up my local collection, and linked it as a remote FS provider in MA. All my testing with MA moving forward will be LAN stored music and [still] casting to Google speakers and Cast Groups (chromecast). I made the switch over a week ago now and am happy with my decision. However, 2 days ago, I started noticing a new GCast issue crop up. At some seemingly random point (I have a theory below), something breaks and MA has issues initiating a power on of cast speakers and groups. I'll hear at least two disconnect chimes before a proper connect chime. If this is part of a "Play Now" command, music does enqueue and play, but MA shows in the Player that an External Source is streaming and a generic MA icon instead of the usual artwork.
In this state, the playback controls stall the playback. I had to enable Debug to see anything even remotely useful. I suspect Google has tweaked something on their end and it's taking longer to power on, which is failing the pychromecast.controller, causing it to retry several times, but the device ultimately initiates connection to an earlier instance of the request, confusing the controller and MA. I have tried multiple iterations of options in MA, such as flow mode and the like, but nothing has any effect at all. When it happened yesterday, I had to power cycle all speakers in the house, as well as my entire HA server (MA is addon). Restarting any of the 3 components (devices, MA, HA) individually wasn't enough to get the issue resolved. Then, it happened again today. It happened after an announcement was played over music. The announcement was targeted to a single speaker of a group that was playing (might be relevant). Given that I have to completely reboot my smart house to get this back up and running again, I haven't had a chance to do that yet today. However, I will get everything restarted here soon and do another round of tests to see if it is in fact announcements and/or the playing of an announcement to a singular device while a group is playing music might perhaps be tripping up something in PyChromecast. At any rate, I'm still very much in the early testing of this, but I'm curious if anybody else is experiencing or can replicate any of my symptoms: MA needs multiple tries to "power on" device and then loses control of that device in the process, despite it connecting and playing music on 2nd-4th try. The music collection, while being stored on a samba share, literally on the same VM host, are all clean, properly tagged MP3 files sorted in their proper artist album directories. I completely removed YTM as a provider. I fully wiped data of MA and started over fresh. I tried both latest stable and beta builds of the server. Something is going on with the communication between music assistant and Googlecast devices, and I think it's a recent change on Google's side that has introduced additional delay in the device or group responding to a power on command...or perhaps a new response code during the handshake that PyChromecast doesn't know how to handle yet. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
|
On discord this was solved when the device was power cycled. Not sure how long it remained good for. |
Beta Was this translation helpful? Give feedback.
-
|
Yesterday, simply power cycling all my speakers didn't resolve it. Today, I had to leave the house before I could reboot anything and, when I returned home, everything was working normally again without resetting/rebooting anything. So, this still leads me to believe this is an initial handshake issue between pychromecast and the devices. It does make sense that after a period of time that things would reset to an idle state and work again for a while, as chromecasts always time out to an idle state after a period of inactivity on the connection - even leaving paused for a while will eventually force timeout of the casting connection; chromecasts love doing nothing by default. haha I still need to do some more testing of the announcements, as that is when I seem to notice it start acting up; after an announcement has been sent through MA. In this case, it is a URI media file playback generated from HA Assist/Conversation Agent (it's response to an inquiry). I use separate Mics to speak to Assist (Atom Echo) and only send the responses to the Google Speakers via MA's announce action. I have to test a few scenarios yet to confirm if this is actually affecting anything or merely coincidence. But both times I noticed this start happening, it was very soon after an announcement has been played. |
Beta Was this translation helpful? Give feedback.
-
|
Any further findings will be great. It looks like someone else has reported this on discord. |
Beta Was this translation helpful? Give feedback.
-
|
It would appear this problem has "fixed" itself. I'm guessing BS on Google's side and declaring this one "can't fix" unless something else comes up down the road. |
Beta Was this translation helpful? Give feedback.
It would appear this problem has "fixed" itself. I'm guessing BS on Google's side and declaring this one "can't fix" unless something else comes up down the road.