I’ve been developing two extensions recently - one Source Control Extension for Logitech Harmony, and one Volume Control Extension for Denon - and have been running into minor issues. Both extensions get notifications from their controlled devices and use update_state to update Roon with volume information, power state, etc.
What I am seeing after a while - sometimes a few hours, sometimes a day or two - is that those updates aren’t propagated anymore. Even the log output is missing the update_state requests, though the extensions keep sending pings. The other direction works though, and I can e.g. still control the volume of the device.
Any tips to debug this would be greatly appreciated. Source Code is on GitHub btw.
Okay, I believe I finally got a lead on this. Perhaps someone from engineering can comment on that, perhaps suggesting a solution. Here’s what I am seeing:
- Looking at the
config.json, I noticed that there are two tokens under
- At least for the Volume Control extension, I can also see two entries in the Device Setup UI.
- The second tokens seems to appear whenever I start Roon on my MacBook, in addition to the Roon Server I am running.
- To me, those two tokens seem to indicate that the extension is registered with two cores - the standalone Roon Server, and the not-in-use core on my MacBook. This seems to be confirmed by the fact that there are two PING request going out at the same time when both cores are running.
In addition to that, I tried to correlate some of my debug output and the output from the RoonServer.log, and it seems that my extension stops sending updates to the standalone server, the very moment the websocket connection to the MacBook gets terminated. After that happened, the log file contains several messages like this:
06/10 22:12:25 Debug: [remoting] firing request callback with null because of dispose
06/10 22:12:25 Warn: posting to shutdown SynchronizationContextThread
Looks to me as if there is something wrong about the extension lifecycle when it comes to having multiple cores on the network. But perhaps I am just missing something, that would prevent this from happening.
Do you have more than 1 license?
I only have one license so I can’t help you there.
I have run into similar issue before, although don’t remember what exactly it was.
I was playing around with the APIs as well and run the server on my MacBook. So, at home I connected to my home core, but when I’m traveling I switch to the roon on my MacBook. This created two core entries in config.json as well.
I just deleted config.json and restart the server.
If you are doing the same as I did, could you try deleting config.json, restart, and re-enable it from roon’s setting->extension and see if you run into the issue again.
Just one license. Tried deleting the config, but as soon as the Mac App is running in addition to the standalone core, I get two tokens.
I did use to transfer there license between the two instances in there past though…
Could it be that the server on your mac (unactivated) is still running?
If you open Roon on your smartphone or tablet, will it show 2 cores?
You could try to quit Roon on your MacBook and delete all Roon related folders in the user‘s library directory. (Should be Roon, RoonServer and RAATServer).
This will reset Roon on your MacBook.
I will give that a try and post if it’s working. Thanks.
However, the question would remain why shutting down a core would severe an extension’s connection to the remaining core(s), preventing it to send updates…
Okay, I deleted the Roon folder under
~/Library, and my iOS apps are discovering only one core on the network. Yet, when I start Roon on my MacBook, I get another token in the
config.json and another PING request appears every second. I also see a registration in the extension’s log output whenever I start the application.
And the moment I stop the application, all update_state request are getting swallowed…
Just moved this to Tinkering->Roon API, seems to be a better suited place…
Ok, this sounds like a bug, but we need to reproduce it. w
What are a simplified number of steps to reproduce this? I need to first determine if the cores are broken or if my multi-core processing is broken in the node API.
I’ll try to come up with a very condensed test case…
Here you go, instructions are in the README.
@danny: do you know if you could reproduce the issue with that? If you didn’t have time yet, that’s also okay. Just wanted to know if that’s something only happening for me, and if I should invest some time in writing a work around…
Another ping to the Roon team. Is there any way to track the progress of the investigation? Right now, I am trying to completely avoid using the desktop apps, so that I don’t run into this issue.
We finally tracked this down and fixed it. I was able to run your test case without problems, stopping and restarting Roon on one of several systems connected to the extension correctly shows subscriptions from just that one core starting and stopping. The last commit in the fix is 23e46ae for reference.
Let me know if you find any other problems.
Hey @ben, my first attempt didn’t produce they expected results, because I did something wrong when picking up the fix. I got that fixed, but won’t be able to confirm until tomorrow.