I havenât tried this, but from looking at the node-roon-api-transport code it should be possible to pass to a callback function to the subscribe_queue function that remembers the zone id of the zone you want to subscribe to. I think that should let you avoid stomping on your subscriptions, in that you can ignore messages about the wrong zone.
Also, this is totally undocumented, but:
this is the return value from all the subscribe_x functions:
so, you can save that object, and call unsubscribe on it when you want to. The ucb argument there should be called when the unsubscribe request returns.
Not a fan of using undocumented features, so while interesting, option 2 is probably not the route I want to take. I may explore it for academic reasons, though.
The route I am going with at the moment is to wrap the subscribe_queue output in a new Object that also includes the zone_id. But I am already finding shortcomings to that approach as well. Now I am working on the differences between a Subscribed response from the subscribe_queue and a Changed response.
For what it is worth, I was a bit surprised that the âqueueâ was not included in the subscribe_zones response. From the outside looking in, it seems to me that a âqueueâ is associated with a âzoneâ, so it should be part of the subscribe_zones response. But I am sure there is a good reason for the separation.
Sometimes undocumented may just mean someone didnt get around to adding the right format comments to the source for the method and thus it never got âdocumentedâ - returning an object on which you can invoke unsubscribe() seems fairly intentional.
This is me saying that I am a rubbish programmer and I havenât figured out how to do it yet!
I am a pretty senior Linux sysadmin and know Local/Campus/Metro Area Networking very well (a bit rusty on Wide area MPLS based networkingâŚ), but JavaScript and web apps are just a hobbyâŚ
I am honestly floored that no one has looked at the code for Roon Web Controller and said âdear lord - this is terrible!â
The main challenge that I am facing is that I am probably using this API in an unexpected way. The API looks very friendly for single page web apps where all of the processing is done in one place. But I am trying to put all of the output from the Roon API into an in memory âstateâ table on the server side Node instance. That state is then sent to the browser via a web socket so that the client side browser can quickly switch between zones with all of the information displayed.
This is intentional since I have multiple subnets out that house which I control my music from, but the Roon API doesnât natively play well with routers, so the Node instance is a proxyâŚ
I will figure something out though. I already have the zone and the zone_seek messages in the state table, I just need to get some time to add the queue messagesâŚ
I suspect quite a few people havenât looked at the code because we get enough opportunities to look like idiots in not understanding things in our daily lives without going and actively finding things to look dumb about.
Unless itâs written in VB4 for Windows and uses nothing but If Else in which case Iâm in thereâŚ