Transferring a Google Chromecast Audio zone to an HQPlayer zone results in the HQPlayer zone inheriting the radio status of the previous zone. Works when transferring in the other direction as well. So in my system at least, it’s a bug.
OK. Let’s see if Support can tell us if that is intended.
1 Like
@andybob - If one has radio turned on in Zone A and turned off in zone B and then if the two Zones are grouped, when the Zones are ungrouped then both of them will have radio turned on. Could this be considered a bug? Dunno.
Still, I don’t think transferring or grouping was what the OP was referring to. At least, he didn’t describe it that way.
Well it seemed related enough. I don’t have it in me to start a dedicated thread for every quirk, annoyance and possible bug I come across. Just along for the ride.
I think you misunderstood my point. You brought up the potential bug with transferring, I brought up what might be considered a potential bug with grouping.
It wasn’t meant as a snarky comment on your generalizing about radio’s perceived shortcomings…
1 Like
I think the grouping behaviour may be intended because that seems like continuing a persistent state. The transfer behaviour feels unexpected. But I’m just guessing.
I’ll do a summary in a little while and then temporarily close the thread so Support can see a crisp question.
Fair enough. Since we are circumspectively talking about transfer this seems like a place I could mention something about transfer that’s been bugging me.
I seem to remember that it used to be the case that when one transferred a queue from one zone to another, the queue in the transferring zone was cleared. If so, that no longer happens and now both the old zone and the resulting new zone have the same queue. In other words, transfer has become a copy rather than a move, so to speak.
Did it always work this way and I am mis-remembering, or has transfer changed, or is there a new bug in transfer? No big deal either way.
Thanks.